zfs send | gzip - Potentially unsafe command?

[dgrab]

I was having problems figuring out how to transfer my dataset from one zpool to another, and was told to look at zfs send for possible solutions.

When reading the Oracle-Solaris ZFS documentation, I noticed one method of using it is compressing it to a zip file, with this command used as an example:

Sending and Receiving ZFS Data - Oracle Solaris ZFS Administration Guide

This book is intended for anyone responsible for setting up and administering ZFS file systems. Topics are described for both SPARC and x86 based systems, where appropriate.

docs.oracle.com

Code:

# zfs send pool/fs@snap | gzip > backupfile.gz

Sure enough, because I'm a beginner, I ctrl-C copied this command, except with my pool and snape name changed. Upon executing, it started zipping up, which ended up creating a big problem. I didn't realize it wasn't creating this gzip file on my pool, but rather, on my boot drive (which happened to be a small vdisk). It filled up to max capacity very quickly and all of a sudden my TrueNAS VM stopped working. Restarting it only resulted in the same problems of not being responsive.

Being a dumb beginner, I of course looked for solutions, and after reading some forum answers, experimented with utilities I didn't fully understand. I tried using qemu-img in my hypervisor to extend the size of the vdisk, but neglected to realize that wouldn't do anything without partitioning inside the VM, and potentially cause further problems (which it did). I eventually messed up my installation vdisk altogether without having the chance to export my zpool, so I'm guessing I lost all the data.

Thankfully it wasn't production data and I didn't lose anything important that I didn't already have stored elsewhere. That being said, I find it quite annoying how the oracle-solaris documentation plainly suggests creating a zip file without specifying where it will be. Yeah maybe I should've become more familiar with the TrueNAS directory tree first, but even then, annoying!

 

[Ericloewe]

Sidenote: Since Oracle's fork of ZFS is a substantially different thing from OpenZFS, using their documentation is generally a bad idea.

Beyond that, you do need a working understanding of how to work with a Unix system if you want to do stuff through the command line - that's part of the reason there's a warning in the Message Of The Day banner when you log in.

I was having problems figuring out how to transfer my dataset from one zpool to another, and was told to look at zfs send for possible solutions.

You can either setup a replication task via the GUI or manually do things by piping zfs send into zfs recv without the useless intermediate file.

That being said, I find it quite annoying how the oracle-solaris documentation plainly suggests creating a zip file without specifying where it will be.

It's pretty universal behavior across Unix-like systems and even Windows that filenames are treated as relative to the current directory unless explicitly provided as absolute paths. I honestly can't fault Oracle's example.

 

[Arwen]

I agree with @Ericloewe, if the intent is to copy a dataset from one pool to another pool on the same server, a ZFS Send & Receive pipeline is much preferred. But, getting the syntax right can be tricky.

Even with trying to copy the dataset from one server to a different server, you can still use ZFS Send & Receive, just use SSH as the transport program.