Jak wykonać kopię zapasową serwera pamięci?

Zastanawiam się nad wdrożeniem bardzo dużego serwera pamięci masowej, który będzie używany jako żywy NAS dla kilku innych serwerów (wszystkie oparte na systemie Linux).

Przez bardzo dużą mam na myśli między 4 TB a 20 TB przestrzeni użytkowej (chociaż jest mało prawdopodobne, że faktycznie uzyskamy 20 TB).

Serwer pamięci będzie RAID 10 dla bezpieczeństwa danych i wydajności, ale nadal będziemy potrzebować rozwiązania do tworzenia kopii zapasowych, w tym tworzenia kopii zapasowych poza siedzibą.

Moje pytanie brzmi: Jak wykonać kopię zapasową tylu danych !?

To nie tak, że mogę po prostu podłączyć przenośny dysk twardy i przesłać pliki. Obecnie nie mamy innych urządzeń z tak dużą przestrzenią dyskową.

Czy muszę przeznaczyć budżet na drugi, zewnętrzny serwer pamięci, czy jest lepsze rozwiązanie?

Istnieje wiele sposobów przetwarzania danych o takiej wielkości. Wiele zależy od środowiska i ilości gotówki, którą chcesz wydać. Zasadniczo istnieje kilka ogólnych strategii „usuń dane z serwera”:

• Przez Ethernet Jak napisano na pudełku, dane są przesyłane strumieniowo do Some Where Else w celu obsługi. Kopiowanie ponad 1 GbE zajmuje 20 TB, ale można to zrobić. Pomocny może być sprzęt (taki jak łącza 10GbE lub w niektórych przypadkach łączenie NIC).
• Przez podsystem Storage Jeśli korzystasz z Fibre Channel, wyślij go do innego urządzenia w sieci FC. Jeśli masz SAS, wyślij go na urządzenie podłączone do SAS. Generalnie szybszy niż Ethernet.
• Wyślij do innej macierzy dyskowej Wyślij do innej części magazynu podłączonej do tego samego serwera.

To widok 100 km. Gdy zaczniesz powiększać, fragmentacja stanie się znacznie bardziej fragmentaryczna. Jak już wspomniano, LTO5 jest specyficzną technologią taśm zaprojektowaną do tego rodzaju obciążeń o dużej gęstości. Inna identyczna tablica pamięci jest dobrym celem, szczególnie jeśli możesz użyć czegoś takiego jak GlusterFS lub DRBD, aby uzyskać tam dane. Ponadto, jeśli potrzebujesz rotacji kopii zapasowej lub po prostu możliwości kontynuowania działania na wypadek awarii macierzy, wpłynie to na to, co umieścisz.

Gdy już zdecydujesz się na metodę widoku 100 km, przejście do oprogramowania będzie kolejnym dużym zadaniem. Czynniki mające na to wpływ, to przede wszystkim to, co można zainstalować na serwerze pamięci masowej (jeśli jest to NetApp, to jedno, serwer Linux z dużą ilością pamięci to zupełnie inna sprawa, podobnie jak serwer Windows z dużą ilością pamięci) , jaki sprzęt wybierzesz (na przykład nie wszystkie pakiety kopii zapasowych FOSS dobrze obsługują biblioteki taśm) i jakiego rodzaju przechowywania kopii zapasowych potrzebujesz.

Naprawdę musisz dowiedzieć się, jakiego rodzaju odzyskiwania po awarii chcesz. Prosta replikacja na żywo jest łatwiejsza, ale nie pozwala przywracać danych tylko z zeszłego tygodnia. Jeśli zdolność przywracania z ostatniego tygodnia jest dla Ciebie ważna, musisz zaprojektować coś takiego. Zgodnie z prawem (w USA i gdzie indziej) niektóre dane muszą być przechowywane przez 7+ lat.

Prosta replikacja jest najłatwiejsza do zrobienia. Właśnie do tego przeznaczony jest DRBD. Po wykonaniu wstępnej kopii, po prostu wysyła zmiany. Czynnikami komplikującymi są tutaj lokalizacja sieci, jeśli druga tablica nie znajduje się w pobliżu podstawowego DRBD, może nie być wykonalna. Będziesz potrzebował drugiego serwera pamięci z co najmniej taką samą ilością miejsca jak pierwszy.

