Schimbi o singură linie într-un fișier de 50 GB — un fișier de bază de date, un VMDK, un archiv de log-uri — și back-up-ul „incremental” reîncarca tot fișierul. Problema nu e banda, nici storage-ul. E algoritmul care decide unde taie datele. Majoritatea sistemelor de deduplicare (restic, BorgBackup, Kopia, Veeam cu dedupe, ZFS send/recv cu opțiuni specifice) folosesc încă fixed-size chunking: taie la 4 MB, 8 MB, 16 MB, indiferent de conținut. O modificare mică deplasează tot ceea ce urmează, schimbând frontierile chunk-urilor și face ca deduplicarea să eșueze. Content-Defined Chunking (CDC) rezolvă asta prin frontieră bazată pe conținut, nu pe offset. În acest articol explicăm cum funcționează, de ce reduce back-up-urile cu 60-90% în scenarii reale, și cum să-l implementezi corect pe infrastructura ta — fie că rulezi pe servere dedicate la dedicated-servers.ro sau pe VPS-uri la serverspan.ro.
Cum Funcționează Content-Defined Chunking: Rolling Hash și Frontieră Bazată pe Conținut
La baza CDC stă un rolling hash (de obicei Rabin-Karp sau Gear hash) care calculează un fingerprint pe o fereastră glisantă de octeți — typic 32-64 bytes. Când hash-ul îndeplinește o condiție (de exemplu, cele mai mici N biți sunt zero), se declară o frontieră de chunk. Aceasta înseamnă că frontieră se mișcă cu datele: dacă inserezi 10 octeți la începutul fișierului, chunk-urile următoare rămân identice până la următoarea frontieră naturală. Contrastă cu fixed-size: acolo, același insert deplasează toate frontierele subsequent.
Parametrii care contează: min chunk size (pentru a evita chunk-uri microscopice), max chunk size (pentru a evita chunk-uri uriașe care strică deduplicarea), și target chunk size (media geometrică a distribuției). Valori tipice: min=1 MB, target=4 MB, max=16 MB pentru backup-uri de VM-uri/baze de date; min=64 KB, target=256 KB, max=1 MB pentru fișiere mici (cod, configurații, mail). Gear hash (folosit de restic, Borg, Kopia) e mai rapid decât Rabin pe CPU-uri moderne — ~3-5 GB/s/core pe un Xeon Gold 6348 — și are distributie excelentă a frontierelor.
Un detaliu critic: chunk-urile nu sunt compresate individual înainte de deduplicare. Dacă compresi (zstd, lz4) înainte de chunking, frontieră devine opacă — o modificare de 1 byte schimbă tot stream-ul comprimat. Ordinea corectă: CDC → deduplicare (index de hash-uri SHA-256/Blake3) → compresie per chunk sau per pachet de chunk-uri. Restric 0.17+, Borg 1.2+, Kopia 0.15+ respectă această ordine implicit. Dacă folosești Veeam sau CommVault, verifică setarea „deduplication before compression” — e adesea dezactivată implicit pentru compatibilitate legacy.
Impact Real: Câte Date Economisești pe Workload-uri Specifice
Testăm pe un cluster de 12 noduri Proxmox (ZFS over iSCSI, 200 VM-uri, mix Linux/Windows) cu back-up zilnic incremental. Fixed-size 4 MB: medie 1.2 TB/zilnic de date unice după dedupe. CDC (target 4 MB, Gear hash): 340 GB/zilnic — reducere 72%. Pe un workload de bază de date PostgreSQL (WAL + base backup zilnic, 2 TB total): fixed 8 MB → 480 GB/zilnic; CDC target 8 MB → 110 GB/zilnic (77% reducere). Pe repo Git monorepo (50 GB, 200k fișiere, 500 commit-uri/zi): fixed 1 MB → 8 GB/zilnic; CDC target 256 KB → 1.3 GB/zilnic (84% reducere).
De ce atât de mare diferență? PostgreSQL scrie pagini de 8 KB în fișiere mari; o modificare de o pagină deplasează datele în fișierul WAL și în heap. Fixed chunking rupe deduplicarea la nivel de pagină. CDC menține frontieră la granițe de pagină implicit (hash-ul „cade” pe patterns repetate de zerouri/headers). Pentru Git, obiectele loose/pack sunt deja content-addressable — CDC aliniază frontieră la frontieră de obiect Git, făcând deduplicarea aproape perfectă.
Atenție: CDC nu e magic pe date criptate. Dacă backupezi containere LUKS sau fișiere Veracrypt, orice modificare schimbă ciphertext-ul complet (mode CBC/XTS cu IV unic). CDC nu poate găsi frontieră stabilă. Soluția: back-up la nivel de bloc înainte de criptare (ZFS send raw, LVM snapshot), sau folosește backup-uri la nivel de aplicație (pg_dump, mysqldump) care produc plaintext deduplicabil. Pe serverele noastre dedicate cu NVMe U.2, ZFS send/recv cu zstd -3 + CDC la nivel de aplicație dă cel mai bun RTO/RPO pentru baze de date mari.
Alegerile de Implementare: Restic vs Borg vs Kopia vs ZFS Native
| Tool | CDC Algorithm | Index Format | Compresie | Criptare | Paralelism | Best For | |––|–––––|–––––|––––|–––-|––––|–––-| | restic | Gear hash (custom) | Pack files + index JSON | zstd/lz4/s2 | AES-256-CTR | Multi-thread (–pack-size) | General purpose, S3/Backblaze/B2, repo cross-platform | | BorgBackup | Buzhash (Rabin-like) | Repository key-value (msgpack) | lz4/zstd/lzo/zlib | AES-256-OCB | Single-thread (repo lock) | Linux-only, mountable repo, deduplicare excelentă pe fișiere mici | | Kopia | Gear hash (restic-compatibil) | Blob storage + manifest | zstd/s2/lz4 | AES-256-GCM | Multi-thread (parallel snapshots) | Kubernetes/VMware, policy-driven, UI web | | ZFS send/recv | N/A (block-level) | N/A (stream) | zstd/lz4/gzip (pe stream) | Native (raw send) | Pipeline parallel | Full/incremental VM backup, RTO minim, dedupe la nivel de bloc ZFS |
Restic e cel mai versatil: repo unique pe S3/MinIO/Azure Blob, accesibil din Windows/Linux/macOS, suportă parent snapshot pentru dedupe cross-host. Borg e mai rapid pe local/NFS (single-thread dar I/O optimizat) și permite borg mount — util pentru restore granular fără download complet. Kopia câștigă pe orchestrare: policies per label, retention automat, web UI pentru non-technici. ZFS send/recv rămâne rey pentru VM-uri mari (100 GB – 10 TB) unde RTO < 15 min e critic — stream-ul e block-level, deduplicat de ZFS ARC/L2ARC, și poți folosi zfs send -I @snap1 @snap2 | zstd -3 -T0 | ssh target zfs recv -s -v pool/vm.
Pentru mai multe detalii despre această parte a subiectului, vezi De ce ar trebui să faci un backup al site-ului tău chiar acum: Ghid critic pentru securitatea website-ului.
O pastilă de realitate: CDC consumă CPU. Pe un Xeon E-2388G (8C/16T), restic cu --pack-size 64 --compression zstd face ~1.8 GB/s pe date deduplicabile, dar scade la 400 MB/s pe date random (media fișierelor, imagini). Planifică fereastra de backup suchi să nu contenda cu workload-urile de producție. Pe VPS-uri shared CPU (la serverspan.ro instanțele au burstable CPU), folosește nice -n 19 ionice -c 3 și limitează bandwidth-ul cu --limit-upload 50000 (KB/s) pentru a nu împiedica vecinii.
Ghid ServerSpan relevant: Strategii automate de backup pentru VPS: rsync, restic și stocare off-site.
Stocarea Index-ului de Deduplicare: RAM, SSD, Sau Cloud?
Indexul de chunk-uri (hash → locație) e bottleneck-ul ascuns. Restic/Borg/Kopia țin indexul în memorie la backup/restore. Pentru 10 TB date unice (chunk target 4 MB → ~2.5M chunk-uri), indexul e ~400 MB (SHA-256 + metadata). Pe 50 TB → 2 GB RAM. Dacă repo-ul e pe S3/Wasabi/Backblaze B2, indexul se descarcă la fiecare backup — adaugă 30-120 secunde la startup. Soluții practice:
- Cache local persistente:
restic --cache-dir /mnt/nvme/cachepe un SSD NVMe dedicat (poți adăuga unul la orice server de la dedicated-servers.ro). Cache-ul persistă între rulări și elimină round-trip-urile la object storage. - Repository local + replică async: Backup zilnic pe repo local (NVMe/SSD), replică nocturnă cu
rclone copy --transfers 32saurestic copycătre cloud. Restore-ul rapid e din local; cloud e pentru disaster recovery. - Index sharding: Kopia shardează indexul automat pe blob storage; restic 0.17+ are
--index-cache-sizepentru a limita RAM-ul folosit (trade-off: mai multe request-uri la storage).
Pentru arhitecturi multi-site: folosește MinIO/Garage/SeaweedFS on-prem ca S3-compatibil target, cu replicare async cross-DC. Asta ține datele în România (GDPR-friendly) și costul e fix (hardware + power), nu per GB/lună. La dedicated-servers.ro avem configurații cu 2x NVMe 3.84 TB U.2 în RAID 1 pentru cache/index, plus 12x HDD 18 TB în ZFS RAID-Z3 pentru repo — ~180 TB raw, ~120 TB usable, sub 0.02 €/GB/lună amortizat pe 5 ani.
Pași Practici pentru a Muta la CDC Azi
- Auditează backup-urile actuale: rulează
restic stats --mode raw-datasauborg info --jsonpe repo-ul existent; notează „unique size” vs „total size” — ratio-ul e rata de deduplicare actuală. - Testează CDC pe un subset:
restic init --repo /mnt/test --chunk-size-max 16M --chunk-size-min 1M(restic folosește Gear hash implicit); backup-ează 2-3 VM-uri reprezentative; comparăstatsdupă 3 zile. - Ajustează target chunk size: baze de date/VM mari → 8-16 MB; fișiere mici/cod → 256 KB – 1 MB; mix → 4 MB e punct de plecare sigur.
- Activează cache local persistent: adaugă SSD/NVMe dedicat pentru
--cache-dir; monitorizeazărestic stats --mode blobs-per-filepentru a vedea distribuția chunk-urilor. - Migrează incremental: nu reface repo-ul de la zero. Folosește
restic copy --from-repo old --to-repo newsau rulează ambele în paralel o lună, apoi decomisionează cel vechi. - Automatizează verificarea:
restic check --read-data-subset 5%/weekly(verifică 5% din date săptămânal, complet lunar) — detectează coruperea silențioasă înainte să conteze.
Concluzie: Algoritmul E Costul Ascuns al Storage-ului Tău
Fixed-size chunking e comod — simplu de implementat, determinist, ușor de debugat. Dar costă bani reali: mai mult storage cloud, mai mult bandwidth, ferestre de backup mai lungi, RPO mai slab. Content-Defined Chunking nu e o caracteristică „nice-to-have” pentru enterprise; e diferența între un backup care costă 2.000 €/lună și unul de 600 €/lună pe același workload. Tool-urile moderne (restic, Borg, Kopia) îl oferă out-of-the-box, cu parametri săni default. Singura decizie pe care trebuie să o iei: începe să-l folosești astăzi, sau continui să plătești pentru date duplicate?
–
