Warum löscht eine GFS-Aufbewahrungsrichtlinie mehr Wiederherstellungspunkte, als die Aufbewahrungsanzahlen vermuten lassen?

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.

Eine GFS-Aufbewahrungsrichtlinie kann mehr Wiederherstellungspunkte als erwartet löschen, da die Aufbewahrungsanzahlen Zeitintervalle beschreiben und keine einfache Summe unabhängiger Backups darstellen.

Regeln wie „letzten behalten“, täglich, wöchentlich, monatlich und jährlich wählen normalerweise repräsentative Wiederherstellungspunkte aus sich überschneidenden Zeiträumen aus. Ein Backup kann mehrere Zeitstufen erfüllen, während ein anderes aufgrund seines Zeitstempels, seiner Quellgruppe, der Richtlinienvererbung oder einer kürzlich geänderten Richtlinie außerhalb aller Intervalle liegen kann. Manche Tools verarbeiten die Regeln in einer festgelegten Reihenfolge oder schließen bereits ausgewählte Backups von späteren Stufen aus. Zeigen Sie den genauen Zeitplan in der Vorschau an, bevor Sie Prune oder Compact ausführen.

Listen Sie jeden Wiederherstellungspunkt mit Richtliniengruppe und Zeitstempel auf

Exportieren Sie Snapshot- oder Archiv-IDs, Quellhost, Pfad, Tags, Abschlussstatus, lokale Zeit, UTC-Zeit und die auf jede Gruppe angewendete Richtlinie. Zählen Sie nicht alle Repositorys oder Quellen zusammen.

Restic wendet Aufbewahrungsrichtlinien auf Snapshot-Gruppen basierend auf Host, Pfaden und Tags an, sofern die Gruppierung nicht geändert wurde. Daher können zwei optisch ähnliche Wiederherstellungspunkte unter unterschiedlichen Richtlinien bewertet werden.

Wenn die unerwarteten Löschungen nur einen Host, einen Pfad oder eine Tag-Gruppe betreffen, korrigieren Sie diese Gruppe oder Auswahl, anstatt die repositoryweite Aufbewahrung zu ändern.

Addieren Sie tägliche, wöchentliche und monatliche Anzahlen nicht einfach

Ordnen Sie jeden Wiederherstellungspunkt dem von ihm repräsentierten Zeitraum zu. Markieren Sie, ob dasselbe Backup als täglicher, wöchentlicher und monatlicher Kandidat ausgewählt wurde.

Der Prune-Simulator von Proxmox zeigt sich überschneidende Aufbewahrungsintervalle, einschließlich Fällen, in denen ein wöchentlicher Kandidat einen Zeitraum abdeckt und spätere Regeln kein weiteres Backup aus demselben Intervall behalten.

Die erwartete Gesamtzahl ist daher nicht immer „täglich behalten“ plus „wöchentlich behalten“ plus „monatlich behalten“. Zählen Sie die eindeutigen IDs der behaltenen Backups, nachdem alle Regeln angewendet wurden.

Prüfen Sie die Reihenfolge der Regeln und den für jeden Zeitraum ausgewählten Kandidaten

Ermitteln Sie, ob innerhalb jedes Zeitraums das neueste, älteste, erste oder letzte erfolgreiche Backup ausgewählt wird. Vergleichen Sie dies mit der tatsächlichen Backup-Zeit des Jobs.

Borg beschreibt seine Prune-Regeln im GFS-Stil und weist darauf hin, dass das Verhalten an Kalendergrenzen Archive in der Nähe des Stichtags beeinflussen kann.

Ein Job, der kurz vor und kurz nach Mitternacht ausgeführt wird, kann zwei Backups erstellen, die lokal an unterschiedlichen Tagen zu liegen scheinen, nach der Umrechnung durch Zeitzone oder Scheduler jedoch in dasselbe Richtlinienfenster fallen.

Prüfen Sie vererbte Richtlinien auf Repository-, Benutzer- und Quell-Ebene

Exportieren Sie die effektive Richtlinie, statt nur die globalen Standardeinstellungen zu lesen. Prüfen Sie Überschreibungen pro Quelle, vererbte Werte, Tags, Ordner und UI-Voreinstellungen.

