zfs q regarding backup strategy

[David Christensen]

On 10/1/21 14:28, Steve O'Hara-Smith wrote:
> On Fri, 1 Oct 2021 15:14:08 +0100
> tech-lists <tech-lists at zyxst.net> wrote:
> 
>> What I'm looking for is something (ideally) written in sh. Or even perl.
>> But even before that, need to understand incremental backups properly.
>> Basically the backup needs to be (effectively) write-only. By that, I
>> mean only added to.
> 
> 	With zfs send every stream is a send up to some 'target' snapshot,
> a full stream is the complete history while an incremental stream is from
> an earlier 'source' snapshot.
> 
> 	It is therefore necessary for any successful incremental backup
> system to know what the last snapshot sent was so that the next cycle can
> start by creating a new snapshot and sending the increment from the last
> sent to the latest. On the receiving end the options are to either store
> each send as a file named in such a way as to make it obvious what order to
> process them in should restore be needed or (more usefully) to use zfs recv
> to load them into filesystems in a pool on the receiving machine. 


The one time I tried booting a system with two OS drives, two boot 
pools, and two root pools convinced me to never to try that again.


My backup plan for OS instances is to take an image of the device with 
dd(1).  For this reason, I keep my OS instances small enough to fit on 
"16 GB" devices and use one device per OS instance.


> If you do
> this there will be no pruning of the received snapshots unless you set
> something up to do it.


+1


> 	This sounds nice and simple and is the basis of most homebrew and
> packaged zfs replication systems - proper error handling is *difficult*
> especially handling errors in the zfs recv phase. 


+1


> Also there is the
> irritating detail that one of the properties of a ZFS filesystem is its
> mount point and while you can run zfs recv in such a way as not to mount
> the received filesystems they will get mounted on reboot which makes
> backing up several root filesystems to an archive server a little tricky!


Are you referring to the zpool(8) property 'altroot'?

      altroot
          Alternate root directory. If set, this directory is prepended 
to any
          mount points within the pool. This can be used when examining an
          unknown pool where the mount points cannot be trusted, or in an
          alternate boot environment, where the typical paths are not valid.
          altroot is not a persistent property. It is valid only while the
          system is up.  Setting altroot defaults to using cachefile=none,
          though this may be overridden using an explicit setting.


I recall that FreeNAS uses altroot, and it is persistent across reboots. 
  I wonder how they accomplished that?  Import scripts on boot and 
export scripts on shutdown?  But, how to deal with an unclean shutdown 
and/or failed export?  STFW I do not see any clues.


> 	The bad news is that I haven't found a solution I really like,
> zrepl comes close but it solves that last problem by dropping *all* the zfs
> properties in the archive and I'm pretty sure it ignores some error
> conditions that eventually lead to an incomplete backup. 


Not good.


> What I really want
> is a rok solid reliable archive server with all the hierarchies archived
> mounted read only under something like /archive/<source>/. 


That would be nice.


> I haven't got it yet.


Perhaps a top-level "archive" pool, one ZFS volume per <source>, one 
pool per volume, and some work-around to achieve persistent altroot's (?).


David