So richtest du Borg Prune und Compact ohne lange Sicherungspausen ein

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.

Um lange Unterbrechungen bei Borg-Sicherungen zu vermeiden, führen Sie die Aufbewahrungsbereinigung nach einer erfolgreichen Sicherung aus, planen Sie die Repository-Komprimierung jedoch seltener und außerhalb des Hauptsicherungszeitraums. Borg 1.4 trennt das Löschen von Archiven von der physischen Rückgewinnung von Speicherplatz. Daher muss borg compact nicht nach jedem borg prune ausgeführt werden.

Dieser Leitfaden richtet sich nach dem aktuellen stabilen Befehlsmodell von Borg 1.4.x. Borg 2 ändert die Semantik von Repositories und Archiven in mehreren Bereichen. Prüfen Sie daher die installierte Version, bevor Sie Automatisierungen aus einer anderen Hauptversion übernehmen.

Borg-Version und Repository bestätigen

borg --version
borg info /mnt/backup/borg-repo
borg list /mnt/backup/borg-repo

Die Borg-FAQ weist darauf hin, dass Borg eine repositoryweite Sperre verwendet und immer nur ein Prozess gleichzeitig Schreibzugriff haben kann. Wenn eine lange Komprimierung mit der nächsten geplanten Sicherung überlappt, wartet die Sicherung auf die Sperre oder schlägt fehl, sobald das Zeitlimit für die Sperre abläuft.

Aufbewahrung zuerst mit einem Probelauf festlegen

borg prune ist ein destruktiver Vorgang für den Archivverlauf. Die Borg-Dokumentation zu prune empfiehlt dringend, mit --dry-run und --list zu testen.

borg prune   --dry-run   --list   --keep-daily 7   --keep-weekly 4   --keep-monthly 6   --glob-archives '{hostname}-*'   /mnt/backup/borg-repo

Wenn ein Repository Sicherungen von mehreren Maschinen oder Datensätzen enthält, ist der Archivfilter unerlässlich. Ohne einen einschränkenden Filter betrachtet Borg 1.4 alle Archive im Repository als Kandidaten für dieselben Aufbewahrungsregeln.

Bereinigung nur nach einer erfolgreichen Sicherung ausführen

#!/bin/sh
set -eu
REPO=/mnt/backup/borg-repo
ARCHIVE='{hostname}-{now:%Y-%m-%d_%H-%M}'

borg create --stats "$REPO::$ARCHIVE" /srv/data

borg prune   --list   --keep-daily 7   --keep-weekly 4   --keep-monthly 6   --glob-archives '{hostname}-*'   "$REPO"

Führen Sie Prune nicht aus, weil ein Scheduler ausgelöst wurde, sondern weil ein neues Backup erfolgreich abgeschlossen und die Aufbewahrungsrichtlinie bereits validiert wurde.

-15% OFF

Verstehen, warum Prune nicht sofort Speicherplatz freigibt

Seit Borg 1.2 ist die Komprimierung von den normalen Befehlen zum Schreiben ins Repository getrennt. In den separaten Hinweisen zur Komprimierung von Borg wird erklärt, dass das Löschen oder Prunen von Archiven nicht sofort den gesamten Speicherplatz im Repository freigibt.

borg create
    |
neues Archiv festgeschrieben
    |
borg prune
    |
alte Archive aus dem Aufbewahrungssatz entfernt
    |
borg compact
    |
nicht verwendeter Speicherplatz in Segmenten wird zurückgewonnen

Das ist für die Zeitplanung nützlich, da tägliche Backups nicht jedes Mal die vollständigen Kosten für das Umschreiben teilweise belegter Repository-Segmente tragen müssen.

Compact seltener als Prune planen

  • backup: jede Nacht;
  • prune: nach jedem erfolgreichen Backup oder einige Male pro Woche;
  • compact: einmal pro Woche während einer ruhigen Zeit;
  • vollständige Repository-Prüfung: nach einem separaten, weniger häufigen Zeitplan.
# Tägliches Backup + Prune
0 1 * * * /usr/local/sbin/borg-backup

# Wöchentliche Komprimierung
0 4 * * 0 /usr/local/sbin/borg-compact

