Serwer kopii zapasowych z ZFS

Jestem IT człowiekiem w małej firmie. Chcę zaprojektować nową infrastrukturę, w tym nowy serwer i oddzielny serwer kopii zapasowych z zasadami tworzenia kopii zapasowych w całej firmie.

Najważniejszą rzeczą w firmie jest SQL Server i jego bazy danych. Istnieje 10 baz danych, ale tylko 2 z nich są naprawdę ważne. Pierwszy 8 GB, głównie dane tekstowe i liczby. Drugi, około 300 GB z 16 GB miesięcznie, zawiera pliki PDF i GIF.

Aby zapisać pamięć, bieżąca polityka tworzenia kopii zapasowych składa się z jednej pełnej kopii zapasowej na tydzień i 6 różnic. Myślę, że to około 350 GB tygodniowo, 1,4 TB miesięcznie.

Po przeczytaniu artykułów o cichym uszkodzeniu danych postanowiłem wypróbować ZFS z Nexenta Community Edition.

Moje pytanie: czy ZFS z deduplikacją nadaje się do przechowywania plików kopii zapasowych pod względem niezawodności, czy powinienem pomyśleć o kopii zapasowej na taśmie lub czymś innym?

EDYCJA: Wiem, że w tej chwili nie możemy przewidzieć wydajności, współczynnika deduplikacji itp., Ale chcę wiedzieć, czy to w ogóle dobry pomysł.

Na pewno ZFS jest wystarczająco stabilny, aby tego dokonać, istnieje wiele bardzo dużych i niezawodnych platform produkcyjnych opartych całkowicie na ZFS i Nexenta.

To powiedziawszy, zawsze lubisz mieć kopie zapasowe na miejscu, takie jak ta, którą sugerujesz, ORAZ kopie zapasowe na dysku wymiennym lub na taśmie, które codziennie wychodzą poza witrynę w celu ochrony przed pożarem / trzęsieniem ziemi / Cthulhu itp.

Więc moja odpowiedź brzmi tak, jest w porządku, ale wybrałbym obie opcje, jeśli możesz.

(zakładając, że masz na myśli używanie dedupe w ZFS w porównaniu z oprogramowaniem do tworzenia kopii zapasowych)

Bym nie zalecamy stosowania ZFS natywną deduplikacji dla systemu zapasowego chyba zaprojektować system przechowywania specjalnie dla niego.

Używanie dedupe w ZFS wymaga bardzo dużej ilości pamięci RAM. Ponieważ deduplikacja zachodzi w czasie rzeczywistym, gdy dane są przesyłane strumieniowo / zapisywane do puli pamięci, w pamięci przechowywana jest tabela, która śledzi bloki danych. To jest tabela DDT . Jeśli serwer pamięci ZFS nie ma wystarczającej ilości pamięci RAM, aby pomieścić tę tabelę, wydajność znacznie spadnie. Nexenta ostrzeże Cię, gdy stół przekroczy określony próg, ale do tego czasu jest już za późno. Można to zwiększyć za pomocą urządzenia L2ARC (pamięć podręczna odczytu), ale wielu wczesnych użytkowników ZFS wpadło w tę pułapkę.

Widzieć:

ZFS - niszczenie deduplikowanego pliku zvol lub zestawu danych blokuje serwer. Jak odzyskać?

ZFS - Wpływ awarii urządzenia pamięci podręcznej L2ARC (Nexenta)

Gdy powiem, że użycie pamięci dedupe wymaga dużej ilości pamięci RAM, oszacuję zapotrzebowanie na pamięć RAM i L2ARC dla opisanego zestawu danych na 64 GB + RAM i 200 GB + L2ARC. To nie jest niewielka inwestycja. Przechowywanie wielu plików systemowych Windows i dokumentów graficznych, które nie będą ponownie czytane, bardzo szybko wypełni DDT. Wypłata może nie być warta prac inżynieryjnych, które należy podjąć z góry.

Lepszym pomysłem jest użycie kompresji w zpool, prawdopodobnie wykorzystując możliwości gzip dla bardziej kompresowalnych typów danych. Deduplikacja nie będzie tego warta, ponieważ istnieje potrzeba, gdy trzeba usunąć deduplikowane dane (musi odwoływać się do DDT).

Ponadto, w jaki sposób zaprezentujesz pamięć masową oprogramowaniu do tworzenia kopii zapasowych? Z którego pakietu oprogramowania do tworzenia kopii zapasowych będziesz korzystać? W środowiskach Windows przedstawiam ZFS jako magazyn blokowy dla Backup Exec przez iSCSI. Nigdy nie uważałem, że funkcje ZFS CIFS są wystarczająco solidne i wolałem zalety natywnie sformatowanego urządzenia.

Oto doskonały zasób ZFS do pomysłów projektowych. Rzeczy o ZFS, których nikt ci nie powiedział

Alternatywnym systemem operacyjnym jest OpenIndiana, który jest równie dobry i czasami otrzymuje częstsze aktualizacje.

Inną opcją jest skonfigurowanie drugiego serwera ZFS z mniejszą (potencjalnie) pulą pamięci z włączoną kompresją. Możesz użyć tego drugiego urządzenia do tworzenia statycznych kopii zapasowych. W ten sposób możesz zrezygnować z pamięci podręcznej odczytu, a także nie potrzebujesz głupich ilości procesora / pamięci RAM do obsługi.

Prowadzimy konfigurację taką jak ta, w której pracuję:

• Główny serwer pamięci OpenIndiana [ main ] z sześcioma dyskami 2 TB w puli RaidZ1 trzech zestawów par lustrzanych. To, ograniczając dostępną przestrzeń dyskową, zapewnia szybką i wielokrotnie nadmiarową pulę pamięci.
• Pomocniczy serwer pamięci [ backup ] również działa z OpenIndiana z podobną konfiguracją dysków, która służy wyłącznie jako urządzenie do tworzenia kopii zapasowych.
• main ma skrypt uruchamiany z zadania cron, który regularnie wykonuje migawki / tank / [zbiór danych] w ciągu dnia
• Każdego wieczoru uruchamiane jest kolejne zadanie CRON, które przesyła dzienne migawki przez sieć do tworzenia kopii zapasowych . Po zakończeniu wstępnej synchronizacji wszystkich migawek (procedura jednorazowa) przyrostowa natura migawek oznacza, że ​​zmiany są bardzo szybko przesyłane na urządzenie kopii zapasowej.

Mam krótkie podsumowanie, w jaki sposób przygotować ZFS do wysyłania / odbierania tutaj: http://kyrill-poole.co.uk/blog/tech/zfs-send-and-receive/