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

Wie können ZFS-Pools außerhalb des Standorts kontinuierlich / inkrementell gesichert werden?

Ich erkenne, dass send/receiveover ssh eine Methode ist, bei der Snapshots manuell verwaltet werden müssen.

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

Das eine vielversprechende Tool ist https://github.com/jimsalterjrs/sanoid Ich jedoch, dass nicht allgemein bekannte Tools mehr Schaden anrichten als nützen, da sie Daten beschädigen / löschen können.

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

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

Obwohl mir die Idee von Clustered ZFS nach Möglichkeit gefällt , ist sie manchmal nicht praktikabel, oder ich benötige eine geografische Trennung der Speicherknoten.

Einer der Anwendungsfälle, die ich habe, ist für replizierten Hochleistungsspeicher auf Linux-Anwendungsservern. Ich unterstütze beispielsweise ein älteres Softwareprodukt, das für seine Daten von NVMe-SSD-Laufwerken mit geringer Latenz profitiert. Die Anwendung verfügt über eine Spiegelungsoption auf Anwendungsebene, die auf einen sekundären Server repliziert werden kann, jedoch häufig ungenau ist und eine RPO von 10 Minuten umfasst .

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

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

Nur ein praktisches Tool, um regelmäßige Snapshots auf ZFS-Dateisystemebene zu aktivieren. Ich arbeite normalerweise mit dem folgenden Zeitplan für Produktionsvolumen:

# /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 ein sekundäres Ziel ausführen. Ich verwende nur den syncoiden Teil des Produkts.

Angenommen, Server1 und Server2 führen einen einfachen Befehl von Server2 aus , um Daten von Server1 abzurufen :

#!/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 funktioniert es in einem Intervall von 30 Sekunden, aber ich ändere die Konfiguration, um einen Basiszeitzyklus von 15 Sekunden zu verwenden.

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

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. Wenn Sie die Ausführung des Snapshots / der Replikation in Monit einbinden, erhalten Sie einen zentralisierten Status, Auftragssteuerung und Warnmeldungen (E-Mail, SNMP, benutzerdefiniertes Skript).

Das Ergebnis ist, dass ich Server mit monatelangen monatlichen Snapshots und vielen Rollback- und Aufbewahrungspunkten habe: https://pastebin.com/zuNzgi0G - Plus, ein fortlaufendes 15-Sekunden-Atom-Replikat:

# 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

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

1. Die traditionelle, dateisystemunabhängige Methode, die in den letzten Jahrzehnten mit Tools wie rsyncoder verwendet wurde Bacula. Dort haben Sie eine (hoffentlich) stabile, große Software getestet, die für große Bereitstellungen angepasst werden kann und auch dann verwendet werden kann, wenn Sie von ZFS wechseln
2. Eines der Tools, die ZFS nutzen send/recv. Dies kann entweder Ihre eigene Lösung sein, ein Skript oder ein erweitertes Skript aus den verschiedenen von Github et al., Oder weitere funktionsreiche Tools wie Sanoid oder ZnapZend (Senden / Empfangen mit Pufferunterstützung und Aufbewahrungsplänen). In diesem Fall werden Sie höchstwahrscheinlich keine großen (im negativen Sinne) "unternehmerischen" Lösungen finden, sondern Tools, die nur eine Aufgabe erfüllen und mit anderen Tools kombiniert werden können, um Ihrem spezifischen Setup gerecht zu werden.

Im Allgemeinen würde ich nur einem Tool vertrauen, dessen Quellcode verfügbar ist, und ich würde es so einfach wie möglich halten. Wenn Sie verwenden send/recv, müssen Sie nicht viel verwalten. Sie müssen nur den Snapshot n-1 auf der lokalen Seite löschen, wenn die Übertragung und Einrichtung des Snapshot n auf der Remote-Seite erfolgreich war.

Sie können Ihr Transportmittel beliebig aufteilen, es kann sogar asynchron sein (Schnappschüsse müssen nicht sofort empfangen werden), wenn Sie nur die eiserne Regel einhalten, dass Sie nur einen Unterschied zwischen dem lokalen aktuellen / neuen und dem lokalen vorherigen Schnappschuss senden können , und dass der lokale vorherige Snapshot der neueste auf der Remote-Seite ist (bis die Sicherung abgeschlossen ist und alles zurückgesetzt ist).

Nun, da ich darüber nachdenke, könnten Sie das wahrscheinlich in einer Zustandsmaschine codieren und dann sicher sein, dass keine unvorhergesehenen Fälle durchrutschen können.