• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Using "dd" and "gzip" for SSD backup

S

shadowwyvern

Gawd
Joined
Sep 22, 2005
Messages
604
Hello,

I have a laptop system running Windows 8 and I need to make an image of it.

Rather than mess with whatever Windows 8 provides (unless its really good?), I would like to just make a simple image of the drive using linux's "dd" run from a usb boot. The problem is, that would make the image the size of the drive (128GB in this case).

The common solution to this issue seems to be to write zeros to all empty filesystem space, and then run the image through a compression tool.

My question is: How bad is it for the SSD to do this? I would secure erase after doing so, and it is only a rare case. Even if I have do do this 100 times over the drive's life - thats still only 100 writes to every cell, which doesn't sound too bad.

A corollary question: Does the trick of creating a large file and then deleting it from within a TRIM-aware system actually work to "clean up" an SSD without having to do a secure erase? This issue arises during the process of restoring an image - "dd" will write every drive address, and then you need a way to purge all the resulting useless data.
 
I'm not sure I understand what you mean, during the backup you will only read the SSD, not write to it, so there is no concern there.
 
What happens is, in lieu of an actually smart tool that understands NTFS and other filesystems, "dd" just blindly copies the drive, byte-for-byte (hence its name :)). The problem is then that backup size = disk size, not data size which is likely much smaller.

An easy way around this is to write all the empty space on the file system with the same value (eg,.0) an then apply a compression tool on it - which will instantly crunch all the space down to nothingness.

That's why the "backup" would involve a write to all free space on the SSD.

Now, this might be a bit of a moot point, because I believe that some SSD's have so-called "deterministic read after trim" - in which case my corollary question of how to force a bulk trim *without* a secure erase comes into play.
 
Huh? Like MrsOldMX said, just use Clonezilla. Clonezilla will not only gzip the image file for you, it is also smart enough to only copy the used space. You are overthinking this.
 
You want to use ntfsclone from ntfsprogs. http://en.wikipedia.org/wiki/Ntfsprogs

It understands ntfs and only outputs blocks that are used. Unused blocks are outputted as zeros. Output files are sparse. DD the bootblock and the boot partition(s) and then use ntfsclone to clone the ntfs partition.

Clonezilla uses ntfsclone under the covers on ntfs volumes.
 
You must log in or register to reply here.
Back
Top