ostatnio na tapecie archiwizacja danych

[kori 29]

starować cronem, rozpakować z panelu directadmin, tak najwygodniej, trochę dziwnie by było cronem rozpakowywać

 

Edytowano Marzec 20, 2016 przez kori (zobacz historię edycji)

[Piotr GRD 608]

Dlatego ja stosuję format .tar.gz - wiem, że w jakimkolwiek środowisku nie przyjdzie mi pracować, na jakiekolwiek ograniczenia nie trafię, z pewnością obsługa tar i gzip będzie.

 

Owszem, dziwnie wykorzystywać cronjob do takiego zadania, choć przy braku SSH zdarzało mi się wykorzystywać tę procedurę do różnych jednorazowych wywołań jakiejś komendy.

 

Ponadto... Skoro jesteś świadom ograniczeń tychże tanich hostingów, to musisz wykazać się kreatywnością w podejściu do tematu. Masz jeszcze PHP, a w nim funkcję exec() (jeśli nie zablokowana, bo i z tym różnie bywa). Na wspomnianym wyżej hostingu pozbawionym dostępu do cronjob wywołuję tworzenie backupów z zewnątrz (np. z pomocą cronjob.de), uruchamiam skrypt PHP, który to z kolei uruchamia tar i mysqldump.

Edytowano Marzec 21, 2016 przez Piotr GRD (zobacz historię edycji)

[kori 29]

ja zakładam że hosting crona ma, i exec w php zablokowane
zmieniłem pierwszy post przetestowany w pełni skrypt

nie jestem czy założona przeze mnie logika archiwizacji jest prawidłowa/skuteczna

[Bartosz Z 236]

Kori, brzydko!

Nie kopiuj tych archiwów, tylko usuń ostatnie i nowszym zmieniaj tylko nazwy

 

Fajnie, że rozwinęła się merytoryczna dyskusja, a skończyło się robienie na siłę z Koriego debila.

[kori 29]

dzięki za zwrócenie uwagi, w istocie rotatocja zmianą nazwy jest bardziej logiczna

rm ${updatefile}4.tar.gz
mv ${updatefile}3.tar.gz ${updatefile}4.tar.gz

w zasadzie to i tak nr4 zostanie nadpisany, więc chyba nie ma co go usuwać

 

a co myślisz o logice archiwów którą wykreowałem?

wiesz ja większość tych jęczytroli (archi l3szcz) nie widzę postów bo są w ignorowanych, a spoofy jeszcze nie zasłużył

Edytowano Marzec 21, 2016 przez kori (zobacz historię edycji)

[Piotr GRD 608]

Nie do końca rozumiem do czego, w jakiej sytuacji mogłyby Ci się przydać archiwa ze zmianami z ostatnich 7 dni. Ale być może masz swoje zastosowanie.

 

Twoja - obecnie zmodyfikowana - uwaga dotycząca niedogodności z archiwami gzip... Ściśle rzecz ujmując to nie chodzi o rodzaj kompresji, ale w ogóle o skompresowane archiwa TAR, bez względu na to czy skompresowane przy użyciu gzip, bz2, deflate, lzma czy jakkolwiek inaczej.

 

 

Jeszcze jedną opcję TARa Ci podpowiem, może skorzystasz, może nie.

 

Jak dla mnie pewną niedogodnością jest obecność wewnątrz archiwum pełnej struktury folderów włącznie ze ścieżką /home/USERNAME/domains/EXAMPLE.COM - przecież jeśli wybraną domenę przeniosę na inny hosting, to ścieżka - choćby USERNAME - pewnie będzie inna, a więc po wypakowaniu plików trzeba jeszcze wykonać ich przeniesienie do odpowiedniego folderu. Dlatego korzystam z opcji -C ("-C /home/USERNAME/domains/EXAMPLE.COM/"), a w swoich archiwach mam jedynie zawartość public_html dla każdej domeny osobno (z poczty na hostingach nie korzystam, za wyjątkiem przekierowań, reszta jest mi zbędna w razie przenosin).

 

