Strategia backupu - co z czym.

[Rolej 58]

Cześć.

 

Pomału zaczynam poważnie zajmować się swoimi maszynkami. Testuje, działam pomału. W momencie, kiedy już rozwiązałem część problemów, doszedłem do etapu backupu. Fakt faktem - na serwerze jeszcze nie trzymam żadnych wrażliwych danych, jednakże niedługo będzie i taki moment, że te dane będą się znajdować.

 

Wiadomo - backup najlepiej rozproszony, nie tylko w jednej lokalizacji. Warto backupy szyfrować przed wysłaniem ich dalej? O czym jeszcze powinno się pamiętać przy tworzeniu systemu backupowego? Jak Wy rozwiązaliście ten system?

[blfr 225]

Sugeruję Tarsnapa. O ile nie masz bardzo dużo niepowtarzalnych, niekompresowalnych danych, to trudno będzie samemu zrobić coś sensowniejszego.

 

Jeśli masz, to patrzyłbym w stronę Google Cloud: Nearline + jakieś instancje do zarządzania tymi backupami.

[Gość Kamikadze]

Ja bym raczej nie trzymał backupu na cloudzie. Mam co do tego zawsze złe przeczucia. Albo fizyczny dysk twardy albo jakiś VPS / konto FTP pod backup.

[blfr 225]

Cloud jest zdecydowanie lepszy niż VPS. U porządnych dostawców masz zapewnioną replikację.

 

Jakieś taśmy w piwnicy, oczywiście, zawsze dobrze mieć.

[Rolej 58]

Mam drugą maszynę fizyczną, której jednym z zastosowań właśnie jest utrzymywanie backup. Backupowane są 3VMki KVM o średniej wadze ~5GB. Jako, że maszyna główna jest w SYS ma dostęp do 100GB FTP Backup - tam byście polecili to szyfrować, zanim wyśle? Jakie macie doświadczenia z tą usługą OVH?

[blfr 225]

Problem z tymi ftp-ami do backupów od OVH jest taki, że masz do nich dostęp z maszyny, którą backupujesz. Czyli jak ktoś Ci się włamie, to może też wyczyścić backupy.

[Rolej 58]

O ile sam dostęp do maszyny zabezpieczam (allow.hosts, logowanie po kluczu itp.) to fakt faktem, mogą być jeszcze jakieś luki, które cały czas staram się wychwytywać.

 

Wracając do szyfrowania danych - na chwilę obecną jest to w miarę skuteczna metoda, która w jakiś sposób ograniczy pole włamywaczowi do pozyskania danych z danego "pudełka"? Jeżeli tak - to czym najlepiej to zaszyfrować?

[blfr 225]

Tak, GPG. Możesz je łatwo pożenić z Duplicity czy podobnym narzędziem.

[Pan Kot 1535]

Wszystko zależy od tego jakie to dane i na ile duże są.

 

Ja mam osobiście coś takiego: 1 serwer główny i 1 serwer backupowy.

 

Serwer backupowy co określony czas (w moim przypadku jest to 4-5 w nocy codziennie) łączy się z main server za pomocą klucza SSH. Następnie robi rsync wszystkich plików, które chce zbackupować (rsync tutaj świetnie działa bo wykrywa zmiany w plikach i tylko je synchronizuje, a nie przesyła wszystko jak leci), a następnie robisz dumpa określonych baz MySQL, oczywiście w skompresowanej gzipem formie, i również zasysa do siebie.

 

Jest to świetne rozwiązanie do dużej ilości potencjalnie niewielkich plików (oraz binarek które się rzadko zmieniają), a także dobre podejście do małych-średnich baz danych.

 

W przypadku dużej ilości danych binarnych sugerowałbym nie używać rsynca, a spiąć to jakimś network filesystemem, np. glusterfs. W przypadku dużych baz SQL natomiast, dobrym pomysłem jest zwyczajna replikacja. Sam osobiście tego nie używam głównie z tego powodu, że te skompresowane bazy łącznie nie ważą więcej jak 100 MB, a rsync sprawdza się świetnie niepotrzebnie nie obciążając filesystemu, co by miało miejsce w przypadku glustera.

