zfs send | zfs receive - receiving and automounting ?

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.
 
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.
 
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.
 
  • Thanks
Reactions: sdf
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
 
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".
 
@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.
 
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.
 
Last edited by a moderator:
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.
 
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
 
Last edited by a moderator:
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.
 
  • Thanks
Reactions: Oko
Back
Top