Send ZFS snapshot to remote machine

9,090

Solution 1

sudo zfs send tank/dana@snap1 | ssh sys2Root zfs recv newtank/dana

where sys2root is an entry in ~/.ssh/config, ie:

host sys2Root
  HostName 192.168.0.x
  User root

Solution 2

Given that's normally considered a bad idea to allow root login via ssh, the alternative is to have the destination user, say foo, be sudoer on destination host, name it remote. Also, passwordless login is a plus.

Then, the following command will suffice

$ sudo zfs send <dataset1> | ssh foo@remote "sudo zfs recv <dataset2>"
Share:
9,090

Related videos on Youtube

Leon Straathof
Author by

Leon Straathof

Updated on September 18, 2022

Comments

  • Leon Straathof
    Leon Straathof over 1 year

    Edit:

    This question originally focused on the issue of reversing the direction of the ssh connection on the transfer, but I came to realize that wasn't what was causing the problems I run into, so I simplified it.


    Though Ubuntu documentation of zfs only discusses send-receive via file, that approach is unfeasible with large data-sets. Oracle documentation recommends using ssh in pipe, i.e.,

    # zfs send tank/dana@snap1 | ssh sys2 zfs recv newtank/dana
    

    However, attempting this procedure with a test data-set I've created, containing a single 10M file, I run into the problem of Ubuntu Xenial's implementation of zfs (ZFS-on-Linux) requiring root privileges (on the receiving side):

    $ sudo -i
    # zfs send tank/dana@snap1 | ssh sys2 zfs recv newtank/dana
    Permission denied the ZFS utilities must be run as root.
    warning: cannot send 'tank/dana@snap1': Broken pipe
    

    I tried to fix this issue by passing ssh the -t flag, i.e. issuing

    # zfs send tank/dana@snap1 | ssh -t sys2 "sudo zfs recv newtank/dana"
    

    which fails with

    Pseudo-terminal will not be allocated because stdin is not a terminal.
    

    before asking for sys2's credentials, after which the following messages are received:

    sudo: no tty present and no askpass program specified
    warning: cannot send 'tank/dana@snap1': Broken pipe
    

    Attempting to perform a test transfer using the other direction, using

    # ssh -t sys2 "sudo zfs send newtank/dana2@snap1" | zfs recv tank/dana2
    

    simply hangs after asking for sys2's credentials. (Recall, each snapshot only contains a 10M file, so I believe it doesn't actually try to do anything, but I'm not sure why it hangs.)

    • davidbaumann
      davidbaumann about 8 years
      What about if you run ssh over an ssh tunnel? ;) unix.stackexchange.com/questions/133863/…
    • Leon Straathof
      Leon Straathof about 8 years
      @davidbaumann, no, it still doesn't work (see edit). Perhaps the issue here is the elevation to root over ssh?
  • Leon Straathof
    Leon Straathof about 8 years
    Isn't it a really bad idea to allow ssh root login on my server?
  • Derrick
    Derrick about 8 years
    Yes, if your server is on a public IP, but theoretically less of an issue if you are on a secure private network. Unfortunately ZoL does not fully support ZFS delegations yet and this is the only reliable workaround I have found.
  • Leon Straathof
    Leon Straathof about 8 years
    Derrick, I can confirm that everything works as expected when allowing ssh root login. I agree that it should be much less of a concern when one of the servers in question is protected behind a private network, so that one could create a reverse ssh tunnel from it to the public server, then initiate the transfer from the public server's side. (However, given the current scope of the question, I'm reluctant to accept this answer as a solution to the general case.)
  • Leon Straathof
    Leon Straathof almost 8 years
    Finding this SU answer, this seems to be a given state, at least until ZFS-on-Linux supports using zfs allow a la the other answer on that question. As such, I'll accept the answer with the comment that restricting root login to a forced command--as described in that answer--could further enhance security.