Wenn Backups häufig mehrere Stunden laufen, planen Sie die Komprimierung in größeren Abständen oder verwenden Sie einen Timer mit expliziten Abhängigkeiten.

Den standardmäßigen Compact-Schwellenwert verwenden, bevor maximale Umschreibungen erzwungen werden

Die aktuelle Dokumentation zu compact verwendet standardmäßig einen Schwellenwert von 10 %.

borg compact --progress /mnt/backup/borg-repo

Dieser Standardwert ist ein guter Ausgangspunkt, wenn ein kurzes Wartungsfenster für Sie Priorität hat. Vermeiden Sie es, automatisch --threshold 0; es schreibt immer dann um, wenn beliebiger Speicherplatz eingespart werden kann, und kann bei einem großen Repository deutlich langsamer sein.

Verhindern, dass die Wartung mit dem nächsten Backup kollidiert

Wenn ein Auftrag legitimerweise auf einen anderen Borg-Prozess warten kann, legen Sie eine begrenzte Sperrwartezeit fest:

borg --lock-wait 1800 create   /mnt/backup/borg-repo::'{hostname}-{now}'   /srv/data

Verwenden Sie keine extrem lange Wartezeit auf die Sperre als Ersatz für eine gute Zeitplanung. Überwachen Sie, wann die Sicherung tatsächlich beginnt und endet.

Wenn mehrere Clients ein Repository gemeinsam nutzen, staffeln Sie ihre Zeitpläne. Die Borg-FAQ weist darauf hin, dass mehrere Repositories die Sperrkonkurrenz verringern können, wenn die clientübergreifende Deduplizierung nicht wichtig ist.

Schnellstatistiken verwenden, wenn die Berichterstellung Prune verlangsamt

Borg 1.4.5 hinzugefügt --quick-stats zum Erstellen, Löschen und Prunen, wobei langsamere repositoryweite Statistiken vermieden werden, wenn sie nicht benötigt werden.

borg prune   --quick-stats   --keep-daily 7   --keep-weekly 4   --keep-monthly 6   --glob-archives '{hostname}-*'   /mnt/backup/borg-repo

Halten Sie freien Speicherplatz bereit, bevor Sie Compact benötigen

Warten Sie nicht, bis das Dateisystem des Repositorys keinen freien Speicherplatz mehr hat. Borg kann normale Schreibvorgänge im Repository auf einem vollständig belegten Dateisystem nicht zuverlässig ausführen.

df -h /mnt/backup
borg info /mnt/backup/borg-repo

Für einen umfassenderen NAS-Sicherungsplan ist der 3-2-1-Sicherungsleitfaden von ZimaOS eine nützliche Erinnerung daran, dass die Aufbewahrung im Repository nur eine Ebene des Sicherungsdesigns darstellt.

Überprüfen Sie den Zeitplan, bevor Sie ihm vertrauen

  • Hat jede Sicherung ein neues Archiv erstellt?
  • Wurde Prune nur nach erfolgreichen Sicherungen ausgeführt?
  • Stimmte die Aufbewahrungsmenge mit dem Dry-Run-Plan überein?
  • Wurde der wöchentliche Compact-Lauf vor der nächsten Sicherung abgeschlossen?
  • Hat sich der freie Speicherplatz nach Compact erhöht?
  • Hat ein Auftrag unerwartet lange auf die Borg-Sperre gewartet?

Wenn Compact wiederholt mit der nächsten Sicherung kollidiert, verringern Sie die Häufigkeit der Komprimierung, behalten Sie den Standardschwellenwert bei, verschieben Sie Compact in ein ruhigeres Zeitfenster oder teilen Sie voneinander unabhängige Workloads auf separate Repositories auf.

Ein wartungsarmes Borg-Muster

TÄGLICH
01:00  borg create
        |
        +-- Erfolg --> borg prune
        |
        +-- Fehler --> alte Archive behalten, Benachrichtigung senden

WÖCHENTLICH
04:00  borg compact

REGELMÄSSIG
        borg check
        Ausgewählte Dateien wiederherstellen

Die zentrale Regel ist einfach: Prune schützt die Aufbewahrungsrichtlinie; Compact gibt Speicherplatz frei; sie müssen nicht mit derselben Häufigkeit ausgeführt werden.

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.