Backing up 18 years in 8 hours
Is there a good reason to back up raw disk images with block-level deduplication, rather than running file recovery to get filesets, and then doing file-level deduplication?<p>On the one hand, I can imagine &quot;cryonically&quot; preserving a disk image for a later, better filesystem recovery program to come around. (This &quot;cryonic&quot; approach would give even better results by preserving bit-level analogue flux recordings of the disk platters, rather than relying on the output of digital reads from the disk heads.)<p>On the other hand, the longer you leave these disk images as dead blobs of data, the more layers of legacy container+encoding formats you&#x27;ll have to try to get your system emulating when you finally do want to pull the files off. One day your OS won&#x27;t have drivers for reading e.g. FAT16, or zfs2, or ReiserFS2.11, nor will it be able to parse out the meaning of an MBR-partitioned disk. Reaching back through Linux kernel archives for something old enough to understand those things, will result in a kernel that won&#x27;t boot your PC. You&#x27;ll end up having to do something convoluted with qemu just to get your disk read.<p>Personally, I&#x27;d much rather throw out all the intermediate containers I can, as soon as I can: not just extracting files from the disk&#x27;s filesystem, but further extracting files from any proprietary archive formats on the disk (using the extractor tools probably installed on the same disk), and even <i>canonicalizing</i> containers like AVI by remuxing them into modern extensible formats like MKV. The goal being to give a file-level deduplication process the best possible inputs to work with, most likely to match: not just for space-saving, but because reducing &quot;junk duplicates&quot; helps greatly in actually <i>finding</i> anything in all that mess, let alone organizing it.