I have read this post - How to dd a remote disk using SSH on local machine and save to a local disk

However, the following code doesn't work:

"dd if=/dev/sda | gzip -1 -" | dd of=image.gz

As I do not have any /dev/sda directory. I'm assuming this is because I'm using Debian 7.0.

Any help to take a complete copy of my vps is highly appreciated.

  • You can find the path to your disk's device file using lsblk, fdisk, df... – John WH Smith Oct 8 '16 at 17:29
  • Good call. fdisk -l worked and my device file is /dev/vda1, but does that contain my entire system? All configurations and everything? – DomainsFeatured Oct 8 '16 at 17:36
  • Can you post the fdisk and df output? – Danny Staple Oct 8 '16 at 18:11
  • 3
    Trying to dd a live filesystem us asking for trouble. It might get an uncorrupted copy but it probably won't, and when you come to use the image it won't restore. I would strongly recommend that you either use something like rsync to perform a file-level backup or you ask your VPS provider if they can snapshot the running system and put the image in a place accessible for you to copy. – roaima Oct 8 '16 at 20:15
  • Hi @roaima, thank you for the input. I will try some of the answers below. – DomainsFeatured Oct 9 '16 at 14:05

The device name of a disk depends on what type of disk it is (more precisely, on what type of bus and controller the disk is connected to, and what driver handles them). /dev/sda is the typical name for the first disk in a PC (other names can be used depending on the driver, e.g. for some older types of disk controllers or some hardware RAID controllers). In a VPS, the disk is normally a virtual one, and the device name depends on the virtualization technology, e.g. /dev/vda or /dev/xvda. You can find the block device names on your system with df or lsblk.

But do not use this to make a backup from a live system! You are very likely to end up with an unreadable backup. If the disk content changes while you're making the backup, which is unavoidable on a live system (e.g. a log gets written somewhere), then your image will be inconsistent — a bit of the old state, a bit of the new state — and may not be recoverable.

The preferred way to make a backup is to make a snapshot, i.e. a view of the filesystem that's frozen and doesn't change even as the real system keeps changing. How to do that, and whether it is at all possible, depends on how your system is set up. Some filesystem types such as btrfs and zfs have a built-in snapshot ability. LVM also can make snapshots of a volume.

If you can't make a snapshot (or even if you can) make a file-level backup. A file-level backup from a system that changes will be inconsistent, but if you don't make “important” changes then the backup will be usable. For example, if you move files around, they may be omitted from the backup if they happen to be moved from a directory that the backup program has not traversed yet to one that it has already traversed. On the other hand, if a log file keeps growing, you'll have some intermediate version of that file, but you won't have a damaged filesystem image. If a file is deleted and another file is created, you may have none of those files, or either one, or both, but you won't have the directory entry of the old file pointing at some data in the new file.

You can use GNU tar (as root!) to back up a Linux system complete with important metadata.

ssh root@vps 'tar -cJf - --acls --selinux --one-file-system /' >vps.tar.xz
  • HI @Gilles, thanks for the input. I was unaware of the risks. Could you provide an explanation of the code please? – DomainsFeatured Oct 9 '16 at 14:06
  • Just wanted to say thank you again for pointing this out. I ended up using a tar command that worked well :-) – DomainsFeatured Oct 10 '16 at 3:47

/dev/sda is the convention when communications with your disk go through the SCSI driver directly. In a comment, you said your disk was at /dev/vda : such naming is somewhat common on virtualised solutions. If I were to guess, I'd say you're talking about a KVM-managed VPS.

If you want to backup your /dev/vda disk, simply use slm's suggestion:

ssh user@remote "dd if=/dev/vda | gzip -1 -" | dd of=image.gz

This will backup /dev/vda entirely, and you will be able to re-dd it onto another disk later, provided there's enough room there.

fdisk -l worked and my device file is /dev/vda1, but does that contain my entire system?

You read that too quickly. /dev/vda1 is a partition (a piece) of the /dev/vda disk. Three things to note:

  • If your system consists solely of a root partition at /dev/vda1, then backing up /dev/vda1 is enough. You don't need to backup the whole drive (which also includes disk "headers").
  • If your system spans across multiple partitions on /dev/vda, then you must dd all of them in order to get everything (or just dd the whole disk like above).
  • Your system might also be using several disks! It is a bit rarer, but I guess it could happen. You could have the / and /var partitions on /dev/vda (at /dev/vda1 and /dev/vda2 for instance), and the home directories (/home) at /dev/vdb1 on another drive (/dev/vdb).

In your case, I'd say lsblk is the right tool to understand your setup. Run it and have a look at the MOUNTPOINT column. Whenever there's something there, your system is using the partition on that row. If you want to backup the whole thing, you have to either:

  • Download all used partitions (/dev/vdXY) to files. A partition is used when it is mounted somewhere.
  • Download all used disks (/dev/vbX) to files. A disk is used when it contains at least one used partition.

If other words, you can either run:

ssh user@remote "dd if=/dev/vda | gzip -1 -" | dd of=disk1.gz
ssh user@remote "dd if=/dev/vdb | gzip -1 -" | dd of=disk2.gz
# ... and so on, once per used disk.

or (using my 2-disk example from above) :

ssh user@remote "dd if=/dev/vda1 | gzip -1 -" | dd of=root.gz
ssh user@remote "dd if=/dev/vda2 | gzip -1 -" | dd of=var.gz
ssh user@remote "dd if=/dev/vdb1 | gzip -1 -" | dd of=home.gz
# ... and so on, once per used partition.

An advantage to backing up partitions separately is that it might be easier to explore them locally when needed:

$ gzip -d home.gz                        # decompress the backup
$ sudo mkdir /mnt/home_bak               # create a mount point
$ sudo mount -o loop home /mnt/home_bak  # mount the backup
$ cd /mnt/home_bak                       # explore the home backup

Finally, remember that lsblk only lists mounted partitions. If you've setup extra partitions (ones you don't mount automatically at boot), remember to include those. Chances are you'd remember if you had done that when installing your VPS.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.