Przyrostowy backup

[bartek1 0]

Cześć

 

Od dłuższego czasu nosze się z zamiarem napisania systemu backup dla mojego hostingu. Im więcej mija czasu, tym więcj pomysłow pojawia się w mojej głowie.

 

Chce oferować backup przyrostowy, czyli dostęp do pełnego backupu z dowolnego dnia z ostatnich 30 dni.

Brzmi pysznie prawda? Niestety, przy głupich 300GB na pliki klientów, potrzeba już 9TB storagu na serwerze backup

Takie duże wartości póki co jeszcze przerażają, mam nadzieję, że za pare lat będą już takie pamięci masowe montować do serwerów, no ale dzisiaj są po 500GB, więc trzeba kombinować.

 

 

Wpadłem na stosunkowo prosty pomysł jak zredukować te 9000TB do nieco powyżej 500GB

Słowo klucz to: "Dziedziczenie plików"

Sporządzamy z każdego pliku każdego klienta sume kontrolną, przy codzinennym procesie backupowania system będzie posiadał pełną listę plików i sume kontrolną każdego z nich i nie będzie ich zastępował, do serwera backup będą dorzucane tylko te pliki których sum kontronych nie ma w bazie.

 

Hipotetyczna styuacja:

Może zaistnieć sytuacja, gdzie dwóch osobnych klientów będzie miało czyste joomle, backup tego drugiego zawierał będzie wyłącznie jeden plik który go różni od backupu pierwszego, konkretnie config.php, w idealnej sytuacji kompletnie nic nie zmieni się w plikach przez całe 30 dni, więc nasz backup przyrostowy nie przyrosnie ani o bit, nie licząc oczywiście backupu baz danych..

 

Mieszanie backupów wszystkich klientów razem brzmi jak szaleństwo, ale powinno się opłacić.

Jeśli idzie o backup baz danych, to troche boje się kombinować i chyba zostanie przy uczciwym pełnym przyrostowym backupie, chociaż też możnaby sprawdzać tabelami, czy coś się nie zmieniło,

No ale oczywiście już tylko w ramach każdego klienta osobno, w końcu sytuacja w której dwóch klientów ma takie same bazy czy nawet takie same tabele jest bardzo mało prawdopodobna, że o różnych kodowaniach nie spomne.

 

 

Co wy na to?

[ahes 83]

Dobrze kombinujesz, ale z tymi 9TB trochę przesadziłeś. Możesz zrobić to na dwa sposoby.

Pierwszy to rdiff-backup i uzyskujesz kopię przyrostową dla każdego klienta. Aby odtworzyć backup z danego dnia także musisz użyć komendy rdiff-backup. Pętla for, backup per klient, jakieś udostępnianie, zarządzanie i będzie.

 

Druga opcja, którą stosujemy na Rootnode to snapshotowy backup przyrostowy. Aby zrobić go dla klientów wymaga trochę sprytu i kodu w perlu, ale idea polega na wykorzystaniu hardlinków do plików (aby danych które się nie zmieniły nie dublować w snapshotach z ostatnich 30 dni) oraz rsync - aby nie przerzucać przez sieć całych plików, a tylko zmienione fragmenty.

 

O tym jak to działa możesz poczytać na http://www.mikerubel.org/computers/rsync_snapshots/. Sam skrypt do zarządzania tym zmieściłem w 165 liniach perla, więc nie jest to nic skomplikowanego - trochę myślenia jest przy listach include/exclude, bo kolesie z rsynca nieźle to zamotali.

 

Podejrzewam, że przy 300G backupie w miesiąc urośnie ci najwyżej 10% więc specjalnie duży storage nie jest potrzebny.

Do tego trzeba jeszcze dorzucić dumpy baz danych, ale to już inna historia.

[p 3]

ZFS + snapshots.

[Dariusz Cieślak 3]

Pierwszy to rdiff-backup i uzyskujesz kopię przyrostową dla każdego klienta. Aby odtworzyć backup z danego dnia także musisz użyć komendy rdiff-backup. Pętla for, backup per klient, jakieś udostępnianie, zarządzanie i będzie.

Polecam jeszcze opcję duplicity - backup jest składowany w plikach tgz. Można nałożyć szyfrowanie, więc backupy są bezpieczniejsze.