Informacje o kopii zapasowej na taśmie ...

LTO5 może pomieścić 1,5 TB danych bez kompresji. Karmienie tych potworów wymaga bardzo szybkiego połączenia sieciowego, którym jest Fibre Channel lub 6 Gb SAS. Ponieważ musisz wykonać kopię zapasową ponad 1,5 TB w jednym uderzeniu, musisz zajrzeć do autoloaderów (oto przykład: link , 24-slotowy autoloader z 1 napędem od HP). Dzięki oprogramowaniu, które je obsługuje, poradzą sobie ze zmianą taśm w trakcie tworzenia kopii zapasowej. Oni są wspaniali. Nadal będziesz musiał wyciągać taśmy, aby wysłać je poza witrynę, ale to cholerny widok lepszy niż kręcenie się przez całą noc, aby samemu ładować taśmy, gdy wymaga ich kopia zapasowa.

Jeśli taśma daje ci „ starsze, nowe ” heebiegeebies, wirtualna biblioteka taśm może być większa niż twoja prędkość (na przykład ta z Quantum: link ). Udają, że są bibliotekami taśmowymi do tworzenia kopii zapasowych oprogramowania, a jednocześnie przechowują rzeczy na dysku za pomocą solidnych (masz nadzieję) technik usuwania duplikatów. Bardziej wymyślni skopiują nawet wirtualne taśmy do prawdziwych taśm, jeśli podoba ci się to, co może być bardzo przydatne w przypadku rotacji poza witryną.

Jeśli nie chcesz się pieprzyć nawet z wirtualnymi taśmami, ale nadal chcesz wykonywać kopie zapasowe bezpośrednio na dysk, potrzebujesz tablicy pamięci wystarczająco dużej, aby poradzić sobie z tym 20 TB, a także dowolną ilością danych o zmianie sieci trzymać. Różne pakiety kopii zapasowych radzą sobie z tym inaczej. Niektóre technologie usuwania duplikatów są naprawdę fajne, inne to hacky kludges. Osobiście nie znam stanu pakietów oprogramowania do tworzenia kopii zapasowych FOSS w tym obszarze (słyszałem o Baculi), ale mogą one być wystarczające. Wiele komercyjnych pakietów kopii zapasowych ma lokalnych agentów instalowanych na serwerach, których kopie zapasowe mają być tworzone w celu zwiększenia przepustowości, co ma wiele zalet.

Szafa grająca LTO-5? potrzebujesz od trzech do 15 taśm, aby poprzeć tę tablicę, co nie jest szalenie dużą liczbą. Szafa grająca zajmie się zmianą taśm, a dobre oprogramowanie do tworzenia kopii zapasowych (np. Bacula) będzie śledzić, które pliki znajdują się na której taśmie.

Warto również wziąć pod uwagę czas potrzebny do utworzenia kopii zapasowej systemu plików tak duży, ponieważ jest bardzo prawdopodobne, że FS zmieni się w tym okresie. W celu uzyskania najlepszych rezultatów bardzo pomocny byłby system plików obsługujący migawki, dzięki czemu można wykonać natychmiastową migawkę i wykonać pełne lub przyrostowe kopie zapasowe w tym przypadku, zamiast w systemie plików na żywo.

Prawdopodobnie powinieneś rozważyć tworzenie kopii zapasowej na dysku , ponieważ taśma zajmie dużo czasu, a ponieważ dostęp sekwencyjny, przywracanie potrwa wieczność.

Zdecydowanie skorzystaj z różnicowych lub przyrostowych kopii zapasowych - tylko tworzenie kopii zapasowych zmian, na dowolnej częstotliwości, która ma dla Ciebie sens.

Prawdopodobnie idealnym rozwiązaniem byłby drugi serwer o podobnej wielkości w innym miejscu , w którym przyrostowe kopie zapasowe są regularnie wysyłane, i które mogłyby zostać szybko zamienione, gdyby główny serwer kiedykolwiek zmarł. Jednak inną opcją byłoby użycie dysków wymiennych na miejscu, które są następnie zabrane poza miejsce przechowywania.

