ZFS backup Q: send/recv and mountpoint property

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

ZFS backup Q: send/recv and mountpoint property

Dmitry Morozovsky
Colleagues,

still stuck in compiling stable procedure.

Prerequisites:

- some servers, all on ZFS, with layout such as
machine -> unique pool name, usually 2-letters, say, hm and im

- zfs layouts like

hm/R/${fs}, like
 hm/R
 hm/R/usr
 hm/R/usr/local
 hm/R/var
 hm/R/home
etc, where hm/R has property mountpoint=/ and others just inherit it


- on servers, zfs allows for non-root user to make snapshots, hold, etc, like

Local+Descendent permissions:
        group operator hold,send,snapshot

- zfs send -R [-i pool@prev-snap] pool@now-snap | \
    ssh backupserver 'zfs recv tgpool/B/zfs/srvname'

Problem:

0. on backup (zfs recv) server, I could not
- overwrite mountpoint property (and I'd better avoid it)
- add canmount=off, especially for child filesets, as it's not inherited (which
could be preferred behaviour)

1. after backup server reboot, if special manual tweaks did not have place,
filesets from backup images overwrite backup filesets, render it unuseable

Any hints?

Or did I missed something trivial?

Thanks, as usual, in advance!



--
Sincerely,
D.Marck                                     [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer:                                 [hidden email] ]
------------------------------------------------------------------------
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [hidden email] ***
------------------------------------------------------------------------
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ZFS backup Q: send/recv and mountpoint property

Jan Bramkamp-2
On 22.07.18 20:14, Dmitry Morozovsky wrote:

> Colleagues,
>
> still stuck in compiling stable procedure.
>
> Prerequisites:
>
> - some servers, all on ZFS, with layout such as
> machine -> unique pool name, usually 2-letters, say, hm and im
>
> - zfs layouts like
>
> hm/R/${fs}, like
>  hm/R
>  hm/R/usr
>  hm/R/usr/local
>  hm/R/var
>  hm/R/home
> etc, where hm/R has property mountpoint=/ and others just inherit it
>
>
> - on servers, zfs allows for non-root user to make snapshots, hold, etc, like
>
> Local+Descendent permissions:
>         group operator hold,send,snapshot
>
> - zfs send -R [-i pool@prev-snap] pool@now-snap | \
>     ssh backupserver 'zfs recv tgpool/B/zfs/srvname'
>
> Problem:
>
> 0. on backup (zfs recv) server, I could not
> - overwrite mountpoint property (and I'd better avoid it)
> - add canmount=off, especially for child filesets, as it's not inherited (which
> could be preferred behaviour)
>
> 1. after backup server reboot, if special manual tweaks did not have place,
> filesets from backup images overwrite backup filesets, render it unuseable
>
> Any hints?
>
> Or did I missed something trivial?

You missed the normal non-replication streams. Those contain only the
dataset and not its properties. You can use those to backup the dataset
and a wrapper script to deal with the dataset's properties. The zxfer
script does all that for you.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ZFS backup Q: send/recv and mountpoint property

Gary Palmer-2
In reply to this post by Dmitry Morozovsky
On Sun, Jul 22, 2018 at 09:14:05PM +0300, Dmitry Morozovsky wrote:

> Colleagues,
>
> still stuck in compiling stable procedure.
>
> Prerequisites:
>
> - some servers, all on ZFS, with layout such as
> machine -> unique pool name, usually 2-letters, say, hm and im
>
> - zfs layouts like
>
> hm/R/${fs}, like
>  hm/R
>  hm/R/usr
>  hm/R/usr/local
>  hm/R/var
>  hm/R/home
> etc, where hm/R has property mountpoint=/ and others just inherit it
>
>
> - on servers, zfs allows for non-root user to make snapshots, hold, etc, like
>
> Local+Descendent permissions:
>         group operator hold,send,snapshot
>
> - zfs send -R [-i pool@prev-snap] pool@now-snap | \
>     ssh backupserver 'zfs recv tgpool/B/zfs/srvname'
>
> Problem:
>
> 0. on backup (zfs recv) server, I could not
> - overwrite mountpoint property (and I'd better avoid it)
> - add canmount=off, especially for child filesets, as it's not inherited (which
> could be preferred behaviour)
>
> 1. after backup server reboot, if special manual tweaks did not have place,
> filesets from backup images overwrite backup filesets, render it unuseable
>
> Any hints?
>
> Or did I missed something trivial?
>
> Thanks, as usual, in advance!


