So planen Sie Restic-Aufgaben für Backup, Forget und Prune ohne Sperrkonflikte

Planen Sie Sicherungen häufig, führen Sie „forget“ über einen zentralen Repository-Controller aus und lassen Sie „prune“ seltener innerhalb eines exklusiven Wartungsfensters laufen. Lassen Sie nicht jeden Host alle drei Aufgaben übernehmen.

Ein gemeinsam genutztes Home-Server-Repository benötigt zwei Arten von Zeitplanung: Wiederherstellungspunkte pro Host und repositoryweite Wartung. Erstellen Sie den Zeitplan anhand gemessener Laufzeiten und Wiederherstellungsziele, nicht anhand fester Beispiele aus dem Internet. Zentralisieren Sie Aufbewahrung und „prune“, gruppieren Sie Snapshots korrekt, legen Sie die Reihenfolge der Units ausdrücklich fest und geben Sie jedem übersprungenen Auftrag eine Wiederholung und einen Alarm. Der Zeitplan ist erst vollständig, wenn zwei Zyklen und eine Beispielwiederherstellung bestätigen, dass Aufbewahrung und Sperrverwaltung wie vorgesehen funktionieren.

Erfassen Sie jeden Auftrag, Verantwortlichen und die längste normale Laufzeit

Erstellen Sie eine Tabelle für jeden Vorgang, der auf das Repository zugreift: Sicherung, „forget“, „prune“, Prüfung, Entsperren, Auflisten von Snapshots und Wiederherstellungstest. Vermerken Sie den auslösenden Host, den Befehl oder Wrapper, die Zugangsdaten, die normale und die längste aktuelle Laufzeit, das Timeout, die Wiederholungsregel und das Alarmziel. Berücksichtigen Sie auch Aufträge, die in Sicherungsanwendungen oder NAS-Oberflächen verborgen sind.

Ein gemeinsam genutztes Repository benötigt repositoryweite Wartung statt einer Kopie pro Client. Die praktische Restic-Praxis für mehrere Hosts führt „forget“, „prune“ und „check“ einmal pro Repository aus und gruppiert die Aufbewahrung nach den relevanten Hosts und Pfaden.

Fassen Sie doppelte Wartungsaufträge unter einem Controller zusammen. Behalten Sie die Zuständigkeit der einzelnen Hosts für Sicherungen bei, wenn dies den Zugriff auf die Quelldaten erleichtert, lassen Sie jedoch jeden Host seinen Start- und Abschlussstatus an den Controller melden. Wenn für einen Auftrag weder eine gemessene Laufzeit noch ein Verantwortlicher vorhanden ist, beobachten Sie ihn zunächst, bevor Sie ein Wartungsfenster dafür festlegen.

Legen Sie zuerst den Sicherungsrhythmus fest und grenzen Sie danach „forget“ ein

Wählen Sie den Sicherungsrhythmus jedes Hosts anhand der Datenmenge, deren Verlust Sie verkraften können, und der üblichen Dauer einer Sicherung. Staffeln Sie umfangreiche Quell-Scans, wenn sie um Netzwerk- oder Speicherressourcen konkurrieren; verteilen Sie Aufträge jedoch nicht bloß, damit ein Diagramm übersichtlich aussieht. Die längste normale Sicherung bestimmt den frühestmöglichen Beginn der Wartung.

Führen Sie „forget“ über den Repository-Controller aus und prüfen Sie die Auswahl vorab mit der vorgesehenen Gruppierung nach Host, Pfad und Tag. Eine unerwartete Kalendergruppierung kann dazu führen, dass die Aufbewahrung mehr Wiederherstellungspunkte entfernt, als eine einfache Betrachtung der Aufbewahrungsanzahl erwarten lässt.

Halten Sie „forget“ bei der Zeitplanung logisch von der physischen Bereinigung durch „prune“ getrennt. Die vorab geprüfte Aufbewahrungsrichtlinie kann nach einer erfolgreichen Sicherung oder in einer eigenen Controller-Phase ausgeführt werden, während „prune“ ein längeres exklusives Zeitfenster erhält. Verknüpfen Sie „prune“ nicht mit der Sicherung jedes Hosts, nur weil ein einzelner Befehl beides kombinieren kann.

