So optimieren Sie die Restic-Paketgröße für ein lokales NAS-Repository

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 Optimize Restic Pack Size for a Local NAS Repository

Für ein lokales NAS-Repository sollten Sie restics Standardwert von 16 MiB beibehalten, sofern Messungen nicht zeigen, dass der Overhead der Repository-Dateien oder das Suchverhalten der HDD den Durchsatz begrenzt. Wenn das NAS ein Repository mit mehreren Terabyte auf rotierenden Festplatten speichert, sind Packs mit 32 MiB oder 64 MiB sinnvolle Werte für einen Benchmark, bevor Sie größere Werte in Betracht ziehen.

Die Pack-Größe ist nicht identisch mit der Deduplizierungs-Chunk-Größe von restic. Restic teilt Dateidaten zunächst in inhaltsdefinierte Blobs auf und gruppiert diese anschließend in Pack-Dateien. Durch das Ändern der Ziel-Pack-Größe wird geändert, wie diese Blobs im Repository gebündelt werden; das Polynom des Repository-Chunkers oder die Inhaltshashes werden dadurch nicht verändert.

Mit dem Standardwert von 16 MiB beginnen

Die aktuelle Anleitung zur restic-Optimierung besagt, dass die standardmäßige Ziel-Pack-Größe 16 MiB beträgt. Außerdem wird darauf hingewiesen, dass größere Pack-Dateien die Anzahl der Repository-Dateien reduzieren und bei einigen auf lokalen HDDs gespeicherten Repositorys die Sicherungsleistung verbessern können.

restic version
restic -r /mnt/nas/restic-repo snapshots
restic -r /mnt/nas/restic-repo stats --mode raw-data

Notieren Sie vor der Anpassung die restic-Version, die Repository-Größe, die Anzahl der Snapshots, den Speichertyp und die aktuelle Sicherungsdauer. Wenn das Repository bereits innerhalb des verfügbaren Sicherungsfensters fertig wird, kann eine größere Pack-Größe zusätzliche Komplexität verursachen, ohne einen nützlichen Vorteil zu bringen.

Verstehen, was die Pack-Größe tatsächlich ändert

Das Design des restic-Repository-Formats erklärt, dass Dateiinhalte in inhaltsdefinierte Blobs aufgeteilt und diese Blobs in Pack-Dateien gruppiert werden.

Quelldateien
   |
Inhaltsdefinierte Chunk-Aufteilung
   |
Deduplizierte Blobs
   |
Pack-Gruppierung
   |
Repository-Datendateien

Ein größeres Pack-Ziel bedeutet im Allgemeinen weniger, dafür größere Repository-Dateien. Dadurch kann eine rotierende Festplatte weniger Zeit für Metadaten- und Dateiöffnungs-Overhead aufwenden. Die Deduplizierung identischer Dateiinhalte wird dadurch nicht verbessert.

Prüfen, ob das NAS tatsächlich durch die Pack-Größe begrenzt wird

Beobachten Sie vor einer Anpassung die Auslastung des Repository-Laufwerks während einer normalen inkrementellen Sicherung. Ein Repository auf einer lokalen HDD, bei dem viele kurze Suchvorgänge und Metadatenoperationen anfallen, während der Durchsatz niedrig bleibt, ist eher ein geeigneter Kandidat als ein SSD-Repository, das bereits mit hoher Geschwindigkeit sequenziell schreibt.

iostat -xz 2

Achten Sie auf eine anhaltend hohe Datenträgerauslastung, erhöhte Await-Zeiten und einen geringen Durchsatz im Vergleich zu einem großen sequenziellen Schreibvorgang. Prüfen Sie außerdem die CPU-Auslastung und die Lesegeschwindigkeit der Quelle. Wenn Komprimierung, Hashing, Quell-I/O oder Netzwerk der Engpass ist, wird eine größere Pack-Größe das Problem nicht lösen.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

16, 32 und 64 MiB mit vergleichbaren Repositories benchmarken

Der sauberste Vergleich verwendet für den Test eigens erstellte, entbehrliche Repositories. Verwenden Sie denselben Quelldatensatz, dasselbe NAS-Volume, dieselbe Restic-Version und dieselbe Anzahl an Backend-Verbindungen.

restic --pack-size 16 -r /mnt/nas/test-restic-16 init
restic --pack-size 16 -r /mnt/nas/test-restic-16 backup /srv/testdata

restic --pack-size 32 -r /mnt/nas/test-restic-32 init
restic --pack-size 32 -r /mnt/nas/test-restic-32 backup /srv/testdata

