ostatnio na tapecie archiwizacja danych

[kori 29]

ostatnio wszyscy poprawiają skuteczność archiwizacji, więc i ja się wziąłem
zauważyłem znaczące braki w spójności archiwizacji manualnej (pojedyncze pliki kopiowane z FTP)

 

skrypt skompletowano dzięki wskazówkom @Piotr GRD
wrazie padu lub przenosin na inny hosting, pełne archiwum i tylko ostatni z update'ów, update 5dni mozemy wysłać na maila

w directadmin dodajemy do crona zadanie na wykonywanie raz dziennie, najlepiej w nocy:

"/home/katalogusera/domains/cron/archiwizer >/dev/null 2>&1" i kod przetestowany, uwagi logiki i kodu mile widziane

hosting="dowolnanazwajamamnazwehostingu";
konto="nazwakonta";
toarchfiles="*"
logstat="--exclude=logs/* --exclude=stats/* --exclude=awstats/* --exclude=ip/* --exclude=daneIP/* --exclude=statx/*"


Y=`date +"%Y"`; homedir=/home/$konto;
M=`date +"%m"`; archdir=$homedir/tmp; mkdir $archdir &> /dev/null
D=`date +"%d"`; cd $homedir/domains;

lastdayfile=${archdir}/${Y}_${hosting}_5daychange
updatefile=${archdir}/${Y}_${hosting}_update
yearfile=${archdir}/${Y}_${hosting}_full.tar.gz

#- pełne archiwum roczne:
if [ ! -e $yearfile ]; then tar czf $yearfile --exclude-from=$homedir/domains/cron/archiwizer.no $toarchfiles; fi


#- update przyrostu rocznego, z pozostawieniem: z każdego 1 dnia miesiąca i 4 ostatnie update
mv ${updatefile}3.tar.gz ${updatefile}4.tar.gz &> /dev/null
mv ${updatefile}2.tar.gz ${updatefile}3.tar.gz &> /dev/null
mv ${updatefile}_last.tar.gz ${updatefile}2.tar.gz &> /dev/null
find $toarchfiles -newermt `date -r $yearfile +%F` -type f | tar czf ${updatefile}_last.tar.gz --files-from=/dev/stdin --exclude-from=$homedir/domains/cron/archiwizer.no
if [ $D == 1 ]; then cp ${updatefile}last.tar.gz ${archdir}/`date +"%F"`_${hosting}.tar.gz; fi


#- update codzienny, zmian z 5 ostatnich dni, z pozostawieniem 3 ostatnich
mv ${lastdayfile}2.tar.gz ${lastdayfile}3.tar.gz &> /dev/null
mv ${lastdayfile}_last.tar.gz ${lastdayfile}2.tar.gz &> /dev/null
find $toarchfiles -mtime -5 -type f | tar czf ${lastdayfile}_last.tar.gz --files-from=/dev/stdin --exclude-from=$homedir/domains/cron/archiwizer.no $logstat

co tam ciekawego jeszcze można zrobić:

- wykluczyć maile gdy archiwizujemy całość: --exclude=/home/$konto/imap --exclude=/home/$konto/Maildir
- archiwum wysłane na mail -s "archiwum stron z $hosting" mail@domena.pl < ${lastdayfile}1.tar.gz

 

uwagi:

- aby skrypt działał trzeba ustawić uprawnienia uruchamiania: 755 i zmienić nazwę konta na swoją
- przy archiwach z programu tar, jest utrudniony dostęp do pojedynczych plików, niestety przy użyciu innych będą problemy uprawnieniami/atrybutami

- wskazówki @Piotr GRD dotyczące baz danych

"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 23, 2016 przez kori (zobacz historię edycji)

[Gość Spoofy]

Eeee... wróć, replay, jeszcze raz....

 

Że co Ty tym robisz?!

Przecież od tego typu rzeczy jest :
- bacula
- ninjabackup

- duply

- *paste any awesome backup script from github here*

 

Więc w sumie.... uczysz korzystać z tar'a i wykonywać polecenie cron'em?

Jak automatycznie archiwizować "bazy danych"? Jak mysql to np. mysqldump + gzip | bzip | tar - whatever?

Rotacja archiwów? find + rm/mv?

[Pan Kot 1535]

A może zamiast wynajdywać koło na nowo, i jeszcze robiąc to w nieudolny sposób, zainteresujesz się chociażby tym jak działa rsync? Bo to co napisałeś stoi na tym samym poziomie użyteczności co większość twoich postów tutaj .