Hi,

On my backup server I have two pools, zfsroot and data.  I think I set
things up, and then exported data so that it's not auto-imported at boot.
I then put this in /etc/rc.local

zpool import -N -R /backups data

It lets the pool import filesystems with paths like / or /home
without over-writing the paths on the local system.

Regards,

Gary
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ZFS backup Q: send/recv and mountpoint property

Dmitry Morozovsky
On Sat, 4 Aug 2018, Gary Palmer wrote:

> On my backup server I have two pools, zfsroot and data.  I think I set
> things up, and then exported data so that it's not auto-imported at boot.
> I then put this in /etc/rc.local
>
> zpool import -N -R /backups data
>
> It lets the pool import filesystems with paths like / or /home
> without over-writing the paths on the local system.

that would fit for "normal" case, but does not survive sudden reboot ;-)

I'm switching to zxfer for now; not ideal, but fair and usable enough

--
Sincerely,
D.Marck                                     [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer:                                 [hidden email] ]
------------------------------------------------------------------------
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [hidden email] ***
------------------------------------------------------------------------
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ZFS backup Q: send/recv and mountpoint property

Gary Palmer-2
On Fri, Aug 10, 2018 at 05:42:46PM +0300, Dmitry Morozovsky wrote:

> On Sat, 4 Aug 2018, Gary Palmer wrote:
>
> > On my backup server I have two pools, zfsroot and data.  I think I set
> > things up, and then exported data so that it's not auto-imported at boot.
> > I then put this in /etc/rc.local
> >
> > zpool import -N -R /backups data
> >
> > It lets the pool import filesystems with paths like / or /home
> > without over-writing the paths on the local system.
>
> that would fit for "normal" case, but does not survive sudden reboot ;-)
>
> I'm switching to zxfer for now; not ideal, but fair and usable enough

Hi,

I haven't tested reboot during sync, but I'm not sure why a sudden
reboot would cause issues - the -R should move mounts outside
critical areas.  Could you elaborate please?

Thanks,

Gary

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ZFS backup Q: send/recv and mountpoint property

Dmitry Morozovsky
On Fri, 10 Aug 2018, Gary Palmer wrote:

> > > On my backup server I have two pools, zfsroot and data.  I think I set
> > > things up, and then exported data so that it's not auto-imported at boot.
> > > I then put this in /etc/rc.local
> > >
> > > zpool import -N -R /backups data
> > >
> > > It lets the pool import filesystems with paths like / or /home
> > > without over-writing the paths on the local system.
> >
> > that would fit for "normal" case, but does not survive sudden reboot ;-)
> >
> > I'm switching to zxfer for now; not ideal, but fair and usable enough
>
> Hi,
>
> I haven't tested reboot during sync, but I'm not sure why a sudden
> reboot would cause issues - the -R should move mounts outside
> critical areas.  Could you elaborate please?

yes, that would be exactly the case I'm referring: reboot when your data pool
is *not* exported

--
Sincerely,
D.Marck                                     [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer:                                 [hidden email] ]
------------------------------------------------------------------------
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [hidden email] ***
------------------------------------------------------------------------
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ZFS backup Q: send/recv and mountpoint property

Gary Palmer-2
On Fri, Aug 10, 2018 at 05:52:03PM +0300, Dmitry Morozovsky wrote:

> On Fri, 10 Aug 2018, Gary Palmer wrote:
>
> > > > On my backup server I have two pools, zfsroot and data.  I think I set
> > > > things up, and then exported data so that it's not auto-imported at boot.
> > > > I then put this in /etc/rc.local
> > > >
> > > > zpool import -N -R /backups data
> > > >
> > > > It lets the pool import filesystems with paths like / or /home
> > > > without over-writing the paths on the local system.
> > >
> > > that would fit for "normal" case, but does not survive sudden reboot ;-)
> > >
> > > I'm switching to zxfer for now; not ideal, but fair and usable enough
> >
> > Hi,
> >
> > I haven't tested reboot during sync, but I'm not sure why a sudden
> > reboot would cause issues - the -R should move mounts outside
> > critical areas.  Could you elaborate please?
>
> yes, that would be exactly the case I'm referring: reboot when your data pool
> is *not* exported

Hi Dmitry,

