Timeline for Can I safely utilize `dd` to backup my drive to a singular image file?
Current License: CC BY-SA 4.0
16 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 30 at 21:39 | comment | added | John Jones | @MarcusMüller Right, overwriting with something like cat /dev/zero > /dev/nvme... could leave old data. I think this is where the "secure erase" interface comes in, as @grawity said above. | |
| Jun 30 at 8:35 | comment | added | Marcus Müller | @JohnJones not any more true than overwriting your data with other data, as Flash translation layers are essentially copy on write to achieve wear levelling. thus, exactly as I wrote, for all practical purposes safe, and at least as safe as overwriting. | |
| Jun 29 at 10:45 | comment | added | grawity | @JohnJones: True, but it really depends on whether your realistic attacker actually is a "particularly determined person" with time/money to spend on that. Yes, I would generally recommend the "secure erase" feature instead (via hdparm for SATA), as that will zero even the areas that can't be written to through the device firmware. | |
| Jun 28 at 1:31 | comment | added | John Jones | blkdiscard doesn't actually zero the underlying flash right? Future reads through the device firmware will return zeroes but a particularly determined person could read the flash directly to recover the data. | |
| Jun 28 at 0:40 | comment | added | phuclv | @MarcusMüller yes, most advanced DOS or Windows restoration tools like Norton Ghost, Acronis Backup & Restore... already had that capability for decades. It's not a byte-by-byte image but still a restoration of that bootable image in a smaller partition | |
| Jun 27 at 16:01 | comment | added | Andrew Henle | Yes, you can. Caveat: Just not on a drive with any mounted filesystems. ;-) | |
| Jun 27 at 12:03 | comment | added | Marcus Müller | @phuclv no, an imaging tool cannot do that, restore to a smaller device (larger is never a problem). What you mean is file-based backups. | |
| Jun 27 at 11:50 | comment | added | Themoonisacheese | @localhost the acronym you're thinking of is TRIM. | |
| Jun 27 at 4:59 | comment | added | phuclv | @GlennWillen it's still somewhat slow compared to a proper imaging tool, because it knows nothing about the filesystem's structure and needlessly read empty sectors. An imaging tool can even skip non-zero unused blocks or deleted files, which makes it much faster, beside allowing you to restore to a drive with different size | |
| Jun 27 at 4:36 | comment | added | localhost | @GlennWillen pretty sure I read somewhere that most SSDs do actually return zeros for empty space. There was a four-letter acronym for that behavior but I couldn't find anything with a quick google just then however. | |
| Jun 26 at 18:02 | comment | added | Marcus Müller | right, and exactly because I knew that comment would come I added the clause "at least as demonstrated in your command line" when I wrote that answer :) | |
| Jun 26 at 17:55 | comment | added | Glenn Willen | "dd really makes little sense if you're backing up a whole image, and will tend to be slow (as it dictates a block size that might interfere with physical read sizes). Also, at least as demonstrated in your command line, you'll probably end up generate a large output file full of zeros that needn't occupy space, but do." Neither of these things has to be true -- you should always use bs= to set the block size, and you can use conv=sparse to avoid wasting space on zeros. (However, be aware that it can only sparsify actual zeros, and empty disk space is often not zeroed.) | |
| Jun 26 at 9:53 | history | edited | Marcus Müller | CC BY-SA 4.0 | added 565 characters in body |
| Jun 26 at 9:36 | history | edited | Marcus Müller | CC BY-SA 4.0 | deleted 1 character in body |
| Jun 26 at 9:33 | history | edited | Marcus Müller | CC BY-SA 4.0 | deleted 10 characters in body |
| Jun 26 at 9:30 | history | answered | Marcus Müller | CC BY-SA 4.0 |