Gdy masz do czynienia z tak dużą ilością danych, sensowne jest również rozbicie kopii zapasowych na mniejsze zadania tworzenia kopii zapasowych, a jeśli nie można ich codziennie tworzyć, ustaw kolejność tworzenia kopii zapasowych, aby zestaw A był tworzony przez jeden dzień i ustaw B następny.

Zawsze myśl o procedurze przywracania . Utknęliśmy raz, gdy musieliśmy przywrócić plik z kilkuset gigabitowego zadania tworzenia kopii zapasowych, co wymagało dużo pamięci i dużo czasu na odbudowanie indeksu kopii zapasowych i przywrócenie. Ostatecznie nie mogliśmy go ukończyć w ciągu jednego dnia i musieliśmy zbudować dedykowany serwer przywracania, aby nasz główny serwer kopii zapasowych mógł kontynuować swoje nocne zadania!

--dodany--

Chcesz również pomyśleć o technologiach deduplikacji , które mogą zaoszczędzić ogromne ilości miejsca, nie tworząc kopii zapasowych tych samych informacji wiele razy dla wielu użytkowników. Wiele rozwiązań do tworzenia kopii zapasowych lub systemów plików oferuje deduplikację w ramach swojej funkcjonalności.

Najpierw wylicz ryzyko, przed którym chronisz. Niektóre typowe zagrożenia:

• Katastrofa: Coś bardzo niefortunnego dzieje się w całej witrynie.
• Błędy ludzkie (to ten, który zdarza się _wszystko_godzina_):
  • Ktoś decyduje się na korzystanie z możliwości „wymiany podczas pracy” serwera pamięci w sposób niezamierzony przez producenta.
  • Ktoś uruchamia proces, który dyskretnie uszkadza dane, których tworzenie kopii zapasowej odbywa się niezawodnie przez kilka miesięcy, zanim problem zostanie zauważony.
  • Ktoś usuwa ważny raport, który ma nastąpić za godzinę i jest wart tysiące dolarów.

Następnie oceń koszt różnych rozwiązań unikania ryzyka, np .:

• Zewnętrzna kopia zapasowa on-line (zdalne dublowanie): Zabezpieczona przed katastrofą, niektórymi (ale nie wszystkimi) błędami ludzkimi (wciąż jest on-line).
• Zewnętrzne miejsce przechowywania poza siecią (taśmy): Zabezpieczone przed katastrofą, trudne do szybkiego odzyskania danych.
• Kopie zapasowe online na miejscu (kopia lustrzana): Zabezpieczone przed jakimś błędem ludzkim, awarią sprzętu, podatne na katastrofę.
• Kopie zapasowe offline na miejscu (taśmy w zmieniaczu taśm): Bezpieczne od większości błędów ludzkich, większości awarii sprzętu.

Następnie oceń strategie rotacji (jak daleko chcesz być w stanie odzyskać, ile danych możesz stracić).

Następnie wybierz, jakie są twoje dane.

Mam klienta z dwoma podobnymi systemami 12 TB w dwóch różnych budynkach, podłączonymi do 1 GB. Jednym z nich jest system produkcji; kopia zapasowa jest tworzona stopniowo (z codziennymi migawkami) przy pomocy doskonałego narzędzia rdiff-backup . rdiff-backup musi być dostępny w standardowym repozytorium dystrybucyjnym.

Zewnętrzna kopia zapasowa on-line (zdalne kopiowanie)

użyj rsync chociaż ssh (tylko zmiany) - pierwsza kopia zapasowa musi być wykonana lokalnie, ale potem kopia zapasowa będzie prosta w zależności od zmian

jeśli chcesz zachować wersje ze zmianami - rdiff-backup

http://www.nongnu.org/rdiff-backup/

System plików btrfs w systemie Linux brzmi obiecująco, ale wciąż intensywnie się rozwija

Spójrz na swoją „treść” i jak często się zmienia przed zaplanowaniem strategii. Wiele razy ludzie po prostu przesyłają te same dane, aby co tydzień nagrywać bez powodu.

Technologie deduplikacji od niektórych dostawców mogą umożliwiać migawki, aby uchronić Cię przed przywracaniem pojedynczych plików, ale zawsze będziesz potrzebować ochrony zewnętrznej.