So verhindern Sie, dass die Snapshot-Replikation den Ziel-Pool füllt

Eva Wong

IceWhale author

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

How to Prevent Snapshot Replication From Filling the Destination Pool

Die Snapshot-Replikation füllt einen Ziel-Pool, wenn sich aufbewahrte Snapshots und geänderte Blöcke schneller ansammeln, als die Bereinigungsrichtlinie des Ziels sie freigeben kann.

Die vorbeugende Lösung besteht darin, Quellaufbewahrung, Zielaufbewahrung, Replikationsintervall und Warnungen zum freien Speicher als eine gemeinsame Richtlinie zu planen. Eine Replik darf durchaus mehr Verlauf als die Quelle aufbewahren, aber diese Entscheidung muss begrenzt sein. Verfolgen Sie, welche Snapshots als inkrementelle Basen benötigt werden, wie viele eindeutige Daten alte Snapshots binden, ob Bookmarks einige lokale Quell-Snapshots ersetzen können und wie viel Spielraum verbleibt, bevor der nächste große Änderungssatz eintrifft.

Definieren Sie eine Aufbewahrungsrichtlinie für das Ziel

Legen Sie fest, wie viele stündliche, tägliche, wöchentliche und monatliche Wiederherstellungspunkte das Ziel behalten soll, und dokumentieren Sie, warum sich dieser Verlauf von dem der Quelle unterscheidet. Gehen Sie nicht davon aus, dass die Replikationssoftware automatisch jeden alten Ziel-Snapshot entfernt, sobald die Quelle ihn löscht.

Eine Übersicht zur ZFS-Replikation erklärt, dass die Replikation eine Snapshot-Richtlinie benötigt, weil Snapshots sowohl Wiederherstellungspunkte als auch Grenzen für inkrementelle Übertragungen sind.

Wenden Sie bei stark veränderlichen Datasets die kürzeste Aufbewahrungsdauer an, sofern ein längerer Verlauf keinen konkreten Wiederherstellungswert bietet. Bewahren Sie Archive mit wenigen Änderungen nach einem anderen Zeitplan auf, damit eine globale Richtlinie keinen Speicher verschwendet, wenn häufige Wiederherstellungspunkte nur geringen Nutzen bringen.

Schätzen Sie, wie viele Änderungen alte Snapshots binden

Messen Sie die USED-Größe der Snapshots, die zwischen Snapshots geschriebenen Daten sowie den freien Speicher des Ziel-Pools vor und nach großen Löschvorgängen, Verschiebungen, Medienaustausch oder dem Umschreiben von VMs. Ein Snapshot kann alte Blöcke weiter am Leben halten, nachdem die Live-Daten verschwunden sind.

Ein TrueNAS-Hinweis zur Replikation warnt davor, dass Snapshot-Änderungen alte Blöcke zurückhalten, selbst wenn das aktuelle Live-Dataset kleiner wird.

Verwenden Sie diese Änderungsrate zur Dimensionierung der Aufbewahrung. Ein Ziel mit 30 Tagen schnell wechselnder VM-Images kann deutlich mehr Kapazität benötigen als ein anderes Dataset gleicher Live-Größe, das hauptsächlich aus nur erweiterbaren Familienfotos besteht.

Reservieren Sie Speicherplatz für die nächste Replikation

Legen Sie eine betriebliche Untergrenze für den freien Speicher fest, die das größte realistische eingehende inkrementelle Datenvolumen, das lokale Wachstum durch Snapshots und den normalen Dateisystem-Overhead berücksichtigt. Lösen Sie Warnungen aus, bevor diese Untergrenze erreicht wird, nicht erst, wenn der Pool bereits nahezu voll ist.

Oracles Diskussion zur Snapshot-Aufbewahrung weist darauf hin, dass die Aufbewahrung das Snapshot-Wachstum steuert, anstatt Snapshots als kostenlos zu betrachten, nur weil ihre Erstellung zunächst wenig kostet.

Unterbrechen Sie nicht kritische Aufbewahrungen oder verkürzen Sie sie, bevor das Ziel einen kritischen Zustand erreicht. Ein Replikationsziel benötigt Platz, um neue Blöcke zu empfangen und zu übernehmen. Nur genügend Speicher für das heutige Live-Dataset einzuplanen, ist daher keine sichere Kapazitätsstrategie.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

