Der Bedarf wächst mit der Zahl der Chunks, nicht mit einer Blockgröße. Mit der Standard-Chunk-Größe (Mittel 256 KiB, real etwa 300 KiB) hat 1 TB belegte Quelle rund 3,5 bis 4 Mio. Chunks:
| Wo | Bedarf (Größenordnung je TB gespeicherter Daten) |
|---|---|
Index des Stores (index.lmdb) | einige hundert MB auf der Platte; schnell, wenn er auf SSD liegt (--index-dir) |
| Agent | Puffer der Pipeline (begrenzt), dazu eine Karte der freien Bereiche (höchstens 16 Mi Einträge) |
mirror (erster Lauf einer Quelle) | liest alle Manifeste, etwa 128 MB je TB |
export, Restore aus einem Archiv | Index im Speicher (Datei: etwa 170 MB je TB; Strom von stdin: etwa 112 MB je TB) |
bkp_maintenance store-info zeigt die geschätzte Indexgröße. Liegt der Store auf NFS/SMB, muss der Index lokal liegen (--index-dir).
25.1 Wie die Chunk-Größe wirkt#
Der Agent schneidet die Quelle mit FastCDC an inhaltsabhängigen Stellen. Die mittlere Größe (--chunk-size, Zweierpotenz, Standard 256K; das Minimum ist ein Viertel, das Maximum das Vierfache) ist eine Abwägung:
| kleinere Chunks (z. B. 64K) | größere Chunks (z. B. 1M) | |
|---|---|---|
| Deduplizierung | findet mehr Gleiches, kleine Änderungen kosten wenig | eine kleine Änderung macht einen ganzen großen Chunk neu |
| Index | größer (mehr Einträge) | kleiner |
| Restore | mehr einzelne Lesezugriffe, auf HDD langsamer | weniger, größere Lesezugriffe |
- Die Größe ist je Store (bzw. Generation) fest;
--chunk-sizewirkt nur beim Anlegen. Eine neue Generation übernimmt ohne Angabe die Größe der vorigen. - Alle Sinks eines Laufs müssen gleich chunken; ein neu hinzukommender Store übernimmt die Größe der anderen.
25.2 Messen statt raten#
Mit --chunk-probe yes (Standard) misst der Agent nebenbei an einer Stichprobe (1/32 der Chunks), wie ein Viertel und das Vierfache der aktuellen Größe dedupliziert hätten, und meldet es dem Store, auch über das Netz. Gespeichert wird davon nichts; es kostet etwa einen weiteren Chunker-Durchlauf. store-info zeigt die Schätzung je Größe und, sobald genug Daten da sind (7 Sicherungen über 5 Tage), eine Empfehlung:
bkp_maintenance store-info --store /backup/default.cbsEnde der Ausgabe (Testdaten, daher noch keine Empfehlung)
chunk size probe: 2 backup(s) over 0.0 day(s), 2 sample(s) of 256K chunks
SIZE RUNS EST. WRITTEN VS. NOW COMPR. EST. INDEX
64K 2 17.4 MiB +86% 100% 0.6 MiB
256K 2 9.4 MiB (now) 100% 0.1 MiB
1M 2 33.6 MiB +258% 100% 0.1 MiB
memory: 1.4 GiB; index on an unknown medium, store on an unknown medium
restores: 1, 188.4 MiB/s, 0.15 ms per read
recommended: not enough data yet (needs 7 backups over 5 days and 256 samples)EST. WRITTEN schätzt, wie viel bei dieser Größe über die gemessenen Sicherungen geschrieben worden wäre, EST. INDEX die Indexgröße. In die Empfehlung gehen auch Arbeitsspeicher und Speichermedium ein (passt der Index nicht mehr in den Speicher und liegt er auf einer drehenden Platte, spricht das für größere Chunks); restores zeigt die beim Restore gemessene Geschwindigkeit.
25.3 Chunk-Größe umstellen#
bkp_agent ... --type full --chunk-size 1Mbeginnt in allen Sinks des Laufs gemeinsam eine neue Generation mit der neuen Größe. Ältere Runs bleiben in ihrer Generation lesbar, bis prune sie entfernt. Bestehende Runs umzuschneiden (rechunk) ist nicht vorgesehen. Der erste Run der neuen Generation kostet Platz und Zeit wie eine vollständige Sicherung.
Tipp: Bei sehr großen, selten geänderten Volumes auf HDD lohnt eher eine größere Chunk-Größe (Index und Restore), bei vielen kleinen Änderungen und ähnlichen Rechnern in einem Store eher die Standardgröße oder kleiner. Im Zweifel die Empfehlung von store-info abwarten.