Frage Wie führe ich inkrementelle / kontinuierliche Backups des zfs-Pools durch?


Wie können ZFS-Pools kontinuierlich / inkrementell extern gesichert werden?

Ich erkenne das send/receive Über SSH ist eine Methode, die jedoch beinhaltet, Snapshots manuell zu verwalten.

Es gibt einige Tools, die ich gefunden habe, aber die meisten werden nicht mehr unterstützt.

Das eine Werkzeug, das vielversprechend aussieht, ist https://github.com/jimsalterjrs/sanoid Ich mache mir jedoch Sorgen, dass ein nicht allgemein bekanntes Tool mehr Schaden anrichten kann, als dass Daten beschädigt / gelöscht werden können.

Wie werden kontinuierliche / inkrementelle zfs-Sicherungen durchgeführt?


20
2018-04-04 15:59


Ursprung


Ich werde etwas später antworten, aber ich habe eine Lösung, die diese Art der Replikation alle 15 Sekunden vom primären ZFS-Server zum sekundären durchführt. - ewwhite


Antworten:


ZFS ist ein unglaubliches Dateisystem und löst viele meiner lokalen und gemeinsamen Datenspeicheranforderungen.

Während, ich mag die Idee von Clustered ZFS wo immer es möglich ist, manchmal ist es nicht praktisch, oder ich brauche eine geographische Trennung von Speicherknoten.

Einer meiner Anwendungsfälle ist der replizierte Hochleistungsspeicher auf Linux-Anwendungsservern. Zum Beispiel unterstütze ich ein Legacy-Softwareprodukt, das NVMe SSD-Laufwerke mit niedriger Latenz für seine Daten nutzt. Die Anwendung verfügt über eine Spiegelungsoption auf Anwendungsebene, die auf einen sekundären Server repliziert werden kann. Sie ist jedoch oft ungenau und dauert 10 Minuten RPO.

Ich habe dieses Problem gelöst, indem ich einen sekundären Server habe (der auch ZFS auf ähnlicher oder unterschiedlicher Hardware ausführt), der lokal, remote oder beides sein kann. Durch die Kombination der drei unten aufgeführten Dienstprogramme habe ich eine Replikationslösung erstellt, die mir fortlaufende Replikation, tiefe Snapshot-Aufbewahrung und flexible Failover-Optionen bietet.

zfs-auto-snapshot - https://github.com/zfsonlinux/zfs-auto-snapshot

Nur ein praktisches Tool, um periodische Snapshots auf ZFS-Dateisystemebene zu aktivieren. Ich verwende normalerweise den folgenden Zeitplan für Produktionsvolumes:

# /etc/cron.d/zfs-auto-snapshot

PATH="/usr/bin:/bin:/usr/sbin:/sbin"

*/5 * * * * root /sbin/zfs-auto-snapshot -q -g --label=frequent --keep=24 //
00 * * * * root /sbin/zfs-auto-snapshot -q -g --label=hourly --keep=24 //
59 23 * * * root /sbin/zfs-auto-snapshot -q -g --label=daily --keep=14 //
59 23 * * 0 root /sbin/zfs-auto-snapshot -q -g --label=weekly --keep=4 //
00 00 1 * * root /sbin/zfs-auto-snapshot -q -g --label=monthly --keep=4 //

Syncoid (Sanoid) - https://github.com/jimsalterjrs/sanoid

Dieses Programm kann Ad-hoc-Snap / Replikation eines ZFS-Dateisystems auf einem sekundären Ziel ausführen. Ich benutze nur die Synkopen Teil des Produkts.

  Angenommen Server 1 und Server2, einfacher Befehl von ausführen Server2 zu ziehen Daten von Server 1:

#!/bin/bash

/usr/local/bin/syncoid root@server1:vol1/data vol2/data

exit $?

Monit - https://mmonit.com/monit/

Monit ist ein extrem flexibler Job Scheduler und Execution Manager. Standardmäßig arbeitet es in einem 30-Sekunden-Intervall, aber ich ändere die Konfiguration, um einen Basiszyklus von 15 Sekunden zu verwenden.

Eine Beispielkonfiguration, die das obige Replikationsscript alle 15 Sekunden ausführt (1 Zyklus)

check program storagesync with path /usr/local/bin/run_storagesync.sh
        every 1 cycles
        if status != 0 then alert