I don't think that's a problem.  I don't export the pool before rebooting,
I just shut down the box and boot it the next time I need to do a backup
The -R flag prevents the pool from being written to the cache file which
should stop import on boot.  Note that I'm running FreebSD 10.4-p<whatever>
currently.  Need to upgrade to 11.2 and see if that still works.

Regards,

Gary
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ZFS backup Q: send/recv and mountpoint property

Gary Palmer-2
On Fri, Aug 10, 2018 at 03:55:21PM +0100, Gary Palmer wrote:

> On Fri, Aug 10, 2018 at 05:52:03PM +0300, Dmitry Morozovsky wrote:
> > On Fri, 10 Aug 2018, Gary Palmer wrote:
> >
> > > > > On my backup server I have two pools, zfsroot and data.  I think I set
> > > > > things up, and then exported data so that it's not auto-imported at boot.
> > > > > I then put this in /etc/rc.local
> > > > >
> > > > > zpool import -N -R /backups data
> > > > >
> > > > > It lets the pool import filesystems with paths like / or /home
> > > > > without over-writing the paths on the local system.
> > > >
> > > > that would fit for "normal" case, but does not survive sudden reboot ;-)
> > > >
> > > > I'm switching to zxfer for now; not ideal, but fair and usable enough
> > >
> > > Hi,
> > >
> > > I haven't tested reboot during sync, but I'm not sure why a sudden
> > > reboot would cause issues - the -R should move mounts outside
> > > critical areas.  Could you elaborate please?
> >
> > yes, that would be exactly the case I'm referring: reboot when your data pool
> > is *not* exported
>
> Hi Dmitry,
>
> I don't think that's a problem.  I don't export the pool before rebooting,
> I just shut down the box and boot it the next time I need to do a backup
> The -R flag prevents the pool from being written to the cache file which
> should stop import on boot.  Note that I'm running FreebSD 10.4-p<whatever>
> currently.  Need to upgrade to 11.2 and see if that still works.

Just upgraded to 11.2 and no obvious issues so far with the above scheme

Regards,

Gary
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ZFS backup Q: send/recv and mountpoint property

Borja Marcos-2
In reply to this post by Dmitry Morozovsky


> On 22 Jul 2018, at 20:14, Dmitry Morozovsky <[hidden email]> wrote:
>
>
> Problem:
>
> 0. on backup (zfs recv) server, I could not
> - overwrite mountpoint property (and I'd better avoid it)
> - add canmount=off, especially for child filesets, as it's not inherited (which
> could be preferred behaviour)
>
> 1. after backup server reboot, if special manual tweaks did not have place,
> filesets from backup images overwrite backup filesets, render it unuseable
>
> Any hints?
>
> Or did I missed something trivial?

Sorry about being late to the party.

What I do is to receive the dataset using the -u option and after the receive I set the
canmount option to off. It would be great if zfs recv could set options atomically
when receiving a dataset, though.

If you are doing incremental replications it’s always wise to use canmount=off
and zfs recv -u. If you need to access files in the replicated dataset, then clone
a snapshot instead of mounting the dataset ifself.

Otherwise, unless you have atime=off any read access will change the last access
timestamps, which means that incremental snapshots won’t apply unless you force
a rollback with a -N. Using -N is itself a bad idea because, in case of error, you might
end up rolling back something you don’t want. If you avoid the rollback you will
avoid making the recv destructive in any way.

Actually, when replicating datasets I always add a hold to the last replicated snaphsot
so that I won’t delete them by mistake.

I do something like this.

- new snapshot (source@new)

- hold  source@new

- Send incremental from @last @new | recv -u

- hold destination@new

- set canmount=off for destination@new

- hold destination@new (would be nice to be able to add a hold atomically as well)

- release source@last, destination@last



It would be awesome to have something like “zfs recv -h HOLD_NAME -o OPTION=xxxx”





Borja.


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ZFS backup Q: send/recv and mountpoint property

Borja Marcos-2


> On 13 Aug 2018, at 11:47, Borja Marcos <[hidden email]> wrote:
> Otherwise, unless you have atime=off any read access will change the last access
> timestamps, which means that incremental snapshots won’t apply unless you force
> a rollback with a -N. Using -N is itself a bad idea because, in case of error, you might
> end up rolling back something you don’t want. If you avoid the rollback you will
> avoid making the recv destructive in any way.

I mean -F of course, not -N. Thanks to the attentive readers who poked me! :P





Borja.


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"