[ksk 67]

Popatrz na backuppc . Ja z tego korzystam do backupowania paru serwerów po rsyncu .

[Rolej 58]

Powrócę do tematu i przedstawię Wam jak to poczyniłem, ewentualnie nakreślicie mi gdzie mogę popełniać błąd. Co drugi dzień robione są snapshoty każdej VMki, które następnie są potraktowane do *.zip jako jeden plik. Transfer pliku prowadzę po SCP do serwera backupowego, gdzie są rozpakowywane i segregowane do odpowiednich folderów. Foldery na okrojonych uprawnieniach.

 

Teraz pytanie - szyfrowanie zrobić jeszcze na poziome serwera backupowanego czy zaszyfrować pliki na backupowym? VMki, nawet tworzone do .gz bezpośrednio przez Proxmoxa trochę ważą i obawiam się, że długo by to trwało zanim by VMka została zaszyfrowana przed wysłaniem.

[Bartosz Z 236]

Podmontować zasób sieciowy i szyfrować w locie? AES powinien sobie radzić z takim szyfrowaniem.

[Gość Kamikadze]

Prócz snapshotów rób dodatkowy backup plików i bazy. Może się stać (odpukać w czoło) że snapshot nie zadział. Musisz się zabezpieczyć też przed taką ewentualnością. Osobiście nie preferuję snapshotów tylko fizyczne dane na fizycznym dysku na fizycznym sprzęcie

[Rolej 58]

Prócz snapshotów rób dodatkowy backup plików i bazy. Może się stać (odpukać w czoło) że snapshot nie zadział. Musisz się zabezpieczyć też przed taką ewentualnością. Osobiście nie preferuję snapshotów tylko fizyczne dane na fizycznym dysku na fizycznym sprzęcie

Samą bazę zamieszam replikować w czasie rzeczywistym. Mówiąc o plikach - masz na myśli chociażby tarsnap czy synchronizacja plików via rsync i późniejsza ich kompresja? Wszystkie dane wiadomo, fizyczny sprzęt fizyczny dysk, a nie chmura.

[Gość Kamikadze]

tarsnap czy rsync - to już kwestia wygody i optymalnego działania.

[malu 460]

Zależy od potrzeb.

Jak masz dużo i chcesz centralnie to kontrolować i łatwo dodawać kolejne storage to bacula.
Jak chcesz łatwo i przyjemnie (z gpg bezpiecznie) robić inkrementalne kopie to duply + duplicity.

Jest też kilka nowych wynalazków np. bup, który do wykorzystuje cośtam z git'a do deduplikacji. Jest też borg, który podobno działa już całkiem stabilnie.

[Rolej 58]

Musze przyznać, że wszystkie Wasze rozwiązania podane są fajne, aczkolwiek przeanalizowałem propozycje dot. Duply + Duplicity i na dzień dzisiejszy jest to strzał w dziesiątkę. Dzięki Wam wielkie za pomoc

[Gość nrm]

Zamiast duply -> rdiff-backup

[ksk 67]

@malu

Chyba chodziło Ci o burp ?

[Gość nrm]

Nie, chodziło mu o bup/bup.

[Rolej 58]

Zamiast duply -> rdiff-backup

A jak z szyfrowaniem?

 

Wracając do duply - przy wysyłaniu backupu (jeden plik 5GB+) on dzieli je na kilkaset malutkich plików *.gpg - to normalne?

[Gość nrm]

"rdiff-backup is a backup program similar to duplicity in some ways. Like duplicity, it uses the rsync algorithm for bandwidth and space efficiency, but instead of storing data in encrypted archives, it creates a mirror on the remote system."

 

http://www.bitflop.dk/tutorials/choosing-a-new-backup-solution-duplicity-rdiff-backup-or-rsnapshot.html