System codziennych kopii dla dużej ilości danych

[Janek86 0]

Witajcie!

Potrzebuję porady co zrobić z backupem w firmie. W chwili obecnej firma stoi na 9 serwerach, dość przeciętnych maszynach - wszystko to jest backupowane przez rsnapshot na 3 maszyny backupowe. Na każdy backup przypadają 3 maszyny produkcyjne. Działa to sobie całkiem ok. Mam przyrostowy backup z 7 ostatnich dni, średnio na każdym produkcyjnym serwerze jest ok. 1TB danych. Całość backupu rsnapshot trwa ok. 5 godzin. Wszystko jest niby ok.. Ale nastała konieczność zmiany serwerów - będą dużo mocniejsze, bardziej pojemne itd. Chcemy upchnąć 9 starych serwerów na 3 nowe. Dojdzie też trochę danych - generalnie na każdy serwer produkcyjny będzie ok. 4TB danych. Sprzęt również na backup będzie mocniejszy, ale obawiam się, że proces backupu będzie trwał koszmarnie długo.. Czy może ktoś polecić rozwiązanie backupowe które pozwoli na trzymanie kopii z deduplikacją które będzie bardziej wydajne? Próbowałem dziś testować r1 soft, ale obsługiwane kernele są dość stare, serwery stoją na ubuntu server. Nie chcę downgrade kernela do wersji z przed 2 lat robić...

[murgal 0]

Pytanie co backupujesz, bazy, pliki ? Wirtualizujesz ?

 

Jeśli bazy to zrzut lokalny i wysyłka różnicowa, jeśli VM to veeam?

Edytowano Sierpień 18, 2016 przez murgal (zobacz historię edycji)

[Janek86 0]

Baz trochę jest, ale zrzucam je skryptem do katalogu lokalnie, a potem wszystko zbiera rsnapshot i zrzuca to na serwery backupowe. Część serwerów to obsługa stron, zewnętrznych i wewnętrznych w firmie - czyli prawie że typowy hosting, 2 serwery to serwery poczty, reszta - repozytoria plików, trochę owncloud. Generalnie dużo różnych danych, raczej jest sporo małych plików w tym wszystkim. Łącznie ok. 8TB danych, z dzienną dynamiką zmian rzędu 50-100 GB. Czyli całość backupu z 7 ostatnich dni zajmuje poniżej 10TB.

Chodzi mi o to, czy jest coś bardziej wydajnego niż rsnapshot, który rsynca robi dość szybko, bo 1-3h w zależności do serwera, ale potem przez pare godzin leci sobie to cp -al.. Zajrzałem w dzisiejsze logi z backupów - dla jednego serwera cp -al robiło się 5 godzin + rsync 2 godziny.

Nacisk z góry jest taki, żeby produkcje upchnąć w 3 mocnych serwerach, a backupy na jednym, serwery będą mocniejsze, ale mimo wszystko IO ma jakieś ograniczenia i spodziewam się że całość procesu backupu zajmie wtedy spokojnie ze 12-16 godzin, co mnie trochę przeraża bo jak użytkownicy mi poszaleją to pewnego dnia może doby zabraknąć na zrobienie pełnego backupu..

[kori 29]

kompresja czasami pomaga zaoszczędzić czas

szczególnie przy dużej ilości małych plików

[areq 0]

Zfs z kompresja + snapshoty + rsync

[murgal 0]

Backupy w jednym miejscu to BARDZO zły pomysł na którym nie jeden już się przejechał.

 

Ale mimo wszystko, jak chcesz upchnąć na mocnych serwerach ja bym naciskał na wirtualizację (którą pewnie planujesz ze względu na konsolidację?) i na veeama, zepnij go w tej samej szafie na linkach 10gbps jak masz możliwość. Sam kilka baz MSSQL kopiuje lokalnie i wysyłam Cobianem na na serwer który potem w kilka miejsc wysyła kopię, ale po testach veeama raczej pójdę w jego stronę.

 

 

Edytowano Sierpień 19, 2016 przez murgal (zobacz historię edycji)

[Janek86 0]

Obawiam się, że szukam czegoś czego nie istnieje Snapshoty całych woluminów mało mi się sprawdzą, gdyż często potrzebuję odzyskać pojedynczy plik z któregoś dnia wstecz.. Ten backup jest przede wszystkim dla użytkowników serwerów czyli ktoś coś usunął, dzwoni i mówi, że chce coś odzyskać..

VMki mogę postawić - ale funkcjonalnie są 3 rzeczy na serwerach - hosting, poczta, pliki - czyli tak na prawdę na jednym serwerze fizycznym postawiłbym jedną vmkę.. Mogę to podzielić i pomieszać po serwerach, ale nadal backup vmki da mi odtworzenie całej vmki na raz.

 

O backupy backupów się nie martwię serwery backupowe są trzymane w innej części budynku oraz raz w tygodniu z serwerów backupowych dane są wysyłane rsyncem do wynajętych dedyków w DC. Dla zabezpieczenia danych wystarczy w przypadku totalnego padu. Jak ogarnę połączenie rclone z ovh object storage to będę chciał jeszcze tam backup wysyłać.

[hemi 20]

