Restoring and snapshots

[David Christensen]

On 2020-04-11 01:31, Andrea Venturoli wrote:
> On 2020-04-11 01:53, David Christensen wrote:

> let's suppose I'm restoring data from 
> a ZFS system on a non ZFS filesystem.
> I just have plain files and I have to deal with that.

I am confused:

*  What is the type of the filesystem that was the source of the backup?

*  What tool(s) did you use to backup?

*  What is the type of the filesystem that was the destination of the 
backup?  Is the the source of the restore?

*  What tool(s) are you using to restore?

*  What is the type of the filesystem that is the destination of the 
restore?


> For example, after restore, 

> I have:
> 
> .../usr/jails/.zfs/snapshot/snapname/dc/
> and
> .../usr/jails/dc/.zfs/snapshot/snapname/

So, the backup source filesystem and the restore destination filesystems 
are both ZFS (?).


What you have show above is the default Unix filesystem representations 
of snapshots for two ZFS filesystems:

     pool/.../jails

     pool/.../jails/dc


The upper Unix filesystem path should be an empty directory.


The lower Unix filesystem path should contain the contents of the 
pool/.../jails/dc ZFS filesystem (.../usr/jails/dc Unix filesystem) when 
the snapshot was taken.


> (This is a result of ezjail use of nullfs).

I believe it is a result of the 'mountpoint' properties of the two ZFS 
file systems and how ZFS represents filesystem snapshots in the Unix 
file system.


> So (in my script) I cannot simply "mv" directories around, but sometimes 
> I need to "merge" them.

AIUI the Unix filesystem namespace, the ZFS filesystem namespace, and 
the ZFS snapshot namespace are related by:

*  ZFS properties -- 'canmount', 'mounted', 'mountpoint', and 'snapdir'.

*  ZFS design -- notably Unix filesystem representation of ZFS 
snapshots: '.zfs/snapshot/filesystem at snapname'.

*  Filesystem and ZFS operations over time.


Navigating these namespaces by hand is tricky.  Writing scripts to 
navigate them is non-trivial.


> The real problem, when writing my script, is that I end up looping over 
> results of `ls ...` or `find ...`. I read that is considered bad 
> practice, so I asked if, maybe, there was a better way.
> Up to now, it seems not...

I believe looping over the results of a command in a Bourne shell script 
is a common programming technique.  But, I would probably invoke the 
command and store the results into a variable on one line and start a 
loop over the variable contents on another line, so that I could insert 
a debug echo between the two lines and see the contents of the variable.


> I'm wondering if I should abandon sh and use something else (Python?).

When I migrated from Linux and ext4 to FreeBSD and ZFS, I wanted to 
incorporate zfs-auto-snapshot and replication in my disaster recovery 
plans.  This required me to rethink my workflows and revise or rewrite 
the associated Bourne and Perl scripts.  For simple stuff, I found that 
I could write and deploy Bourne scripts more easily and quickly than 
Perl scripts.  For non-simple stuff, sometimes I wrote a Bourne script 
that called a Perl script for crux moves and sometimes I wrote the whole 
script in Perl.  The key differentiators for choosing Perl over Bourne 
included command-line option and argument processing, data structures/ 
algorithms, and automated testing.


David