■ 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_ffs -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 filesystem mounted at /, using a temporary
log of /var/snap, to which new writes will be added for as long the
snapshot device is configured. 
In this case, the snap log will be automatically unlinked after device
configuration 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 of the very unreliable 64Gb SD where this
system is running on.  

$ 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.