Generalnie w tym przypadku najlepiej sprawdziłby się ZFS + rsync z opcją --inplace jak ktoś wyżej sugerował. Snapshoty w ZFS działają bardzo dobrze (w zasadzie nie znam innego systemu plików z tak dobrą obsługą snapshotów), żeby się dostać do kopii z danego dnia wystarczy jedno polecenie zfs, znapshoty działają przyrostowo a więc trzymają tylko deltę zmian między kolejnymi dniami. ZFS obsługuje deduplikację choć w jej przypadku trzeba serwera z dość dużą ilością pamięci RAM. Do tego masz sprawdzanie poprawności danych w czasie rzeczywistym, możesz w każdym momencie uruchomić też scruba, który sprawdzi na żądanie poprawnośc danych blok po bloku (w tym momencie nadal możesz komfortowo korzystać z systemu bez zauważalnego spadku wydajności) etc etc etc.

 

Generalnie FreeBSD obsługuje natywnie ZFSa, na linuksa istnieje projekt ZfsOnLinux (używam go w takiej konfiguracji na proxmoxie i nie odnotowałem na razie żadnych problemów aczkolwiek nie zalecałbym go jeszcze w przypadku bardzo wrażliwych danych).

 

Mając dane na zfs'ie lokalnie + zfs na serwerach zdalnych możesz również przesyłać całe datasety danych (lub ich snapshoty przyrostowo) zamiast kopiować rsynciem plik po pliku przez sieć co też w jakiś sposób przyspieszy przesył danych.

Edytowano Sierpień 19, 2016 przez hemi (zobacz historię edycji)

[Janek86 0]

Hmm.. Wpadłem teraz na pomysł (albo to jest to o czym piszecie, a ja tego nie łapię). Naprowadźcie mnie na prawidłową ścieżkę jeśli gadam głupoty. Kiedyś przez chwilę używałem ZFS na FreeBSD ale nie zagłębiałem się za bardzo w to. W tym przypadku chyba będzie trzeba napisać jakieś własne skrypty do tego, ale to jest do przeżycia

Na serwerze backupowym stawiam sobie np. FreeBSD żeby nie kombinować z ZFS na linuksie. Stawiam tam ZFS i dla każdego serwera np. osobny wolumin.

Z serwera backupowego odpalam rsync i robię backup danych na serwer backupowy z włączoną jakąś lekką kompresją co powinno mi przyspieszyć trochę rsync.

Po zakończeniu rsync - robię sobie snapshot z poziomu ZFS i mam zapisany stan z danego dnia - odpada mi kilka godzin tworzenia hardlinków. W razie potrzeby montuje sobie snapshot z któregoś dnia i mam dostęp do danych archiwalnych. Rozwiązanie wydaje mi się być bardzo dobre i znacznie powinno skrócić czas robienia backupów.

 

Chyba nawet znalazłem narzędzie, które coś takiego robi:

https://github.com/adlibre/adlibre-backup

[hemi 20]

Skryptu nie kojarze ale jeśli sie sprawdzi to ok. Osobiscie uzywam zwyklego rsynca + na serwerze backupowym mam doinstalowaną paczkę skryptów zfstools, która zawiera miedzy innymi skrypt zfs-auto-snapshot. Ten skrypt konfigurujesz w ten sposob, że dodajesz go do crona z odpowiednimi parametrami i zapominasz. On automatycznie tworzy nowe snapshoty i wykonuje autorotacje snapshotow (usuwanie starych snapshotow). Potem dla każdego datasetu zfs, który chcesz miec automatycznie snapshotowany ustawiasz parametr zfs i tyle.

zfs set com.sun:auto-snapshot=true nazwa/datasetu/zfs

[Janek86 0]

Super. Dzięki wielkie za pomoc. Już sobie postawiłem testowe freebsd, robi mi się testowy rsync z 2 produkcyjnych serwerów, potem sobie te snapshoty pokonfiguruje. Myślę, że to jest właśnie to czego szukałem

[przemon 35]

Jaki masz storage na backupie i jaki filesystem?

Czas cp -al jest uzależniony od ilości plików które musi hardlinkować dziennie a nie od wielkości wolumenu.

Dla 1TB i 27mln plików robi mi rsnapshot na jednym serwerze 1h10min (RAID-1 mdadm + lvm)

Dla porównania na drugim mam 2mln plików i 13TB danych i cp -al robi się w 11 minut )RAID-6 mdadm+lvm).

Sprawdź czy czasem problem nie leży w I/O bo np kiedyś wziąłem HW RAID na jakimś kontrolerze ARECA i cp -al robił się dla 23mln plików 5h.

 

BTW snapshoty też możesz co prawda mniej wydajnie bez ZFSa odpalić via lvm.

 

[Janek86 0]

Wszędzie było ext4. Problem leży zdecydowanie w IO i spodziewałem się że nowy sprzęt będzie miał dużo większą moc przerobową, ale na nowym sprzęcie będzie też backupowane kilka razy więcej danych, więc zysk z większej wydajności zostanie skompensowany przez większą ilość danych do przerobienia.

Generalnie postawiłem sobie vmkę na testy na freebsd, zrobiłem testowe backupy na vmce najmniejszych serwerów i snapshoty z zfs na freebsd. Działa pięknie. Lada dzień zamawiamy nowe serwery i już jestem spokojny, że będzie wszystko działało Dzięki jeszcze raz.