Verwenden Sie Bookmarks, wenn sie den inkrementellen Verlauf erhalten

Wenn Ihre ZFS-Version und Ihre Replikationstools Bookmarks unterstützen, prüfen Sie, ob ein Bookmark die Referenz für einen inkrementellen Versand erhalten kann, nachdem ein alter Quell-Snapshot nicht mehr als vollständiger lokaler Wiederherstellungspunkt benötigt wird.

Ein Design für Offsite-Backups zeigt, wie Bookmarks inkrementelle Basen bewahren und gleichzeitig eine unabhängige Snapshot-Aufbewahrung ermöglichen.

Ersetzen Sie nicht jeden Snapshot durch ein Bookmark. Der Wiederherstellungsverlauf des Ziels erfordert weiterhin echte Snapshots, und Replikationstools gehen unterschiedlich mit gemeinsamen Basen um. Verwenden Sie Bookmarks nur dort, wo sie die Quellseite vereinfachen, ohne das Wiederherstellungsziel des Ziels zu beeinträchtigen.

Schützen Sie nur die Snapshots, die die Replikation noch benötigt

Ermitteln Sie vor dem Bereinigen den neuesten gemeinsamen Snapshot, den Quelle und Ziel teilen. Wenn die Tools Holds oder gleichwertige Schutzmechanismen verwenden, prüfen Sie, ob Bereinigungsaufträge diese respektieren und veraltete Holds schließlich freigegeben werden.

Das FreeBSD-ZFS-Handbuch erklärt, dass Holds gemeinsame Snapshots schützen, bis der Hold ausdrücklich freigegeben wird.

Bewahren Sie nicht jeden historischen Snapshot auf, nur weil eine gemeinsame Basis erforderlich ist. Schützen Sie die kleine Menge, die die Replikation tatsächlich benötigt, und überlassen Sie ältere, unabhängige Wiederherstellungspunkte der Aufbewahrungsrichtlinie des Ziels.

Prüfen Sie Replikations-Snapshots getrennt vom Backup-Verlauf

Einige Tools erstellen zusätzlich zu Ihren geplanten stündlichen oder täglichen Snapshots eigene Synchronisations-Snapshots. Listen Sie beide Gruppen auf dem Ziel auf und stellen Sie sicher, dass die vom Tool erzeugte Gruppe nicht ohne Bereinigungsregel anwachsen kann.

Eine Diskussion zu Sanoid und Syncoid erklärt, dass Synchronisations-Snapshots als Schutzmechanismen dienen, anstatt dass jeder Replikations-Snapshot als langfristiger Backup-Verlauf gedacht ist.

Überprüfen Sie das Ziel monatlich oder nach jeder größeren Verschiebung eines Datasets. Die Richtlinie ist gesund, wenn die erwarteten Wiederherstellungspunkte vorhanden sind, das nächste inkrementelle Update über eine gültige gemeinsame Basis verfügt und der freie Speicher des Pools über der festgelegten Untergrenze bleibt. Der zugehörige ZimaSpace-Artikel zur Diagnose des Snapshot-Speicherplatzes ist der nächste Schritt, wenn das Ziel bereits unerwartet voll ist.

Häufig gestellte Fragen

Sollte das Ziel exakt dieselben Snapshots wie die Quelle behalten?

Nicht unbedingt. Ein Backup-Ziel kann einen längeren Verlauf behalten, aber der Unterschied sollte beabsichtigt, kapazitätsseitig geprüft und durch eine eigene Aufbewahrungsrichtlinie geregelt sein.

Kann das Löschen von Dateien auf der Quelle sofort Speicherplatz auf dem Ziel freigeben?

Nein. Replizierte Snapshots können ältere Blöcke weiterhin referenzieren, nachdem die Live-Datei verschwunden ist. Speicherplatz wird erst freigegeben, wenn kein aufbewahrter Snapshot und keine andere Referenz diese Blöcke mehr benötigt.

Gibt das Löschen des ältesten Snapshots immer den meisten Speicherplatz frei?

Nein. Snapshot-Speicherplatz wird von mehreren Wiederherstellungspunkten gemeinsam genutzt. Schätzen oder messen Sie den eindeutig referenzierten Speicherplatz und schützen Sie jeden gemeinsamen Snapshot, der für die inkrementelle Replikation noch erforderlich ist.