Der Richtlinienbefehl von Kopia unterstützt vererbte Aufbewahrungswerte pro Quelle. Dadurch kann sich die aktive Regel von der an anderer Stelle angezeigten Einstellung auf Repository-Ebene unterscheiden.

Ein lokaler Aufbewahrungswert von null oder eine geänderte Vererbungsgrenze kann Wiederherstellungspunkte entfernen, obwohl die übergeordnete Richtlinie korrekt aussieht. Speichern Sie die aufgelöste Richtlinie zusammen mit dem Audit.

Prüfen Sie kürzlich reduzierte Richtlinien und den Zeitpunkt der Bereinigung

Vergleichen Sie die aktuellen Aufbewahrungswerte mit früheren Richtlinienversionen und dem Zeitpunkt der letzten Bereinigung. Ermitteln Sie, ob ältere Punkte sofort zum Ablauf vorgemerkt wurden.

Microsoft dokumentiert, dass eine Verkürzung der Aufbewahrung vorhandene Wiederherstellungspunkte betrifft, und zwar während eines späteren Bereinigungsjobs und nicht nur bei zukünftigen Backups.

Eine verzögerte Bereinigung kann dazu führen, dass viele Löschungen scheinbar gleichzeitig erfolgen. Bewahren Sie den Datensatz der Richtlinienänderung und die Liste der vorgemerkten Punkte auf, bevor Sie einen weiteren Lauf genehmigen.

Prüfen Sie GFS-Kennzeichnungen, kurzfristige Aufbewahrung und Richtlinienkonvertierungen

Prüfen Sie, ob die wöchentlichen, monatlichen und jährlichen Kennzeichnungen weiterhin vorhanden sind und ob die kurzfristige Kette die ausgewählten Punkte noch unterstützen kann. Überprüfen Sie Software-Upgrades und Richtlinienkonvertierungen.

Veeam warnt, dass Änderungen an GFS-Einstellungen dazu führen können, dass bestehende Kandidaten ihren GFS-Status verlieren und anschließend für die normale kurzfristige Löschung infrage kommen.

Gehen Sie nicht davon aus, dass der alte Dateiname oder die Rolle als Vollbackup eines Wiederherstellungspunkts eine aktuelle langfristige Aufbewahrung garantiert. Überprüfen Sie seine aktive Richtlinienkennzeichnung.

Führen Sie vor Prune und Compact einen Testlauf oder Simulator aus

Frieren Sie Richtlinienänderungen ein, exportieren Sie die aktuelle Liste der Wiederherstellungspunkte, führen Sie den Testlauf oder Simulator der Plattform aus und vergleichen Sie die beibehaltenen und gelöschten IDs mit einer manuell geprüften Stichprobe.

Der ZimaSpace-Artikel über umfangreiche Snapshot-Verläufe bietet den angrenzenden Wiederherstellungskontext. Dieser Artikel konzentriert sich darauf, warum die Aufbewahrungsberechnung von einer einfachen Zählung abweicht.

Das Problem ist gelöst, wenn Simulator, effektive Richtlinie und eindeutige IDs der beibehaltenen Punkte über mindestens zwei Kalendergrenzen hinweg übereinstimmen und kein erforderliches Wiederherstellungsfenster von einem zum Löschen markierten Punkt abhängt.

Häufig gestellte Fragen

Sind die Anzahlen für täglich und wöchentlich aufzubewahrende Backups additiv?

Nicht unbedingt. Derselbe Wiederherstellungspunkt kann beide Zeiträume repräsentieren, oder die Aufbewahrungs-Engine kann bereits abgedeckte Kandidaten von späteren Regeln ausschließen.

Kann eine verkürzte Aufbewahrung vorhandene Wiederherstellungspunkte löschen?

Ja. Viele Systeme wenden die neue Richtlinie während der nächsten Bereinigung auf vorhandene Punkte an und nicht nur auf zukünftige Backups.

Gibt Prune sofort Speicherplatz im Repository frei?

Das hängt vom Tool ab. Einige Systeme markieren Snapshots oder Archive zunächst und geben die gemeinsam genutzten Daten erst in einem separaten Compact- oder Garbage-Collection-Schritt frei.

Support & Tipps

Mehr zum Lesen

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.