Führen Sie „prune“ und „check“ in repositoryweiten Zeitfenstern aus

Führen Sie „prune“ seltener als Sicherungen und in der Regel auch seltener als „forget“ aus, da die physische Bereinigung des Repositorys deutlich länger dauern und andere Arbeiten blockieren kann. Platzieren Sie sie nach dem Abschluss aller erwarteten Sicherungen und der Auswahl durch die Aufbewahrungsrichtlinie. Geben Sie „check“ abhängig von der Repositorygröße und der Geschwindigkeit des Backends eine eigene Phase oder ein eigenes Zeitfenster.

Eine systemd-Restic-Konfiguration kann Sicherung und Bereinigung in getrennten Services halten, sodass der Scheduler deren Beendigungsstatus überwacht, anstatt einen undurchsichtigen kombinierten Befehl zu starten.

Wenn „prune“ das Zeitfenster regelmäßig überschreitet, lassen Sie Sicherungen nicht unbemerkt auflaufen. Verringern Sie die Häufigkeit von „prune“, erweitern Sie das Zeitfenster, untersuchen Sie den Datendurchsatz des Backends oder teilen Sie die Repositorys auf, wenn ihre betrieblichen Anforderungen nicht mehr zusammenpassen. Der Eintritt setzt voraus, dass keine Sicherung aktiv ist; der Austritt erfordert einen sauberen Wartungsstatus und eine freigegebene Repository-Sperre.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Definieren Sie Abhängigkeiten, Wiederholungen und Alarme

Definieren Sie die gewünschte Reihenfolge, statt sich auf Zeitabstände zu verlassen: Sicherungs-Units melden ihren Abschluss, „forget“ läuft erst nach den erforderlichen Sicherungen, „prune“ erst nach dem Eintritt des Repositorys in sein exklusives Zeitfenster und „check“ entsprechend der festgelegten Wartungsrichtlinie. Verwenden Sie ein gemeinsames externes Gate, das alle relevanten Units berücksichtigen.

Systemd-Targets können ausdrücken, dass die Abhängigkeiten zwischen Sicherung und Wartung in der richtigen Reihenfolge abgeschlossen werden müssen, statt lediglich zu unterschiedlichen Uhrzeiten zu starten.

Legen Sie begrenzte Wiederholungen für konkurrierende Sperren und Netzwerkfehler fest und alarmieren Sie, wenn die Frist verpasst wird. Eine verspätete Sicherung sollte „prune“ verzögern; ein überlang laufendes „prune“ sollte die nächste Sicherung verzögern und den Betreiber benachrichtigen. Erzwungenes Entsperren und Optionen ohne Sperrprüfung sind keine Wiederholungsstrategien.

Prüfen Sie zwei vollständige Zyklen und eine Wiederherstellung

Beobachten Sie zwei vollständige Zyklen, statt den Erfolg bereits nach dem Laden der Timer-Dateien zu erklären. Bestätigen Sie, dass jede Quelle den erwarteten Snapshot erzeugt, „forget“ die vorgesehenen Gruppen behält, „prune“ nur in seinem Zeitfenster läuft, Sperren nach sauberen Abschlüssen aufgehoben werden und Alarme jede Verzögerung protokollieren.

Stellen Sie Dateien aus einem Snapshot wieder her, der die Aufbewahrungs- und Bereinigungssequenz überstanden hat, nicht nur aus der neuesten Sicherung. Damit wird nachgewiesen, dass der vollständige Zeitplan einen nutzbaren Wiederherstellungspunkt bewahrt und nicht lediglich grüne Auftragsstatus erzeugt.

Der Zeitplan ist erfolgreich, wenn zwei Zyklen in der vorgesehenen Reihenfolge abgeschlossen werden, kein Auftrag unbemerkt verschwindet, die behaltenen Snapshots mit der Vorschau übereinstimmen und die Beispielwiederherstellung korrekt ist. Setzen Sie die Automatisierung der Wartung zurück, behalten Sie jedoch die normalen Sicherungen bei, wenn die Aufbewahrung die falsche Gruppe entfernt, „prune“ nicht zuverlässig abgeschlossen werden kann oder Sperrkonflikte erneut auftreten. Passen Sie den Rhythmus anhand gemessener Ergebnisse an, statt den Schutz des Repositorys zu deaktivieren.