zfs send | zfs receive - receiving and automounting ?

da1 · Nov 29, 2011

Hi again

,

For the sake of learning I set up 2 VBox FreeBSD 8.2 with ZFSonRooT (hostname "primary" and "backup"). The idea is to simulate a full hardware failure and recovery using ZFS. Machine "primary" has 1 pool called "zroot" (OS) and machine "backup has "zroot" (OS) and "primary". The idea is to send all data to the "primary" pool on machine "backup" from machine "primary".

After the machines are up, I populate the "primary" machine with some data, create a snapshot with

Code:

zfs snapshot -r zroot@1

and send it to the "backup" machine ("primary" pool) via

Code:

 zfs send -R zroot@1 | ssh root@backup.local zfs receive -dF primary

.

The problem is that after transferring the snapshot, the datasets get mounted automatically and because the snapshot is of the "zroot" pool from machine "primary" it overwrites the "zroot" pool from machine "backup".

I guess I'm missing something and I need a hand in finding out what.

bbzz · Nov 29, 2011

Hello,

The way I do it (if I do all snapshots with -R) is
# zfs send -R zpool@snap | ssh host@remote zfs receive -dvu somepool

In other words, -d will create needed fs, and -u means fs is not mounted. -F would overwrite data.

Also I don't like having root account enabled for ssh so I delegate permissions on zfs pools for sending and receiving. Like so:

# zfs allow -g wheel send zroot
That allows sending snapshots

# zfs allow -g wheel create,mount,receive storage/backups
That allows receiving snapshots

Wheel group still can't remove fs with this.

da1 · Nov 30, 2011

The -u option does the job, but only half way through. When I send/receive with the -u option, everything is fine, the snapshot gets copied over and does not get mounted.
However, upon reboot, the snapshot datasets do get mounted .....

A workaround would be to set all datasets to mountpoint=legacy but I think this would be overkill since I would need to do it for every snapshot sent.

kpa · Nov 30, 2011

The destination of the zfs send/receive does not have to be the root of the destination pool, it can be a dataset somewhere futher down the hierarchy, for example
# ... | ssh [email]root@backup.local[/email] zfs receive -dF primary/some/dataset

bbzz · Nov 30, 2011

I use fstab to specify what is getting mounted, even with zfs. I don't use /etc/rc.conf.
My other guess would be to specify mountpoint as "none".

da1 · Nov 30, 2011

@kpa: I tried it already and I get the same behavior.
@bbzz: AFAIK, datasets mountpoints are properties of the datasets and one cannot specify datasets in /etc/fstab.

Regardless, the "backup" pool gets imported at boot time and I think it has nothing to do with the datasets auto mounting. I think "the problem" is that the datasets have a valid mountpoint (ex: not "legacy") and due to that, they get mounted (which is normal, but not for what I need). As I have said before, a workaround is possible but there should be a better and cleaner way of doing it.

tfba · Feb 7, 2016

I realise this is an old thread I'm resurrecting, but I just wondered if anyone had an easy workaround for the mounting problem? I'm sending zroot to a remote machine and receiving in it a zfs filesystem /backups/<machinename> but hit the same mounting issue described in the original post.

My workaround was to try sending each filesystem individually (i.e. without send -R). However, when sending the root, most directories from /usr get sent even though /usr is also a filesystem. If I then try and send /usr, I loose /usr/bin etc on the remote backup machine.

How can /usr/bin and /usr/lib etc be part of the root file system in zfs, not part of the /usr filesystem? /usr has to be a filesystem because it contains /usr/home and /usr/ports etc so sending /usr should send /usr/bin, /usr/lib etc but doesn't.

junovitch@ · Feb 17, 2016

Note the configuration of the canmount property.
% zfs get canmount zroot/usr

Code:

NAME  PROPERTY  VALUE  SOURCE
zroot/usr  canmount  off  received

% zfs get canmount zroot/usr/home

Code:

NAME  PROPERTY  VALUE  SOURCE
zroot/usr/home  canmount  on  default

The filesystem is laid out so a snapshot of zroot/ROOT/default or whatever the current boot environment name is in use will snapshot the system in a coherent state. That means directories like /usr/bin fall through the canmount=off configuration and are included in the boot environment.

manas · Jul 28, 2016

junovitch@ said:
Note the configuration of the canmount property.
% zfs get canmount zroot/usr

Code:

NAME PROPERTY VALUE SOURCE zroot/usr canmount off received

% zfs get canmount zroot/usr/home

Code:

NAME PROPERTY VALUE SOURCE zroot/usr/home canmount on default

The filesystem is laid out so a snapshot of zroot/ROOT/default or whatever the current boot environment name is in use will snapshot the system in a coherent state. That means directories like /usr/bin fall through the canmount=off configuration and are included in the boot environment.

I made a bug report about this very issue last month. I had suggested to Allan Jude that this should be added to the handbook at BSDCan 2016. I've been hit by this issue many times, thank you junovitch@ for the solution.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210222

junovitch@ · Aug 6, 2016

manas said:
I made a bug report about this very issue last month. I had suggested to Allan Jude that this should be added to the handbook at BSDCan 2016. I've been hit by this issue many times, thank you junovitch@ for the solution.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210222

Thanks. And if you have a suggestion for clearer Handbook text that suggestion is a good starting point. You can get some assistance from the committer involved be it allanjude@ or another committer to get it into a commit ready shape.