Schimbi o singură linie într-un fișier de 50 GB și backup-ul incremental reîncarca tot fișierul. Nu e vina rețelei, nici a backend-ului de storage. E vina algoritmului care decide unde să taie datele. Majoritatea sistemelor de deduplicare folosesc încă fixed-size chunking — o abordare care părea logică acum douăzeci de ani, dar care astăzi costă bani reali în bandwidth, spațiu pe disc și timp de restore. Content-Defined Chunking (CDC) schimbă paradigma: în locul de a tăia la offset-uri fixe, granurile sunt determinate de conținutul efectiv al datelor. Rezultatul? Deduplicare reală, backup-uri incremental adevărate și costuri reduse cu 60-90% pentru workload-urile tipice de enterprise. Dacă rulezi VM-uri, containere, baze de date sau volume mari de fișiere pe serverele dedicate de la dedicated-servers.ro, înțelegerea și implementarea CDC nu e opțională — e diferența dintre o strategie de backup care scălează și una care te blochează la primul restore critic.
Pentru mai multe detalii despre această parte a subiectului, vezi Dincolo de backup-uri: Un ghid practic pentru recuperare în caz de dezastru pe VPS.
Fixed-Size vs. Content-Defined: Unde se pierd byte-ii
Fixed-size chunking împarte datele în blocuri de dimensiune constantă — de obicei 4 KB, 64 KB sau 128 KB. Pare simplu și eficient până realizăm că orice modificare, chiar și un singur bit, deplasează toate chunk-urile subsolvent. Imaginează-ți un fișier VMDK de 2 TB al unei VM Windows. Instalezi un patch de securitate de 200 MB la începutul fișierului. Cu chunking fix de 64 KB, fiecare chunk de la offset 0 la final se schimbă. Backup-ul „incremental” devine de facto un full backup. CDC folosește un rolling hash (de obicei Rabin fingerprint sau Gear hash) pentru a identifica frontiere naturale în date — puncte unde conținutul local satisface o condiție matematică (ex: hash % N == 0). Aceste frontiere sunt stabile: dacă inserezi date la început, chunk-urile de după rămân identice. Pentru acel VMDK de 2 TB, doar chunk-urile afectate de patch se schimbă. Restul — sute de GB — sunt deja deduplicate. Pe infrastructura de la serverspan.ro, unde backup-urile zilnice de sute de TB sunt norma, această diferență se traduce direct în costuri de stocare și bandwidth.
Algoritmii de hashing rolling: Rabin, Gear și FastCDC
Nu toate rolling hash-urile sunt create egale. Rabin fingerprint (polinom ireductibil pe GF(2)) e standardul academic, dar e costisitor computacional. Gear hash, populat de restic și borg, folosește un lookup table de 256 de intrări pentru a calcula hash-ul într-o singură instrucțiune CPU per byte — ordinelor de mărime mai rapid. FastCDC (2016) optimizează din nou: folosește o fereastră de 64 bytes și un hash simplificat care permite vectorizare SIMD, atingând 5-10 GB/s pe core pe CPU-uri moderne. Alegerile practice: restic (Gear, chunk size mediu 1 MB, min 512 KB, max 8 MB), borgbackup (Buzhash varianta, chunk size configurabil), kopia (Rabin cu optimizări), zstd –long (fixed-size dar cu dictionary sharing). Pentru workload-uri de tip baza de date (PostgreSQL WAL, MySQL binlog), chunk size mai mic (128-256 KB) capturează modificările granulate. Pentru VM images și backup-uri de fișiere mari, 1-4 MB reduce overhead-ul de metadate. Testează cu restic stats --mode raw-data înainte să comiți la o politică.
Implementare practică: De la teorie la producție
Migrarea la CDC nu înseamnă să rescrii backup-urile existente. Poți începe incremental. Pentru restic: restic init --repository s3:bucket/path --chunk-size 1M (valori implicite sunt deja optimizate). Pentru borg: borg create --chunker-params buzhash,19,23,21,4096 repo::archive /data — parametrii sunt: hash algorithm, hash mask bits, window size, min chunk, max chunk. Dacă folosești Rclone ca backend, activează --s3-chunk-size 64M pentru multipart uploads care se aliniază cu chunk-urile CDC. Monitorizează deduplication ratio: restic stats --mode blobs-per-file arată câte blob-uri unice există vs. totale. Un ratio de 0.1-0.3 e excelent pentru VM-uri; 0.5-0.7 e tipic pentru fișiere mici modificare frecventă. Atenție: CDC nu rezolvă deduplicarea cross-file (acela e jobul de indexing global). Pentru asta, asigură-te că repository-ul e unificat per client/tenant, nu per job. Pe serverele noastre dedicate, vedem economii de 70% spațiu când mutăm de la rsync + hardlinks la restic/borg pe același dataset.
Ghid ServerSpan relevant: Strategii automate de backup pentru VPS: rsync, restic și stocare off-site.
Când CDC nu e suficient: Edge cases și mitigări
CDC are limite. Fișierele comprimate/criptate (ziplike, gzipped SQL dumps, imagini Docker layered) par aleatorii la nivel de byte — rolling hash-ul nu găsește frontiere stabile. Soluția: deduplicare înainte de compresie/criptare (dump SQL direct, tar necomprimat, Docker layer-uri separate). Baze de date mari cu page-level modifications (InnoDB, PostgreSQL) beneficiază de chunk size 마이크 (128 KB) și –pack-size mare. Backup-urile de tip snapshot (LVM, ZFS, Ceph RBD) au metadata care se schimbă la fiecare run — exclude-le sau foloseți --exclude-caches / --exclude-if-present. Un gotcha subtil: CDC pe sisteme de fișiere cu deduplicare nativă (ZFS dedup, Btrfs dedup) poate crea overhead în cascadă. Dezactivează dedup-ul la nivel de FS și lasă backup tool-ul să facă CDC. De asemenea, verifică că tool-ul tău folosește convergent encryption (chunk hash = encryption key) pentru deduplicare cross-client fără a împărtăși chei — restic și borg fac asta by default.
Pași practici de implementat azi:
- Auditează backup-urile curente: măsoară ráta de schimbare reală vs. dimensiunea incremental backup-ului
- Alege tool: restic (simplicitate, S3 native), borg (maturitate, FUSE mount), kopia (UI, policy engine)
- Configurează chunk size potrivit workload-ului: 128-256 KB pentru DB/WAL, 1-4 MB pentru VM/images
- Testează deduplication ratio pe un subset reprezentativ înainte de rollout complet
- Monitorizează
blobs-per-fileșiunique bytes / total byteszilnic; alertează dacă ratio-ul crește brusc
Content-Defined Chunking nu e o optimizare cosmetice — e fundația pe care se construiesc backup-urile scalabile moderne. Diferența dintre un restore de 4 ore și unul de 45 minute, între o factură S3 de $2.000/lună și una de $400, între o strategie care te permite RPO de 15 minute și una care te forțează la RPO de 24 de ore. Începe cu un pilot pe un singur workload critic. Măsoară. Iterează. Extinde. Datele tale merită o abordare care respectă structura lor internă, nu una care le taie orbe la granice artificiale.
