Restoring and snapshots
dpchrist at holgerdanske.com
Sat Apr 11 22:18:51 UTC 2020
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
> For example, after restore,
> I have:
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:
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
> 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.
More information about the freebsd-questions