3 ms·
Why is dd fragile? I mean, yes doing so while the filesystem is mounted is like Russian Roulette, but if the filesystem is unmounted? I see that it isn't very e
by arendtio 8y ago
Why is dd fragile? I mean, yes doing so while the filesystem is mounted is like Russian Roulette, but if the filesystem is unmounted? I see that it isn't very efficient, but I never had any problems with reliability.
Silent corruption might actually be a problem, but that is something you won't solve by backing up files and directories instead of block devices. After all, a block devices backup just contains more information than the files and directories backup. The only advantage of filesystem backups is that you can easier validate if a file should have changed, but even if you detect that it changed even if it shouldn't have, you still need some kind of checksum or so to find out which version is correct.
On the other hand, if you back up the files and directories you have to care about the filesystem type and if there are special types like links, devices nodes and the like. On that side, I had enough unpleasant experiences that I am trying to avoid that trouble.
To restore single files I can simply mount the image on a loop device, so no problem there.
- zulgan 8y agothere is absolutely no technical problem doing it on unmounted filesystem but it just imposes certain restrictions that I dont think are worth their cost considering in many cases you want to copy live files, you have to copy them to place you can unmount, so now you have 2 problems if you dont gzip the dd you risk pure cosmic microwave background bitflips and no checksums, and they can corrupt superblocks and etc if you gzip it (to have crc sums) you cant restore partial files from it so easily unless you use squashfs and significantly complicate the process so tar and gzip is more robust (compared to the dd) just because of the crc (of gzip not of tar), size and portability