Inną niedogodnością - w przypadku archiwów ze zmianami - jest niepotrzebne odzwierciedlenie pełnej struktury folderów, nawet jeśli są one w tymże archiwum puste (bo wewnątrz nie ma zmodyfikowanych ostatnio plików). Przy rozbudowanym drzewie i chęci ręcznego przejrzenia co się zmieniło jest to pewne utrudnienie. Ale w ramach samego TAR tego ponoć nie można obejść, trzeba by osobnym skryptem najpierw badać datę modyfikacji plików, a później TARowi przedstawić tylko wyszczególnioną ich listę, co raczej nie jest warte zachodu.

 

 

 

Dla osób, które jednak korzystają z baz danych - najczęściej MySQL - dodam prostą, podstawową linijkę, na bazie której można oprzeć archiwizowanie baz danych właśnie. Pierwsza wersja dla jednej określonej bazy danych, druga dla wszystkich baz, do których użytkownik ma dostęp. Modyfikacje według uznania, oczywiście, każdemu według potrzeb, ale początkujący może od poniższego zacząć.

mysqldump -u MYSQLUSERNAME -pPASSWORD DATABASENAME | gzip > /PATH/database_backup.sql.gz
mysqldump -u MYSQLUSERNAME -pPASSWORD --all-databases | gzip > /PATH/alldatabases_backup.sql.gz

Dla dodatkowego bezpieczeństwa dla celów backupu tworzę specjalnego użytkownika bazy danych, który ma nadane wyłącznie uprawnienia SELECT i LOCK TABLES.

Edytowano Marzec 22, 2016 przez Piotr GRD (zobacz historię edycji)

[kori 29]

nie ma juz tez folderów ścieżki: home/user/domains w archiwum
zmienilem ostatnio modyfikowane 7 na 5 dni, puste foldery nie są już tam kompresowane

celem archiwum w porównaniu do przyrostowego, jest mały rozmiar by go pobrać lub wysłać skryptem na maila

 

sprawdzę czy to samo umiem z update przyrostowym

Edytowano Marzec 22, 2016 przez kori (zobacz historię edycji)

[Piotr GRD 608]

Skoro już mnie naprowadziłeś na find (którego - mając mało wspólnego z linuxem nie używałem dotąd), to chyba będzie to jakoś tak:

find $toarchfiles -newermt 2016-01-01 -type f

Oczywiście datę możesz wprowadzić ze zmiennej.

 

Albo odwołać się można do daty modyfikacji pełnego rocznego backupu:

find $toarchfiles -newer fullstartyear.tar.gz  -type f

Choć to może być zdradliwe ze względu na różnicę - nawet wielominutową w przypadku dużej ilości danych - pomiędzy rozpoczęciem tworzenia tego rocznego archiwum, a zakończeniem jego tworzenia - w międzyczasie coś przecież mogło ulec zmianie i nie będzie wtedy uwzględnione.

 

 

// edytowałem, bo pierwotnie źle napisałem pierwszą linijkę, źle zrozumiałem instrukcje dotyczące -newerXY.

Edytowano Marzec 22, 2016 przez Piotr GRD (zobacz historię edycji)

[kori 29]

data modyfikacji ustawia się na faktyczną datę ostatniej modyfikacji, więc nie ma problemu

jednego nie rozumiem, w jakich sytuacjach które formy przypisania czy użycia zmienniej stosować, robilem to na wyczucie, zmienna="$innazmienna" - zmienna=$innazmienna - zmienna=${innazmienna} - zmienna="${innazmienna}"

 

wygląda na to że to już będzie finalna wersja archiwizera w wydaniu lokalnym, teraz by trzeba pomyśleć jak:

- wysyłać kopie na zewnątrz
- usuwać pliki z tarów pod windowsem bez psucia uprawnien, na powrót gzipać i przywrócić datę

 

 

Edytowano Marzec 23, 2016 przez kori (zobacz historię edycji)