Dies ist einfach zu automatisieren und über das Konfigurationsmanagement hinzuzufügen. Indem Sie die Ausführung des Snapshots / der Replikation in Monit einschließen, erhalten Sie einen zentralisierten Status, Jobkontrolle und Alarmierung (E-Mail, SNMP, benutzerdefiniertes Skript).


Das Ergebnis ist, dass ich Server habe, die haben mehrere Monate von monatlichen Snapshots und vielen Rollback- und Retentionspunkten innerhalb von: https://pastebin.com/zuNzgi0G - Plus, ein fortlaufender 15-Sekunden-Atommodell:

# monit status

Program 'storagesync'
  status                            Status ok
  monitoring status                 Monitored
  last started                      Wed, 05 Apr 2017 05:37:59
  last exit value                   0
  data collected                    Wed, 05 Apr 2017 05:37:59
.
.
.
Program 'storagesync'
  status                            Status ok
  monitoring status                 Monitored
  last started                      Wed, 05 Apr 2017 05:38:59
  last exit value                   0
  data collected                    Wed, 05 Apr 2017 05:38:59


18
2018-04-05 12:42



Vielen Dank für Ihre Nachricht, Ihre Antwort ist phänomenal und genau das, wonach ich gesucht habe (von der Latenz bis zur Überwachung des Prozesses). Lesen auch github.com/ewwhite/zfs-ha/wiki und ich bin sehr beeindruckt. Vielen Dank noch mal :) - Greg


Sie haben zwei verschiedene Möglichkeiten, dies zu tun:

  1. Der traditionelle, filesystem-agnostische Weg, der in den letzten Jahrzehnten mit Tools wie verwendet wurde / wurde rsync oder Bacula. Dort haben Sie eine (hoffentlich) stabile, große Software getestet, die für große Bereitstellungen angepasst werden kann und auch verwendet werden kann, wenn Sie von ZFS abschalten
  2. Eines der Tools, die ZFS nutzen send/recv. Dies kann entweder Ihre eigene Lösung sein, ein Skript oder ein erweitertes Skript von den verschiedenen auf Github et al., Oder mehr funktionsreiche Tools wie Sanoid oder ZnapZend (send / recv mit mbuffer Support- und Aufbewahrungsplänen). In diesem Fall werden Sie höchstwahrscheinlich keine großen, "unternehmensbezogenen" (im negativen Sinne) Lösungen finden, sondern Werkzeuge, die nur die eine Aufgabe erledigen und mit anderen Tools kombiniert werden können, um auf Ihre spezifische Konfiguration einzugehen.

Im Allgemeinen würde ich nur einem Werkzeug vertrauen, dessen Quellcode verfügbar ist, und ich würde es so einfach wie möglich halten. Wenn Sie verwenden send/recv, Sie müssen nicht viel verwalten, Sie müssen nur Snapshot löschen n-1 auf der lokalen Seite bei der Übertragung und Erstellung von Snapshots n auf der anderen Seite war erfolgreich.

Sie können Ihren Transport beliebig teilen, er kann sogar asynchron sein (Snapshots müssen nicht sofort empfangen werden), wenn Sie nur die eiserne Regel beibehalten, dass Sie nur einen Unterschied zwischen dem lokalen aktuellen / neuen und lokalen vorherigen Snapshot senden können und dass der lokale vorherige Snapshot der neueste auf der Remote-Seite ist (bis die Sicherung beendet und alles zurückgesetzt wird).

Nun, da ich darüber nachdenke, könnte man das wahrscheinlich in einer Zustandsmaschine kodieren und dann sicher sein, dass keine unvorhergesehenen Fälle durchkommen können.


4
2018-04-05 07:00



Ich sehe nicht wie rsync-basierte Lösung würde skalieren, um ein großes unternehmensweites Dateisystem kontinuierlich zu replizieren. Änderungen könnten schneller passieren als rsync könnte sie entdecken. - Andrew Henle
@AndrewHenle Ich würde mich auch nicht dafür einsetzen, ich wollte es nur darstellen, weil die Frage nicht den Umfang / die Größe der Daten oder den Zeitrahmen spezifiziert hat. Im Falle von seltenem Handeln könnte es also eine Möglichkeit sein, wenn es Dateisystem-agnostisch sein sollte. Natürlich würden Sie die schönen Deltas auf Blockebene verlieren ... - user121391
@ user121391 Ich stimme dir völlig zu, dass Opensource der richtige Weg ist. Vielen Dank für Ihre ausführliche Antwort. - Greg
@Dave genau wie ich tippe ... - ewwhite
empfehle sehr znapzend - Trent Lloyd