123

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 [email protected] "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

Anthon
  • 78,313
  • 42
  • 165
  • 222
Qu0rk
  • 1,371
  • 2
  • 10
  • 9

5 Answers5

184

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?

  1. Login via ssh in another terminal and ls -l the file to see what it's size is.

  2. 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

  3. Send a "SIGUSR1" signal to dd and it will print stats. Something like:

     $ pkill -USR1 dd

  4. Use dd's progress switch, status=progress

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.

Stephen Kitt
  • 411,918
  • 54
  • 1,065
  • 1,164
slm
  • 363,520
  • 117
  • 767
  • 871
  • I tried this for a similar problem (backing up remote computer `ONE`'s hard drive to remote computer `TWO`'s storage), like this:
    [root@ONE]# dd if=/dev/sda1 | ssh root@TWO `dd of=/root/Public/ONE/sda1.img`
    409600+0 records in 409600+0 records out 209715200 bytes (210 MB) copied, 0.894929 s, 234 MB/s Pseudo-terminal will not be allocated because stdin is not a terminal root@TWO's password: The problem is that the `/root/Public/ONE/sda1.img` file was created on `ONE`, not on `TWO` as expected. How do I fix this?     – Urhixidur Jul 15 '15 at 13:59
  • 1
    Can someone give us an example of using `pv` from the local machine? Thank you. – TCB13 Dec 16 '15 at 15:08
  • it is better to use lbzip2 or pigz insted of gzip – Shimon Doodkin Mar 10 '16 at 00:15
  • why do i need " | dd of=image.gz" at end? (not just ">image.gz") because dd takes 100% of one cpu – Shimon Doodkin Mar 10 '16 at 00:19
  • 12
    Regarding monitoring: Newer dd versions also have the `status=progress` option. Thus, you do not need to run `pkill -USR1 dd` from another terminal anymore. – Till Schäfer Jan 02 '18 at 15:23
  • I only have tar on my old macOS. I know how to use tar, but I’m having trouble translating your command into tar’s format. Thanks in advance. – mannyglover Mar 03 '19 at 05:09
  • excellent work around. thanks – Arun Panneerselvam Apr 02 '20 at 14:30
  • 1
    restore: gunzip -c xxx.gz | pv | dd of=/dev/sda1 – nobjta_9x_tq Apr 11 '20 at 06:12
  • you also want to bs=1M in there because by default dd will copy in 512 byte chunks. 1M much faster. – stu Feb 06 '22 at 01:40
  • Is it safe to read /dev/sda if the machine is actively booted from it? – jorisw Jul 15 '22 at 10:11
15

The error you receive is due to the use of sudo remotely (you'd be asked for the password but you don't have a tty to enter it). On the other hand, as a normal user you can't normally use simply dd as suggested in other answer (you don't have the required permissions to the device). You can solve the problem by giving yourself rights to execute dd as sudo without a password. You can do this by editing the sudoers file (on the remote!):

sudo visudo

add the following line:

userfoo ALL=(ALL) NOPASSWD: /bin/dd if=/dev/sdX

Now you can issue:

ssh userfoo@host "sudo /bin/dd if=/dev/sdX" | dd of=test.dd

and it should work. You could make a more generic entry in sudoers, allowing you to run dd with any parameter, but it is wiser to keep this free permissions to the minimum you need.

elfantin
  • 151
  • 1
  • 2
  • Or, you can just run 'sudo ls' at the applicable end (and type in password), just prior to running the 'sudo dd ...' command – MikeW Feb 19 '19 at 11:28
  • 1
    With newer versions of dd adding status=progress even allows monitoring of copy progress. – sensslen May 21 '19 at 09:16
  • This is the correct answer regarding the error message. But you could add these alternatives: use `ssh -t` to execute the command with a `tty` allowing for interactive password input / use `sudo -S` to read password from `stdin` even without a `tty`. – acran Nov 01 '20 at 14:34
  • 3
    @MikeW note that this might not work since by default `sudo` only remembers the authentication for the same console session, see `timeout_type` in `man 5 sudoers`. – acran Nov 01 '20 at 14:35
8

I've just used a modified version on a virtual Linux Mint box to clone a physical hard drive on an aging RedHat server.

I ran the following as root on the virtual box:

ssh [email protected] "dd if=/dev/cciss/c0d0" | dd of=/dev/sdb
  • 192.168.1.5 is the physical Red Hat Enterprise Linux 2.1 box.
  • /dev/sdb is a new virtual disk, which when finished cloning will be the basis of a virtual version of the old dying physical box.
slm
  • 363,520
  • 117
  • 767
  • 871
Fred Nerk
  • 81
  • 1
  • 1
7

Combining these answers allowed me to clone to another Linux host and avoid the 'permission denied' error:

  • RPI4 SD card (/dev/mmcblk0 - this clones the entire card)
  • avoid permission issue by prompting for elevated privilege (sudo -S)
  • see progress as it copies (status=progress)
  • compressing the copy (gzip)
  • specify buffer size (bs=64k) for improved speed. You can specify higher values. please read this
ssh [email protected] "sudo -S dd if=/dev/mmcblk0 bs=64k status=progress | gzip -1 -" | dd of=rpiimg.gz bs=64k
Hummus_Ful
  • 3
  • 3
Paul Sturm
  • 171
  • 1
  • 3
2

I was in a similar situation recently. The difference for me was, that

  • due to security measures root ssh access was disabled
  • sudo was not installed (deliberately)

So what I did was:

  1. examine device file permissions (grep for appropriate block device naming sheme (hd, sd, nvme, etc.))
user@machine:~$ ls -la /dev/ |grep sd
brw-rw----  1 root disk      8,   0 Nov 22 13:36 sda
brw-rw----  1 root disk      8,   1 Nov 22 13:36 sda1
brw-rw----  1 root disk      8,   2 Nov 22 13:36 sda2
brw-rw----  1 root disk      8,   5 Nov 22 13:36 sda5
  1. add the user to the disk group
root@machine:~$ usermod -aG user disk
  1. then run the dd the same way you already tried (but w/o sudo)
ssh [email protected] "dd if=/dev/sdX " |  dd of=/home/username/Documents/filename.image

(or also chain-in the gzip as others suggested)

helvete
  • 151
  • 4