restic --pack-size 64 -r /mnt/nas/test-restic-64 init
restic --pack-size 64 -r /mnt/nas/test-restic-64 backup /srv/testdata

Messen Sie die verstrichene Zeit, den Datendurchsatz auf dem Repository-Datenträger, den Verbrauch an temporärem Speicherplatz und die daraus resultierende Anzahl an Datendateien. Wiederholen Sie die Durchläufe nach Möglichkeit, damit die Effekte des Seiten-Caches das Ergebnis nicht bestimmen.

Temporären Speicherplatz berücksichtigen, bevor die Pack-Größe erhöht wird

Restic dokumentiert den Bedarf an temporärem Speicher ungefähr wie folgt:

Pack-Größe × (Backend-Verbindungen + 1)

Bei fünf Backend-Verbindungen und einem Zielwert von 64 MiB sind das mindestens 384 MiB temporärer Speicherplatz. Das lokale Backend verwendet derzeit standardmäßig weniger Verbindungen als die meisten Remote-Backends, aber dieselbe Regel gilt weiterhin.

df -h "${TMPDIR:-/tmp}"
export TMPDIR=/mnt/fast-temp/restic
mkdir -p "$TMPDIR"

Größere temporäre Packs können außerdem den Speicherverbrauch erhöhen und dazu führen, dass mehr temporäre Schreibvorgänge den SSD-Speicher erreichen, anstatt im Cache zu verbleiben.

Bei Befehlen, die in das Repository schreiben, dieselbe Pack-Größen-Einstellung beibehalten

Restic empfiehlt, die Pack-Größen-Einstellung für jeden Befehl anzugeben, der das Repository verändert. Verwenden Sie für den gesamten Auftrag eine Umgebungsvariable:

export RESTIC_REPOSITORY=/mnt/nas/restic-repo
export RESTIC_PACK_SIZE=64
export RESTIC_PASSWORD_FILE=/root/.config/restic/password

restic backup /srv/data
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6
restic prune

Eine Änderung der Pack-Größe definiert die Deduplizierungs-Chunking nicht neu, kann aber zu Packs unterschiedlicher Größe führen. Einheitlichkeit erleichtert die spätere Wartung und die Interpretation von Leistungsvergleichen.

Erwarten Sie nicht, dass vorhandene Packs automatisch angepasst werden

Eine neue Einstellung für die Packgröße wirkt sich auf neu erstellte oder neu gepackte Daten aus. Vorhandene Pack-Dateien werden nicht allein deshalb neu geschrieben, RESTIC_PACK_SIZE Änderungen.

Wenn Sie absichtlich kleinere vorhandene Packs durch prune neu packen lassen möchten, unterstützt die aktuelle restic-Version --repack-smaller-than. Lesen Sie zuerst die Optionen zum Repacken mit prune.

restic prune --dry-run --repack-smaller-than 32M

Beginnen Sie mit einem Probelauf. Erzwingen Sie kein vollständiges Repack nur, damit jede Pack-Datei einheitlich aussieht.

Integrität nach der Anpassung überprüfen

restic check
restic check --read-data-subset=5%

Wählen Sie einen Prüfzeitplan, der zur Repository-Größe passt. Die Hinweise zur Repository-Fehlerbehebung von restic behandeln Integritätsprüfungen als Grundlage für die Diagnose von Repository-Schäden.

Für ein umfassenderes Backup-Konzept kombinieren Sie das lokale Repository mit einer weiteren unabhängigen Kopie. Die 3-2-1-Backup-Strategie von ZimaOS erklärt, warum lokale Redundanz und ein separates Ziel unterschiedliche Ausfallszenarien abdecken.

Verwenden Sie diese Entscheidungsregel

Bleiben Sie bei 16 MiB, wenn Backups das Zeitfenster bereits einhalten oder der Engpass an anderer Stelle liegt.
Testen Sie 32 MiB, wenn ein großes HDD-Repository viel Zeit mit Metadaten- und Operationen an kleinen Dateien verbringt.
Testen Sie 64 MiB, wenn 32 MiB hilft und der Speicherplatzbedarf für temporäre Daten problemlos bleibt.
Hören Sie auf zu erhöhen, wenn die Verbesserungen abflachen oder der temporäre I/O-Aufwand steigt.

Die beste Packgröße ist der kleinste Wert, der den Repository-Overhead messbar reduziert, ohne einen neuen Engpass zu schaffen.