3

I have a volume with client data that is encrypted using ZFS native encryption. I was trying to send this from a Ubuntu server to a Debian server. It is not possible to receive zfs send data into encrypted volumes, so the target volume is a new one.

But now the transfer failed after a small outage, and the new container doesn't show up.

Is the received data still somewhere? Can I continue this transfer somehow?

Source

zfs snapshot pool/bigdata@bup
zfs send pool/bigdata@bup | pv | nc -l -p 5555

Target

nc -w 10 1.2.3.4 5555 | zfs receive pool/bup201710

(Where 1.2.3.4 is the source IP address.)

Note: ZoL ZFS native encryption is not available in the ZFS versions (0.6.x) that ship with Debian and Ubuntu. This feature was implemented ZoL in 2016, and only available through manual compilation. It's not in any tagged release but available from master on their github page. It is expected to be included in the tagged release of 0.8. Seen how both Ubuntu and Debian are a long way behind the very active development, many people compile ZFS themselves.

3

I don't know if it is possible with included encryption (I assume it would be), but normally you can resume failed sends with special flags send -t | recv -s, if your pool supports it (the documentation is from illumos, I assume it is the same with ZoL):

zfs send [-Penv] -t receive_resume_token
       Creates a send stream which resumes an interrupted receive.  The
       receive_resume_token is the value of this property on the filesystem or
       volume that was being received into.  See the documentation for zfs
       receive -s for more details.

zfs receive [-Fnsuv] [-o origin=snapshot] filesystem|volume|snapshot
zfs receive [-Fnsuv] [-d|-e] [-o origin=snapshot] filesystem

   -s  If the receive is interrupted, save the partially received state,
       rather than deleting it.  Interruption may be due to premature
       termination of the stream (e.g. due to network failure or failure
       of the remote system if the stream is being read over a network
       connection), a checksum error in the stream, termination of the zfs
       receive process, or unclean shutdown of the system.

       The receive can be resumed with a stream generated by zfs send -t
       token, where the token is the value of the receive_resume_token
       property of the filesystem or volume which is received into.

       To use this flag, the storage pool must have the extensible_dataset
       feature enabled.  See zpool-features(5) for details on ZFS feature
       flags.

zfs receive -A filesystem|volume
       Abort an interrupted zfs receive -s, deleting its saved partially
       received state.

I would first try it locally (pipe, no netcat or pv) with a small system and just Ctrl-C the transfer to see if it works in principle.

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.