Tipnul bych si, ze autor clanku mel na mysli pripad, kdy na jednom mediu (napr. na diskovem poli) mate vice nez jednu zalohu toho jednoho a sameho.
Potom se tam vejdou zalohy treba serveru ne za posledni tyden, ale treba i za vice nez cely mesic, jelikoz stejne bloky tam budou pouze jednou.
Ovsem pri fyzickem poskozeni disku jsou data v haji prave proto, ze byla ulozena jenom jednou. Je tedy potreba pouzivat diskova pole (raidy) atd.
Anebo tak ovsem tim se ochudite o moznost minimalizovat nasledky softwarove chyby v ZFS.
Obcas se vyplati rozhodit mozne chyby mezi sfotware a hardware tak, aby se vam zniceni dat kvuli chybe hw neseslo se znicenim dat kvuli chybe sw s moznym znicenim dat kvuli chybe obsluhy.
Idealni stav: Online a Offline zalohy, vzhledem k clanku ZFS je-li to vyhodne a nejaky ten hw ci sw RAID ktery ovsem ZFS pouzivat nesmi.
Zálohovat něco na stejný filesystem/partition je blbost samo o sobě a vliv deduplikace už je minimální.
Ad dříve virtualizace – v rámci toho image budou knihovny, binárky atd. stejně začínat na hranici bloku. Bude-li deduplikace po blocích, tak se tedy shody najdou. Cena v případě třeba md5(4kb) bude jedno procento.
Technologie celkem zajímává, už před lety mi chybělo něco jako hardlink-copy-on-write. Nejen virtualizace, ale třeba checkout do různých míst to zlepší. Na běžném uživatelském desktopu bude užitek spíš malý.