Sicherungsspeicherserver mit ZFS

Ich bin IT alles Mann in einer kleinen Firma. Ich möchte eine neue Infrastruktur mit einem neuen Server und einem separaten Sicherungsserver mit unternehmensweiten Sicherungsrichtlinien entwerfen.

Das Wichtigste im Unternehmen ist der SQL Server und seine Datenbanken. Es gibt 10 Datenbanken, aber nur 2 davon sind wirklich wichtig. Die ersten 8 GB, meistens Textdaten und Zahlen. Die zweite mit etwa 300 GB und 16 GB / Monat wächst mit PDFs und GIFs.

Zum Speichern des Speichers besteht die aktuelle Sicherungsrichtlinie aus einer vollständigen Sicherung pro Woche und 6 Differentialen. Ich denke, es sind ungefähr 350 GB pro Woche, 1,4 TB pro Monat.

Nachdem ich Artikel über stille Datenkorruption gelesen hatte, entschied ich mich, ZFS mit der Nexenta Community Edition zu testen.

Meine Frage: Ist ZFS mit Deduplizierung in Bezug auf die Zuverlässigkeit gut zum Speichern von Sicherungsdateien geeignet, oder sollte ich über eine Bandsicherung oder etwas anderes nachdenken?

EDIT: Ich weiß, dass wir derzeit keine Leistung, Deduplizierungsrate usw. vorhersagen können, aber ich möchte wissen, ob dies überhaupt eine gute Idee ist.

Sicherlich ist ZFS stabil genug, um so etwas zu tun. Es gibt viele sehr große, hochkarätige und zuverlässige Produktionsplattformen, die ausschließlich auf ZFS und Nexenta basieren.

Das heißt, Sie möchten immer festplattenbasierte Sicherungen vor Ort haben, wie die von Ihnen vorgeschlagene UND Sicherungen auf Wechseldatenträgern oder Bändern, die täglich außerhalb des Standorts ausgeführt werden, um sich vor Feuer / Erdbeben / Cthulhu usw. zu schützen.

Meine Antwort lautet also ja, es ist in Ordnung, aber ich würde beide Optionen wählen, wenn Sie können.

(Angenommen, Sie beziehen sich auf die Verwendung von Deduplizierung in ZFS im Vergleich zu Ihrer Sicherungssoftware.)

Ich würde nicht empfehlen, die native ZFS- Deduplizierung für Ihr Sicherungssystem zu verwenden, es sei denn, Sie entwerfen Ihr Speichersystem speziell dafür.

Die Verwendung von Deduplizierung in ZFS ist extrem RAM-intensiv. Da die Deduplizierung in Echtzeit erfolgt, während Daten in den Speicherpool gestreamt / geschrieben werden, wird im Speicher eine Tabelle verwaltet, die Datenblöcke verfolgt. Dies ist die DDT-Tabelle . Wenn Ihr ZFS-Speicherserver nicht über genügend RAM verfügt, um diese Tabelle aufzunehmen, leidet die Leistung erheblich. Nexenta wird Sie warnen, wenn der Tisch eine bestimmte Schwelle überschreitet, aber bis dahin ist es zu spät. Dies kann durch die Verwendung eines L2ARC-Geräts (Lese-Cache) ergänzt werden, aber viele frühe Anwender von ZFS sind in diese Falle geraten .

Sehen:

ZFS - Durch das Zerstören von dedupliziertem zvol oder Datensatz wird der Server blockiert. Wie erholt man sich?

ZFS - Auswirkungen eines L2ARC-Cache-Gerätefehlers (Nexenta)

Wenn ich sage, dass der RAM-Bedarf für die Verwendung von Deduplizierung hoch ist, würde ich den RAM- und L2ARC-Bedarf für den von Ihnen beschriebenen Datensatz auf 64 GB + RAM und 200 GB + L2ARC schätzen. Das ist keine geringe Investition. Wenn Sie viele Windows-Systemdateien und Bilddokumente behalten, die nicht erneut gelesen werden, wird dieser DDT sehr schnell gefüllt. Die Auszahlung ist möglicherweise nicht die technische Arbeit wert, die im Voraus geleistet werden muss.

Eine bessere Idee ist die Komprimierung des zpools, wobei möglicherweise die gzip-Funktionen für die komprimierbareren Datentypen genutzt werden. Eine Deduplizierung lohnt sich nicht, da es einen Treffer gibt, wenn Sie deduplizierte Daten löschen müssen (muss auf das DDT verweisen).

Wie werden Sie den Speicher Ihrer Sicherungssoftware präsentieren? Welche Backup-Software-Suite verwenden Sie? In Windows-Umgebungen präsentiere ich Backup Exec ZFS als Blockspeicher über iSCSI. Ich fand die ZFS CIFS-Funktionen nie robust genug und bevorzugte die Vorteile eines nativ formatierten Geräts.

Hier finden Sie auch eine hervorragende ZFS-Ressource für Designideen. Dinge über ZFS, die Ihnen niemand erzählt hat

Ein alternatives Betriebssystem ist OpenIndiana, das genauso gut ist und manchmal häufiger aktualisiert wird.

Eine andere Möglichkeit besteht darin, einen zweiten ZFS-Server mit einem kleineren (potenziell) Speicherpool mit aktivierter Komprimierung einzurichten. Sie können dieses zweite Gerät für statische Sicherungen verwenden. Sie können somit auf den Lese-Cache verzichten und benötigen auch keine dummen Mengen an CPU / RAM, um damit umzugehen.

Wir führen ein Setup wie dieses aus, in dem ich arbeite:

• OpenIndiana-Hauptspeicherserver [ main ] mit sechs 2-TB-Festplatten in einem RaidZ1-Pool aus drei Sätzen gespiegelter Paare. Dies reduziert zwar den verfügbaren Speicherplatz, sorgt jedoch für einen schnellen und mehrfach redundanten Speicherpool.
• Ein sekundärer Speicherserver [ Backup ], auf dem auch OpenIndiana mit einer ähnlichen Konfiguration von Festplatten ausgeführt wird, die ausschließlich als Backup-Gerät dient.
• main hat ein Skript, das von einem Cron-Job ausgeführt wird, der im Laufe des Tages regelmäßig Snapshots / tank / [Dataset] erstellt
• Jeden Abend wird ein weiterer Cron-Job ausgeführt, der die Snapshots des Tages über das Netzwerk zur Sicherung überträgt . Sobald die erste Synchronisierung aller Ihrer Snapshots abgeschlossen ist (ein einmaliges Verfahren), bedeutet die inkrementelle Natur der Snapshots, dass Änderungen sehr schnell auf Ihr Sicherungsgerät übertragen werden.

Ich habe einen kurzen Überblick darüber, wie man das Senden / Empfangen von ZFS manipuliert: http://kyrill-poole.co.uk/blog/tech/zfs-send-and-receive/