SSH – How to DD a Remote Disk Using SSH and Save to Local Disk

ddhard-diskremotessh

How can I create a backup of a remote disk using SSH on my local machine and save it to a local disk?

I've tried the following:

ssh hostname@my.ip.address "sudo dd if=/dev/sdX " | \
  dd of=/home/username/Documents/filename.image`

However, I receive the following error:

no tty present and no askpass program specified

Best Answer

If your intent is to backup a remote computer's HDD A via SSH to a single file that's on your local computer's HDD, you could do one of the following.

Examples

run from remote computer

$ dd if=/dev/sda | gzip -1 - | ssh user@local dd of=image.gz

run from local computer

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

Live example

$ ssh skinner "dd if=/dev/sda5 | gzip -1 -" | dd of=image.gz
208782+0 records in
208782+0 records out
106896384 bytes (107 MB) copied, 22.7608 seconds, 4.7 MB/s
116749+1 records in
116749+1 records out
59775805 bytes (60 MB) copied, 23.9154 s, 2.5 MB/s

$ ll | grep image.gz
-rw-rw-r--.   1 saml saml  59775805 May 31 01:03 image.gz

Methods for monitoring?

Login via ssh in another terminal and ls -l the file to see what it's size is.
You can use pv to monitor the progress of a large dd operation, for instance, for the remote example above, you can do:
```
$ dd if=/dev/sda | gzip -1 - | pv | ssh user@local dd of=image.gz
```
Send a "SIGUSR1" signal to dd and it will print stats. Something like:
```
$ pkill -USR1 dd
```

References

The methods mentioned above for monitoring were originally left via comments by @Ryan & @bladt and myself. I've moved them into the answer to make them more obvious.

Related Solutions

SSH Sudo Expect – Run Command with Sudo on Remote Machine

I think you missed a level of quotes escaping. At this high level of escaping, it is best to simply make a little script for every stage where otherwise quotes would be required.

Otherwise, you could try this modified version (but mind you, I don't encourage this coding style!)

function _remoteInstallation(){
    local retval=1
    local debToInstall=$(basename "$1")
    local remoteMachine="$2"
    spawned=$(expect -d -c "
          set timeout 1800
          spawn \"/usr/bin/ssh -t borrajax@$remoteMachine /usr/bin/sudo /usr/bin/dpkg -i /home/borrajax/Documents/$debToInstall\"
          expect {
                \"Are you sure you want to continue connecting\" { send \"yes\r\"; exp_continue }
                \"password\" { send \"myPassword\r\";  exp_continue }
                \"[sudo] password\" { send \"myPassword\r\";  exp_continue }
                default { exit 1 }
          }
    " )
    retval=$?
    return $retval
}

Debian – How To dd or cp Entire Disk On Debian Remote Machine To Local Machine

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