Restoring and snapshots

[David Christensen]

On 2020-04-11 15:18, David Christensen wrote:
> 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?

Correction: Is this 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'.

Correction: '.zfs/snapshot/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


David