■ Introducing FFS snapshots

I am positive not many know that NetBSD FFSv2 allows taking atomic
filesystem copies of a mounted filesystem (or part it) through fss(4),
the fileysytem snapshot device. These can be used to create backups or to
give fsck_ffs a consistent view of a previous version of the filesystem
to compare with (see `fsck -x`). Having a snapshot ready before editing critical configuration files under /etc or performing etcupdates, is
also a good idea.

Basically, what fss(4) does is providing a userspace API for accessing
file history, by creating a read-only version ('view') of a filesystem
at a given point of time. This view can be mounted with mount and used
in conjunction with utilities like dump, tar, rsync or more advanced
backup utilies to create and export system backups to a backup device.

For reference, I strongly recommend reading the relevant wiki entry: https://wiki.netbsd.org/tutorials/how_to_use_snapshots/

■ Create a full system snapshot

Time has come to configure our snapshot device.

$ fssconfig -cx fss0 / /var/snap

This will configure the fss0 virtual device at node /dev/fss0 to be an
atomic copy of the root fileysystem mounted at /, using a temporary log
of /var/snap, to which new writes will be added for as long as the
snapshot device is configured. This file will be automatically deleted
at device unconfiguration because of the optional -x switch

To mount he snapshot read-only at /mnt/snap:

$ mkdir /mnt/snap
$ mount -o ro /dev/fss0 /mnt/snap

A `df` output will easily reveal it is a mirror of the root filesystem:

Filesystem 1K-blocks Used Avail %Cap Mounted on
/dev/dk1 61271672 6790408 51417688 11% /
...
/dev/fss0 61271672 6722368 51485728 11% /mnt/snap

■ Use a ZFS dataset as target filesystem for backups

Remembering I had an external HDD formatted as a zpool and mounted at
/zfs, I will now create a dedicated dataset with a maximum reserved quota
of 500Gb, to store backups.

$ zfs create -o mountpoint=/zfs/snap zfs/snap
$ zfs set compression=gzip zfs/snap
$ zfs set copies=2 zfs/snap
$ zfs set quota=500G zfs/snap

■ Use the dump(8) utility to create a full system backup

The dump utility - and its restore(8) counterpart - are very useful when
it comes to backups on *nix, even though their long legacy, which traces
its roots back to AT&T UNIX 4, make their design look a little 'vintage' by modern standards. In particular, being dump very tape-drive oriented, it's advisable to always use the '-a' option in order to bypass all tape length considerations.

Other recommended dump options to use for backups:

- -0 : to perform a full system backup (not incremental)
- -u : update /etc/dumpdates to keep track of successful dumps
- -f : specify the file to use as target for the backup. Without it,
dump will default to /dev/rst0, but who owns a tape drive?

$ touch /zfs/snap/$(date +%Y_%m_%d).dump
$ dump -0ua -f /zfs/snap/$(date +%Y_%m_%d).dump /mnt/snap

DUMP: Found /dev/rfss0 on /mnt/snap in mount table
DUMP: Date of this level 0 dump: Wed Mar 16 14:56:30 2022
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/rfss0 (/mnt/snap) to /zfs/snap/2022_03_16.dump
DUMP: Label: none
DUMP: mapping (Pass I) [regular files]
DUMP: mapping (Pass II) [directories]
DUMP: estimated 7054721 tape blocks.
DUMP: Volume 1 started at: Wed Mar 16 14:57:19 2022
DUMP: dumping (Pass III) [directories]
DUMP: dumping (Pass IV) [regular files]
DUMP: 41.85% done, finished in 0:06
DUMP: 7063003 tape blocks on 1 volume
DUMP: Volume 1 completed at: Wed Mar 16 15:06:46 2022
DUMP: Volume 1 took 0:09:27
DUMP: Volume 1 transfer rate: 12456 KB/s
DUMP: Date of this level 0 dump: Wed Mar 16 14:56:30 2022
DUMP: Date this dump completed: Wed Mar 16 15:06:46 2022
DUMP: Average transfer rate: 12456 KB/s
DUMP: level 0 dump on Wed Mar 16 14:56:30 2022
DUMP: Closing /zfs/snap/2022_03_16.dump
DUMP: DUMP IS DONE

We can see the dump was recorded in /etc/dumpdates:

/dev/rfss0

0 Wed Mar 16 14:56:30 2022

By inspecting the dump file we can see it's a backup of the snapshot we
had previously created:

$ file /zfs/snap/$(date +%Y_%m_%d).dump
/zfs/snap/2022_03_16.dump: new-fs dump file (little endian), This dump Wed Mar 16 13:56:30 2022, Previous dump Thu Jan 1 00:00:00 1970, Volume 1, Level zero, type: tape header, Label none, Filesystem /mnt/snap, Device /dev/rfss0, Host rpi4, Flags 3

We can also see that the size of the backup is significantly reduced
compared to that of the used root filesystem, due to the inehrent
compression:

$ du -g /zfs/snap/$(date +%Y_%m_%d).dump
4.1G /zfs/snap/2022_03_16.dump

All the above commands can be put together in a script and executed periodically
by a cron job. In this way we can assure to always have a relatively recent backup to restore.

■ Addtional considerations

The restore(8) utility can be used to extract dump backups to a target directory (that in which restore is executed). For example:

( cd /altroot ; restore -rf /zfs/snap/2022_03_16.dump )

Will extract to /altroot a backup of the system as it was at the date
when this post was written.

An alternative to dump backups, is using something like rsync to do
incremental backups of a FFS snapshot to a target filesystem. For
example, supposing I wanted to mirror my newly created snapshot to the
snap ZFS dataset:

rsync -vaHx --delete /mnt/snap/ /zfs/snap

Hope this can turn useful to anybody looking for simple backup solutions
on NetBSD, using the tools available in base.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)