Live data from Hacker News

A snapshot of your computer with dd, pv and gzip - Part 1

allgood38.github.io

31–34 of 34 posts

Re: A snapshot of your computer with dd, pv and gzip - Part 1

#31
post #17

I used dd booting from a USB stick to transfer a Windows install from hard drive to SSD this weekend - there are a number of steps that can be done beforehand to tighten up the size of the final output. These steps are also useful for virtual machines, but they tend to take quite a while... (1) Defrag - built-in / maybe SysInternals contig http://technet.microsoft.com/en-us/sysinternals/bb897428 (2) Defrag the page f…

Why would you possibly want to copy a pagefile over :D

Actually with the current RAM prices you don't need one at all.

Re: A snapshot of your computer with dd, pv and gzip - Part 1

#32
post #18

I don't always backup an entire system with 'dd', but when I do: dd if=/dev/da0 | ssh user@rsync.net "dd of=backup.dd" or maybe: pg_dump -U postgres db | ssh user@rsync.net "dd of=db_dump"

i'd look at using pv for the input, makes for a nicer output

pv /dev/da0 | ssh user@rsync.net "dd of=backup.dd"

Re: A snapshot of your computer with dd, pv and gzip - Part 1

#33
The author mentions that removed files stick around on disk after being removed, and that this can increase the size of a compressed bit-for-bit copy.

They then suggest you can mitigate this by writing zeros to a file before rm'ing it. However, this is slow in the general case, and doesn't help if you've already rm'd the file.

As an alternative, the 'sfree' utility, available in the debian package 'secure-delete', can be used to fill the unallocated portions of a disk with zeroes (or random data).

sfree -llz

will write zeroes to the free areas of a disk. -ll limits it to only one pass over the disk, and -z makes that pass write zeroes, instead of random data.

man page: http://manpages.ubuntu.com/manpages/lucid/man1/sfill.1.html

Re: A snapshot of your computer with dd, pv and gzip - Part 1

#34
post #33

The author mentions that removed files stick around on disk after being removed, and that this can increase the size of a compressed bit-for-bit copy. They then suggest you can mitigate this by writing zeros to a file before rm'ing it. However, this is slow in the general case, and doesn't help if you've already rm'd the file. As an alternative, the 'sfree' utility, available in the debian package 'secure-delete', ca…

This is a pretty cool utility, I never really did like just creating a blank file, I'd rather use an explicit tool

I'll update the article.

Post reply on HN