Podgląd pojedynczego posta
Stary 27.12.2012, 18:29   #101
pali
Թ
 
Avatar użytkownika pali
 
Data rejestracji: 14.02.2003
Posty: 3,066
pali wyróżnia się na forum <450 - 549 pkt>pali wyróżnia się na forum <450 - 549 pkt>pali wyróżnia się na forum <450 - 549 pkt>pali wyróżnia się na forum <450 - 549 pkt>pali wyróżnia się na forum <450 - 549 pkt>
Zainspirowany tym tematem przerobiłem swój backup. Opiszę jak to zrobiłem, może ktoś zauważy błąd a może komuś przyda się.

-------
Zabezpieczam produkcyjny serwer wystawiony do Internetu w różnoraki sposób. Generalnie prawie cała zawartość ~.

W poniższym modelu dla jasności pomijam takie rzeczy jak wykluczenie plików tymczasowych, wykluczenie plików nierelacyjnych baz danych do osobnego backupu, zatrzymywanie działających serwisów, synchronizacja backupu plików serwisu z ich bazami danych, no i sam backup relacyjnych baz. To wszystko zrobione.


1. Backup pełny - wykonaj każdego 28 dnia miesiąca
1.1 Wylistuj drzewo plików.
1.2 Każdy plik zapisz do tar (bez kompresji), zachowując strukturę drzewa.
1.3 Utwórz tabelę SQL o nazwie full-d-m-Y z kolumnami:
path - ścieżka do pliku
flag -tutaj zawsze flaga n (newfile)
fingerprint - hash zawartości pliku
privileges - uprawnienia w formacie 10-literowym
owner - właściciel pliku
group - grupa
filedate - data utworzenia pliku
compressor - kompresor właściwy dla pliku (gzip, bzip2, xz, packjpeg); znajduję go różnymi metodami
decompressor - dekompresor, zapisuję dla wygody, bo compressor daję z opcjami np. bzip2 -v9
cdate - czas utworzenia rekordu

* W całej tabeli pomijam kwestię hardlink, bo ich nie stosuję, ale gdyby program miał być uniwersalny - należałoby sprawdzać i-nody, liczbę dowiązań.

* Jak widać, w tabeli duplikuję informacje z tara: ścieżka i uprawnienia. Celowo. Objętość samej bazy jest nieistotna przy objętości tar, a takie dobrze poukładane informacje pozwolą na wygodne odtwarzanie, szukanie problemów, odtwarzanie częściowe etc

2. Backup różnicowy - wykonaj codziennie
2.1 Wylistuj drzewo plików
2.2 Utwórz tabelę SQL diff-d-m-Y (o strukturze jak dla full-d-m-Y)
2.3 Znajdź ostatnią tabelę full
2.4 Znajdź pliki ze zmienionym fingerprint
2.4.1 Zapisz te pliki do tar i utwórz dla nich rekord w tabeli z flagą c
2.5 Znajdź pliki, którym zmieniły się tylko uprawnienia lub czas
2.5.1 Utwórz dla tych plików rekord w tabeli (flaga p)
2.5 Znajdź w tabeli full pliki, których nie ma w drzewie plików
2.5.1 Przepisz ich rekordy z tabeli full oznaczając flagą d
2.6 Znajdź w drzewie plików te pliki, których nie ma w tabeli full
2.6.1 Zapisz je do tara oraz utwórz dla nich rekordy oznaczając flagą a

3. Archiwizacja - wykonaj codziennie po backupie
3.1 Skasuj pliki i tabele SQL backupu różnicowego starsze niż 31 dni
3.2. Skasuj pliki i tabele SQL backupu pełnego starsze niż 3 miesiące. Alarmuj gdy backupy pełne wyzwalane ręcznie zapełniły dysk.
3.3 Niezależnie od 3.1 i 3.2 jeszcze inna maszyna WAN kopiuje wszystkie backupy full i archiwizuje tyle ile starczy jej miejsca, kasując od najstarszych.

ad 3 Strategię archiwizacji muszę jeszcze przemyśleć. Brakuje streamera

No i tyle. Odtwarzanie polega na wgraniu odpowiedniego pełnego backupu i wybranego różnicowego - wraz z dekompresją wedle zapisów w tabeli. Przetestowałem, problemów nie znalazłem.

***10003; Stosowanie odrębnej kompresji pozwala przykładowo na taki zysk:
1,4 giga - tar bez kompresji
1,1 giga - tar z kompresją gzip lub bzip2 (to samo, bo główna masa to jpeg)
750 mega - kompresja dla każdego pliku z osobna

***10003; Dużą wadą wydaje mi się operowanie bez inodów. Np. zmiana nazwy potężnego katalogu powoduje codzienne kopiowanie potężnej ilości danych. Nie chciałem zbytnio komplikować zadania, bo wiem, że gdy będę potrzebował backupu, to będę wściekły... i chciałem jak najprościej. No ale może to jeszcze przepiszę, pomyślę.

Jako rozwiązanie powyższego problemu dałem sobie możliwość ręcznego wyzwolenia backupu full, który właśnie mogę uruchomić po dużych zmianach.

***10003; Mam dwa prawie identyczne CMSy. Mógłbym za pomocą hashy ładować ich pliki jednokrotnie. Ale to zbędna komplikacja, ktora zaoszczędzi 10 groszy miesięcznie. Niemniej myślę, że gdybym był hosterem... to może wykrywałbym podobne instalacje

***10003; Operowanie na plikach przebiega z użyciem SFTP. Ma to taką wadę, że generuje duży ruch między maszynami, ale moje obie maszyny są w szybkim LAN (rozległym, ale jednak LAN), więc no problem. W razie operowania WAN należałoby zalogować się do shella i tak liczyć fingerprint. Tak czy siak SFTP nieco spowalnia całkowity czas wykonania backupu i może powodować problemy w synchro jeśli backupujemy działający serwis.

***10003; Skrypty napisane proceduralnie w python. Logowanie odbywa się poprzez prosty print i dalej cron-sendmail. W przesyłanych logach są linki do ręcznego ściągnięcia paczek z backupem (przez nginxa z hasłem - to jedyny serwer na świat odpalony na tej maszynie). Do tarów dodaję też mysqldump z odpowiednimi tabelami. Jest też link do prostego html, który daje linki do aktualnie posiadanych paczek.
Logi można cudować cyzelować w nieskończoność

***10003; Niezależnie od backupu działa z crona innej maszyny zadanie, które sprawdza czy na serwerze backupowanym nie zmieniły się pliki, które zmienić się nie powinny. Też za pomocą hash.
pali jest offline   Odpowiedz cytując ten post