The amount of time it takes to back up and restore a computer depends on the
amount of effort you want to go into. There is a massive selection of software
that will attempt to guide you through the process.
I have been using the utilities that come with a GNU/Linux operating system
for this task for their brazen simplicity and reliability. In this post, I
want to show you how to take a complete bit for bit copy of your hard drive
that can be restored at any time.
There are some caveats. When you restore, it needs to be on a hard drive of
the same size or larger, and will overwrite anything on the drive. The benefit
is that even if you absolutely ruin the data on your drive, restoration will
include everything, including the boot sector, so on start-up it will be as if
nothing ever happened.
Anyways, on to the commands.
What you may have already seen
The target drive must not contain the operating system you want to boot up, so
booting from a live-cd is recommended, unless you are dual booting from a
completely separate drive or something.
> sudo dd if=/dev/sda of=/media/myExternalDrive/myBackup.img
dd is the key here, often jokingly refered to as the "Disk Destroyer," don't
play around with this unless you know what your doing, especially with root
permissions (see the wikipedia article for some history). This will
accomplish our goal in the most inefficient manner possible. But lets go over
this a little bit:
if=/dev/sda: is the special file that represents your hard drive in its
most raw form. There are many ways to determine which one you want, a simple
method is to open it in a graphical file manager, then go to the command line
mount to see a list of mounted drives.
of=...: is the path to the output file. The file doesn't really have a
specific file format, I just append the
.img at the end for my own
This has some pretty drastic drawbacks. First, there is no indication of your
current progress through the operation. You just sit and watch the cursor
blink and maybe watch the output file grow in the file manager. Furthermore
the image is going to contain empty information, the free space on the disk
which are just zero's.
A step further
I now want to include two commands into the previous one. We are going to do
this by piping the output from
dd into the following:
> dd if=/dev/sda | pv | gzip --fast > /media/myExternalDrive/myBackup.img
pv: Pipe viewer, will provide information about the data as it passes
through the commands. Unfortunately, this command does not seem to come
standard with most installations and you might need to install it. Don't worry
though, a live cd will still allow you to install this.
gzip: Compression, will eliminate the zero data from the image.
This is better, it will show how fast the data is going through the pipe and
keep the image down to the size of the actual data (actually, there is one
more caveat with this, read on for more).
pv has no idea how much data its expecting to pass through it and so
it can't guess how long the process is going to take. Furthermore, even with
gzip can be a bottleneck since it only runs on a single
Figuring how the data size
For this I use the tool
parted. I will use it to determine the size of the
entire drive in Bytes.
sudo parted /dev/sda
(parted) unit B
Model: ATA Corsair Force SS (scsi)
Disk /dev/sda: 60022480896B
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system
1 1048576B 60021538815B 60020490240B primary ext4
The command output shows the results for my laptops hard drive, the number I'm
interested in is the
60022480896B, size of my hard drive in Bytes. We take
this and give it to the
-s argument for
pv without the
B at the end (pv
expects the number to be bytes).
Which now gives us:
> dd if=/dev/sda | pv -s 60022480896 | \
gzip --fast > /media/myExternalDrive/myBackup.img
\ simply tells bash to continue on the next line)
And now pv will tell you how long the transfer is going to take. Now lets take
care of the
Speed up compression
I recently came across a utility called pigz (pronounced pig-zee), which
creates completely compatible gzip archives whilst using multiple threads. The
utility had no problem maxing out my cpu for the entire duration of the
operation and sped up the entire process immensely. Check out the homepage
here for more info.
So finally we have:
> dd if=/dev/sda | pv -s 60022480896 | \
pigz --fast > /media/myExternalDrive/myBackup.img
Some finishing touches
I really don't like using
/dev/sda to specify the hard drive, since it is
possible for this to change. Rather try using:
Which gives you a unique identifier for each disk that should never change. (I
believe it doesn't change across systems either, but I'll have to check.)
Also, remember when I said that gzip will eliminate the useless data? Well it
will, but only if it actually sees null values. The empty space on your hard
drive might be filled with random data (especially if you use encryption). If
you want to make sure the free space is actually zero you could do:
> dd if=/dev/zero of=/path/to/somewhere.img && \
Which would create a file containing only zeros, which will get as big as
there is free space available, and then removes it. It takes a while since it
actually forces the drive to write zeros to the disk.
You reverse the process. Use a similar command to decompress the file, pipe it
to pv, then dd which writes it back to the disk, such as:
pigz -d /media/myExternalDrive/myBackup.img | \
pv -s 60022480896 | dd of=/dev/sda
-d option specifies decompression, and is the same for
gzip. Note that
you always want the decompressed version to be piped through
pv since thats
what the number of bytes actually represents. I suppose you could use a
different number for decompression corresponding to the image size and placing
I'm pretty certain it would be possible to mount the file system from the raw
image file with
losetup and some other tools, which would make this strategy
for backup way more useful.
Let me know if you found this interesting, feel free to ask questions in the
There are comments.