[Gość Rafiki]

you made my day

[kori 29]

@Archi ty isniejesz tylko by trolować? napisałeś rsync,

więc podaj jak mam to na hostingu użyć, czy w cron czy jak

 

zamiast jęczeć dyskutuj, do tego stworzono fora

[Bartosz Z 236]

Sam jestem ciekaw, jak użyć rsynca, Baculi i innych wymienionych narzędzi na hostingu z DA i cronem, bez SSH
Kori, zamiast wrzucać tyle exclude'ów w linii poleceń, to możesz je zapisać w pliku.

Edytowano Marzec 18, 2016 przez Bartosz Z (zobacz historię edycji)

[kori 29]

one nie są w linii poleceń, w pliku: /home/katalogusera/cron/arc_full_new
sądzisz że za długiej komendy nie strawi? nie znam linuxa, w dos chyba było do 128znakow

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

[Bartosz Z 236]

Po prostu plik z listą wykluczeń byłby wygodniejszy w edycji i czytelniejszy

[Gość Spoofy]

Sam jestem ciekaw, jak użyć rsynca, Baculi i innych wymienionych narzędzi na hostingu z DA i cronem, bez SSH

Kori, zamiast wrzucać tyle exclude'ów w linii poleceń, to możesz je zapisać w pliku.

 

Przecież dobry shared hosting ma dostęp do SSH gdzie standardowo masz tools'y w stylu : mc, git, curl, wget, rsync, tar, bzip, gzip, zip etc.

 

Na dodatek w DA przecież każdy user może sobie ustawić backup....

 

Jeżeli chcemy to zrobić trzymając się jedynie standardów POSIXowych no to kłania się standardowa znajomość poleceń powłoki i/lub szukania google/github - przecież tego jest od groma...

 

Apropos exclude'owania:

 

nie lepiej po prostu source'ować plik/listę z exclude'ami i zwkyłym for'em to wypluć?

[kori 29]

konkrety, jak automatyzujesz podanymi narzędziami archiwizację,

żeby za każdym razem nie odpalać ssh czy directadmina

 

co do excludów, nie wiem po co tworzyć 2 pliki zamiast mieć wszystko w jednym

[Bartosz Z 236]

Przecież dobry shared hosting ma dostęp do SSH gdzie standardowo masz tools'y w stylu : mc, git, curl, wget, rsync, tar, bzip, gzip, zip etc.

 

nie lepiej po prostu source'ować plik/listę z exclude'ami i zwkyłym for'em to wypluć?

 

Być może

 

Jeśli chodzi o listę wyjątków w pliku, to miałem na myśli:

