I will be assuming you booted with a LiveUSB or LiveCD througout my explanation and you need root for basically anything I explain here.
First lest me explain what "dd" is. The abbreviation means "disk dump" and can make an image over basically everything that is a block device (that's disks to you) of files. Let's go over the basics:
dd if=source-device of=target-device bs=blocksize count=numberofblocks
if Input File, aka, where the data comes from
of Output File, aka, where the data goes to
bs Block Size, aka, how much data you want to "buffer" in memory. If you do not use this, it basically copies directly from one device to another and will be slooooooow. For most operations, do specify something. I usually use something like
bs=1G. Of course, you must have 1GB of free RAM to actually do that
count How many "block" (quantity defined by
bs) you want to move. In the general case this is not needed, because you want all blocks.
Now, imagine you have a SSD of 128GB, named /dev/sda, and you want to "image" it (that's what the operation is called) fully, including everything that's on it. Partition tables. You have a backup disk with plenty of space on /mnt/bigdisk. To image the whole disk, you issue the following command:
dd if=/dev/sda of=/mnt/bigdisk/backup-20160812.img bs=1G
This will take quite a while (but you haven't lived until you do this on a 4TB disk), and finally you will find a 128GB file named backup-20160812.img in /mnt/bigdisk. dd will not give any output during that time and you will notice a big degradation of system performance. Oh, and for the love of all what is good: make sure nothing, not a single partition, is mounted or using /dev/sda.
Once you have the big file, you can do whatever you want with the real disk (well, except destroying it physically). If you want to restore, you do:
dd if=/mnt/bigdisk/backup-20160812.img of=/dev/sda bs=1G
These are bit-exact copies which means the following:
- The size of the big file is exactly the size of the disk
- Obviously you cannot restore to a disk, smaller than that size
- Even if you restore to a disk larger, it may not work. Usually, it winds up being the partitions you want followed by a huge free space block. You'll have a lot of resizing to do and if it's an SSD, check alignment.
- Should the source disk be defective, dd will stop upon errors. If you do not want this, you need to specify extra parameters. The man pages are obviously your friend.
- Again, everything is imaged even unused space. If you have a disk of 100GB, and it's only 10% used, your file will be 100GB large and it will have wasted 90% of it's time on copying unused blocks.
With this knowledge, logic says, you can use dd to backup a single partition. Look at the following command an you may see why:
dd if=/dev/sda1 of=/mnt/bigdisk/backup-sda1-20160812.img bs=1G
The only difference is using /dev/sda1 instead of
/dev/sda (and I used another target filename). Why? Because
/dev/sda represents the full disk, and
/dev/sda1 represents the first partition on that disk. That's it... All the remarks about being a bitwise copy persist.
The file generated to
dd can be gzipped and will result in smaller files. You can do this using pipes. The image command would look like:
dd if=/dev/sda bs=1G | gzip > /mnt/bigdisk/backup-20160812.img.gz
The restore command something like this:
dd if=/mnt/bigdisk/backup-20160812.img.gz bs=1G | gunzip > /dev/sda
Some general remarks for understanding: Omitting the
of will send all output to
stdout. This data is send to
gunzip) using the pipe
gzip/gunzip have no specifed file, they use this data, and gzip it. The output is send to
stdout, which we then send to a file using the
Now off to ntfs partitions.
ntfsclone There are other associated tools you might want to look into (
ntfsfix. Type ntfs on the command line and do tab completion) Instead of just copying all bits, ntfsclone will copy the filesystem structure and data (unless you tell it not to), and thus ignore unused space. This translates into the fact that the files are much smaller and aren't much bigger than the actual "used" filesize of the ntfs partition. Of too the command:
ntfsclone -s -o /mnt/bigdisk/backup-20160812-sda2.ntfsclone /dev/sda2
It will give all sorts of information while it's working, which is much more reassuring than
dd. Anyway, what does it all mean?
-s Means you want to save an image (and not do a device to device clone) -
-o Where do you send the data to. In this case a file. If the file exists, it will refuse to overwrite it.
- The last option in the command is the source, in this case the partition two of sda.
Here for the restore:
ntfsclone -r -O /dev/sda2 /mnt/bigdisk/backup-20160812-sda2.ntfsclone
Again, soothing information and here is what the options mean:
-r means restore from image. It basically is
-s pendant for restore.
-O is where to write the data, in this case it's an upper case -O because that causes it to overwrite the file. This is necessary, because
/dev/sda2 exists already and you want to overwrite it.
- The final option, again, is the source of the data. This is, obviously, the file we just made with the first command.
The size of these images are not changeable. You're not going to restore it to a smaller disk/partition, even if it would fit based on the filesize. The structures of the file system that have been backed up, are bound to the size of the disk. So, even though that image you made of a 100GB partition with 10GB data could fit on a smaller 50GB, it's not going to work. You can restore to a a larger partition, but again, the structures stayed the same, so, you'll have to use
ntfsresize in order to actually be able to use that extra space.
Let's get to
dump. As I mentioned in my comment, I haven't used this in ages. I just backup my data files, as I know that Linux re installations are basically painless, especially if you keep /home on a different partition. What is writen here is basically what I found out while I wrote it. My OpenBSD backup scripts that use dump are so old, I wouldn't dare to say that I still know how they work. To dump.
dump -0 -f /mnt/bigdisk/backup-20160812-sda3.dump /dev/sda3
Again, what does this mean?
-0 is the level of the dump. This is to do incremental backups and is very useful, but for now, you'll remember that a level 0 dump means the full filesystem.
-f The data of the dump is sent to the specified file, in this case:
Restore? Well, you need to know that you can only restore to a clean filesystem and mounted filesystem, so you first have to make sure the target is formatted an clean and mount it:
mount /dev/sda3 /mnt
restore -r -f /mnt/bigdisk/backup-20160812-sda3-level0.dump
-r means restore
-f from file
- The target is the current directory, hence the /mnt
It will probably give you an warning like
restore: ./lost+found: File exists, because
lost+found exists on any newly create filesystem.
Interestingly, given the way it works, you should be able to restore to a smaller disk, but I haven't tried.
Now that I addressed "mounting". Doing any of these operations, shouldn't be done on mounted disks, except for the restore part of dump.
Finally, backing up the MBR and GPT:
The MBR is easy and to be honest, I prefer using it as long as my disks don't exceed 2TB. Anyway, the MBR is basically block 0 on your disk, of which the first part is the boot code and the second part is the partition table. The first 446 bytes of the first sector, the next 66 Bytes are the partition. So, exctracting only the boot code, looks like this:
dd if=/dev/sda of=/mnt/bigdisk/backup-20160812-bootcode.dd bs=446 count=1
Extracting the boot code with the partition table looks like this:
dd if=/dev/sda of=/mnt/bigdisk/backup-20160812-mbr.dd bs=512 count=1
That's it. Obviously, you can only restore these to exactly the same disk (or one with exactly the same characteristics).
As you see MBR is simple. GPT is not and it's a pain. GPT is variable length, and you better Google it for a better understanding. I have no GPT disks on the machine I'm testing this, so double check everything. From what I Google, the tool to use is
gdisk. Alas it seems to be an interactive tool. That's fine, but we want a simple one-liner:
printf "b\\n/mnt/bigdisk/backup-20160812-gpt.gdisk\n" | gdisk /dev/sda
Basically, send the text:
to the applicaton
gdisk working on device
/dev/sda. The file
/mnt/bigdisk/backup-20160812-gpt.gdisk should now contain a backup of the GPT.
The restore should be something like this, but I did not try, so use at your own risk.
printf "b\\nr\\nl\\n/mnt/bigdisk/backup-20160812-gpt.gdisk" | gdisk /dev/sda
This should the following text to to the interactive gdisk menu, to go onto recovery mode and restore from file.
If you start Googling GPT in conjunction with dd, you'll see many people who warn you not to do this because of the uuid used by GPT. That is most certainly true: you will get problems if you have two disks active in the same system with the same uuid. Except of course, that's not what you are doing here. At no time, you'll have two identical uuids in the system if you stick to copying to files (which is what all my examples do)
As you see, this is rather a big chuck of information to digest and I'm not going to even bother reading it again for spelling mistakes, typos, etc. If it's all too much, look into Clonezilla. It might be closer to what you actually need. I might have even saved so much writing, had I started off with telling you that.