Use the `--exclude-from' option to read a list of patterns, one per line, from file; tar will ignore files matching those patterns.

 

[Gość Spoofy]

konkrety, jak automatyzujesz podanymi narzędziami archiwizację,

żeby za każdym razem nie odpalać ssh czy directadmina

 

co do excludów, nie wiem po co tworzyć 2 pliki zamiast mieć wszystko w jednym

 

konrkety to bash + conf + cron

 

Chcesz żebym Ci napisał skrypt? Sorry, piję piwko bo jest piątek wieczór, chyba że mi zapłacisz 200zł/ h xD

 

A tak serio to jak wbiję na jakiś serwer na którym nie używam w/w narzędzi to wkleję tutaj jak tak bardzo chcesz

[Pan Kot 1535]

Kolego, man rsync - to jest konkret. Rusz cztery litery i naucz się z niego korzystać, bo my śmigamy w samochodach a ty kleisz swój pierwszy rower z gliny i kleju.

 

Pomijając już nawet całkowitą nieprzydatność tego co napisałeś, to mi nawet nie chciałoby się czasu marnować na pisanie skryptu czy polecenia kiedy dokładnie to samo robi za mnie rsync + mysqldump. I nawet nie wspominam tutaj o bardziej egzotycznych skryptach i narzędziach, o których powiedział ci Spoofy.

Edytowano Marzec 19, 2016 przez Archi (zobacz historię edycji)

[kori 29]

znow czepiasz się zamiast dyskutować, kiedy nauczysz się że jesteś na forum?
ja swoją metodę zaprezentowałem, dla mnie skuteczna i innej nie chcę, poddałem myśli rozwinięcia
cel? pomoc innym którzy jeszcze nie archiwizują, ty z braku wiedzy podałeś wyłącznie nazwę

przywołujesz z nim narzędzia, jesteś pewien że działają z cron na każdym hostingu?
podaj przyklady: jak kompresujesz nimi dane do jednego pliku i jakie dodajesz zadanie/skrypt do crona

 

 

Edytowano Marzec 19, 2016 przez Gość (zobacz historię edycji)

[Gość l3szcz]

Directadmin - rsync razem z wcześniejszym pakowaniem w .tar.gz pomiędzy serweram A i B a jak wiadomo Directadmin jest na większości polskich hostingów.

Rsync jest na prawdę dobrym narzędziem i ma potężne możliwości. Wystarczy poczytać man a nie liczyć na gotowce

Wracając jednak do Twojego skryptu. Może i on działa ale nie jest on optymalnie napisany. Rsync ma o wiele więcej do zaoferowania w tej kwestii.

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

[Gość Kamikadze]

Po gotowce można iść do wujka google.

[kori 29]

rsync jest zdaje cię programem do synchronizacji danych, nie do archiwizacji
bardziej przydatny administratorom serwerów lub ogromynch serwisów

i nadal powątpiewam czy na każdym hostingu z crona da się uruchomić

ja archiwizuję na tym samym hostingu automatycznie cronem i mam tam kilka kopii,

od czasu do czasu pobieram sobie którąś z kopii poprzez ftp na kompa,

jak będę chciał automatycznych kopii na innym serwerze to też nie rsync'em, tylko prostym skryptem php

 

[Gość Pokuć]

@up, to w jaki sposób pobrać pliki zdalnej kopii na dysk twardy skoro FTP powinno dawno umrzeć?

Rsync tworzy kopie, użytkownik co określony czas którąś tam kopie pobiera na dysk twardy.

[kori 29]

@samu

RSYNC miałby dla mnie sens i wtedy i tylko wtedy gdyby:
robił pierwszą główną kopię, potem tylko dogrywał do archiwum skompresowanego i opisywał datą zmian
wchodzę w archiwum rsync z 5 stycznia i pokazuje mi wszystko tak jak było 5 stycznia
wchodzę w 10 stycznia i pokazuje mi wszystko co miałem 10 stycznia

ale jak rozumiem tylko porównuje daty i kopiuje zmienione pliki

 

co do SSH, to jest odwrotnie niz mowisz, większość hostingów nie daje ssh, ze względów bezpieczeństwa

albo trzeba wziąć droższy/większy pakiet np. hitme 228zł, mydevil.net 150zł, gdzie standardowa cena to 50zł

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

[Piotr GRD 608]

Bazując na wielu wcześniejszych tematach koriego - mówi on o "hostingach" ; ), jak to ująłeś samu.

Wiele maluczkich osób nie ma wielkich wymagań i korzysta z najtańszych możliwych (lub wręcz darmowych) rozwiązań. Sam też korzystam z takich, gdzie dostępu po SSH nie ma, ba, na jednym nawet nie ma cronjob.

 

kori, podpowiem Ci może co ja robię w przypadku, gdy ogólna ilość plików na serwerze jest względnie duża, ale tych zmieniających się, dodawanych na bieżąco względnie mało.

 

Mianowicie pełny backup plików dokonywany jest rzadziej, a częściej tylko ten z plikami zmodyfikowanymi później niż wyznaczona data. Korzystając z tar dodaję argument --newer-mtime=... A jako że w moim przypadku w ogóle są to niewielkie rozmiary, bazy danych (zrzucane za pomocą mysqldump) i archiwum .tar.gz z tymi zmodyfikowanymi plikami wysyłam sobie emailem na dwie różne skrzynki pocztowe (nawet darmowi usługodawcy udostępniają wystarczająco duże skrzynki, a dość małe jest prawdopodobieństwo, że nagle znikną dwa serwisy naraz, więc dane są relatywnie bezpieczne). Pełen backup pobieram raz na rok lub rzadziej i wtedy też zmieniam datę dla archiwum z plikami zmienionymi. W razie potrzeby odzyskania danych przywracam ten pełen plus zmienione pliki i najnowszą bazę danych z emaila.

 

Przy większej ilości danych zmienić by trzeba sposób przesyłania danych na zewnątrz (bo nic Ci nie da backup trzymany tylko na tymże tanim hostingu, jeśli on padnie na dłuższy czas lub zniknie w ogóle, a ręczne pobieranie na dłuższą metę się nie sprawdza w żaden sposób).

 

Archiwa przechowuję też oczywiście lokalnie na tymże hostingu. W razie czego szybciej można przywrócić wszystko bez konieczności wgrywania backupów z zewnątrz (np. gdy osoba korzystająca ze strony/forum/bloga coś namiesza, przez przypadek skasuje wszystkie posty itp.). W przypadku baz danych kopia wykonywana co 24 godziny, te starsze niż powiedzmy tydzień usuwane prostym skryptem.

 

 

To wszystko oczywiście rady dla 'maluczkich', którzy mają jakieś tam strony ważne dla siebie, ale już nie tak ważne patrząc obiektywnie, by koniecznie wdawać się w bardziej profesjonalne rozwiązania, które mogą kosztować więcej (np. droższy - czyli więcej niż 30zł rocznie - hosting dający dostęp SSH) lub wymagać więcej czasu na poznanie sposobu działania (3 linijki wykorzystujące tar/gzip/mysqldump plus gotowy skrypt wysyłający emaila i kasujący starsze archiwa - to opanować można i zaimplementować szybciej, niż poznawanie rsync i podobnych systemów).

 

 

 

PS.

- denerwuje mnie otwieranie archiwów "bz2", program 7zip rozpakowuje duzy plik dopiero potem można do niego wejść i sprawdzić pliki, może istnieje jakiś program dla Windows, który odrazu pokazuje zawartość takiego archiwum i pozwala wyciągnąć pojedynczy plik

 

Tego raczej nie przeskoczysz. Bo sposób działania jest taki, że tworzone jest archiwum .tar - czyli wiele plików łączonych jest w jeden duży - a następnie tenże duży plik jest kompresowany - czy to wykorzystując gzip czy bz2. W drugą stronę *musi* nastąpić dekompresja (chociażby tylko do pliku tymczasowego), by móc zajrzeć do archiwum .tar i z niego cokolwiek wydobyć.

 

Musiałbyś zmienić sobie sposób tworzenia archiwum, wprowadzić kolejność odwrotną niż domyślna. Najpierw kompresja każdego pliku osobno, a dopiero potem z nich tworzenie .tar. Do późniejszego przywracania danych też jednak musiałbyś mieć podobnie działające indywidualnie stworzone narzędzie (chyba, że już ktoś zrobił coś takiego gotowego, nie wiem).

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

[Gość Spoofy]

rsync jest zdaje cię programem do synchronizacji danych, nie do archiwizacji

bardziej przydatny administratorom serwerów lub ogromynch serwisów

i nadal powątpiewam czy na każdym hostingu z crona da się uruchomić

 

ja archiwizuję na tym samym hostingu automatycznie cronem i mam tam kilka kopii,

od czasu do czasu pobieram sobie którąś z kopii poprzez ftp na kompa,

jak będę chciał automatycznych kopii na innym serwerze to też nie rsync'em, tylko prostym skryptem php

 

 

Chcesz konkretny hosting z dostępem po SSH i z możliwością uruchomienia rsync? Całość stoi na LiteSpeed Enterprise, możesz sobie nawet odpalić wydajnie PHP7 przez lsapi, a całość stoi na CloudLinux'ie i zarządzana jest DirectAdmin'em (w którym też jest opcja backup'u)

 

No ale w kwestii backupów, to są one robione dla całego hostingu i np. jak klientowi zapieprzą taki oto syf na całym koncie z 20stoma prestami/wordpress'ami : https://blog.sucuri.net/2016/02/massive-admedia-iframe-javascript-infection.html#comment-2508174174 , albo jego "majszter programiszta" usunął co nie trzeba bo nie potrafi używać git'a, to przywracamy bez problemu

 

Ba! Nawet dam Ci kupon rabatowy! Zgłoś się na pw

 

A rsync? No tak, służy do "synchronizacji", a "synchronizować" (bardzo ładne to słowo ) możesz wiele rzeczy i na wiele sposobów, do tego bardzo wydajnie

[kori 29]

@Piotr GRD chociaż jedna kompletna i rzeczowa wypowiedź w tej dyskusji, a nie w kółko rsync ;p
"tar dodaję argument --newer-mtime=" nie znałem napewno przyda się, dodałem do pierwszego postu wnioski

nie mają problem dostepu do pojedynczych plików: zip i 7zip (brak wsparcia w directadmin)

7zip ma najlepszy współczynnik kompresji na świecie, a 64bit z dużymi słownikami jeszcze lepiej wychodzi, ale okupione to olbrzymią ilością pamięci

7zip na linuxpl jest, jak sądzisz czy pozostałe hostingi też mają lub doinstalują na zyczenie? i czy zachowuje on uprawnienia/atrybuty plików

plików: 69759, na dysku z windows: 394 591 665, bzip2 (102 921 413), 7zip: 96 269 951,
tar (307 077 120) coś sporo większy od plików bez kompresji: 243 155 399

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

[Piotr GRD 608]

Czyste nieskompresowane archiwum tar będzie większe niż rozmiar składowanych w nim plików, w końcu trzeba jeszcze zachować informacje o strukturze folderów, o uprawnieniach każdego, datach modyfikacji itp.

 

Co do 7zip... Chyba nie do końca odróżniasz format archiwum 7z od sposobu kompresji.

 

Format archiwum 7z nie przechowuje uprawnień plików właściwych dla danego systemu plików, nie zachowa więc informacji o użytkownikach/grupach UNIXowych, ani ACL w systemie NTFS itp. Dlatego nie nadaje się do tworzenia kopii zapasowych, o których tutaj mowa. Do tego musimy (powinniśmy) użyć formatu archiwum TAR.

 

Ale jeśli zauważyłeś, że kompresja oferowana przez 7zip jest lepsza, a zależy Ci na wielkości archiwum, to z powodzeniem możesz zastosować tę samą również i dla archiwów TAR. Domyślnie 7zip wykorzystuje kompresję LZMA (choć możesz też wybrać dla przykładu bzip2 lub zwykłe deflate). Z tego co wyczytałem TAR od wersji 1.20 ma również zaimplementowaną obsługę LZMA (opcja --lzma zamiast j dla bzip2 czy z dla gzip), a od wersji 1.22 również i LZMA2 poprzez xz (opcja --xz albo -J).

 

To jednak nie rozwiąże Twojego problemu (niedogodności) z koniecznością dekompresji takiego pliku przed wydobyciem czegokolwiek ze środka. Po prostu najpierw tworzone jest archiwum TAR, a dopiero potem całość kompresowana. Inaczej niż w archiwach 7z, ale ten format nie przechowa uprawnień.

 

Co do obecności na poszczególnych hostingach... nie wiem. Z rozpakowywaniem ZIP nigdy nigdzie nie miałem problemu, archiwów7z nigdy w sumie nie używałem.

[kori 29]

nie boj odrozniam 7zip i lzma, poprostu lzma jest domyślną metodą 7zip, od dawna kojarzę go z metodą lzma, nawet sądziłem że to autor 7zipa ją wynalazł, stąd dla mnie 7zip jest synonimem lzma, kilka wersji gry: (lzma-44MB, lzma2-118MB)

archiwum stron: pełne archiwum (bz2-177MB, lzma-172MB, gz-184MB), update roczny (bz2-87MB, lzma-84MB, gz-91MB), zmiany ostatniego tygodnia (bz2-3MB, lzma-2MB, gz-4MB)

1. czy zwykly zip też nie przechowa atrybutów/uprawnień
2. pojawił się kolejny problem w panelu directadmin, mozna wypakować tylko zip i tar.gz

 

no i kaplica po zmianie nazwy lzma archiwum na *.tar.gz nie da się rozpakować w directadmin
"gzip: stdin: not in gzip format /bin/tar: Child returned status 1 /bin/tar: Error is not recoverable: exiting now"

 

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

[Piotr GRD 608]

W formacie ZIP istnieje nagłówek "extra field", który może zawierać cokolwiek, ale nie wiem czy jakiekolwiek oprogramowanie zapisuje tam i odczytuje stamtąd UNIXowe uprawnienia plików. Nie wiem, nigdy nie zagłębiałem się w temat.

 

Jeśli menadżer plików w DirectAdmin rozpakowuje tylko archiwa TAR spakowane metodą GZIP, to pozostaje Ci takie właśnie archiwa tworzyć, albo rozpakowywać je później bezpośrednio tym samym TARem bez użycia menadżera DA. Przecież nie jesteś ograniczony menadżerem plików w DA, jeśli na jakimś hostingu możesz używać TAR do pakowania plików, to i możesz do rozpakowywania.

 

tar xf archiwum.tar
tar xzf archiwum.tar.gz
tar xjf archiwum.tar.bz2
tar xf archiwum.tar.lzma (albo: "tar xf archiwum.tar.lzma --lzma", nie jestem pewien, nie stosowałem)