Real world compare against zfs snapshot
Zfs snapshots are a great mechanism for
- creating recovery points
- making replicas
- making backups
with some issues
- restoring on anything not-zfs based
- consolidation and pruning
- external (USB)
Let's examine the differences of zpaqfranz, or rather how it can be used in integration.
It is a functionality that can be emulated via much more complex software, like hb (hashbackup) for example, mounting a "fake" filesystem to read the data
zpaqfranz cannot do this kind of "fake" filesystem, but it is possible to use a GUI (for example... my own PAKKA for Windows or Bandizip) to restore everything @ a specific version
zpaqfranz can make replicas (a-la robocopy or rsync) via the command r (... robocopy!) with one master folder and multiple slave dirs, forcing .XLS copy, with optional verify, even "hard" (by hash)
Of course zfs replica are much faster, but can occur ONLY on a zfs target: instead zpaqfranz r (robocopy, rsync etc) works with Linux-NAS destination
zfs can be used to make a zfs send-into-a-file, differential and incremental, but there is a big issue.
**but restoring is a nightmare **
in fact restoring a big zfs backup can require hours and hours and terabytes of free disk space, because first you zfs "receive" the main backup, then apply one or more diff/inc backups, then you can restore say the single /etc/rc.conf you want
With zpaqfranz you can extract a entire version (snapshot), some files, or just one.
And, if you are lazy just like me, with a GUI
In my experience, snapshot restore is far more complex than with zpaqfranz
It is not easy at all to restore a complex multi-layered zfs snapshots backups on a different system (example a FreeBSD backup on Windows).
In the event of an emergency it is practically certain to have a Windows machine (even a notebook) rather than a server with very large free disk space (for restoring snapshots), with the same version of zfs and, ideally, also the same version of operating system (interoperability is not always trivial)
This is not a problem for zpaqfranz: you can restore the data of a UNIX system on a Windows machine without any particular problems.
There are also specific functions and switches (e.g. -utf, fix255) that extract data even if the target filesystem (let's say NTFS) has greater limitations than the starting one (let's say zfs)
After some times, using for example zfsSnap or whatever, you will get hundreds/thousands of snapshot, each one take space and takes time (slowing the system, much more with spinning drives), and they are very delicate, in the sense that it happens to have to delete them all for reasons of space, speed, and complexity
With zpaqfranz you get a single file (when not using multipart archive) with a thousand of version that does not slow down you fileserver.
Every now and than (example: 1 or 2 years) you will rename the archive (say mybackup.zpaq to mybackup_2021.zpaq) and you do not need to do anything.
On the next round your script will start a brand new mybackup.zpaq, and you can put offline the mybackup_2021.zpaq (for consultation).
There is a specific switch (-timestamp) to consolidate zfs snapshot into a zpaqfranz archive. Just before deleting the snapshots, put the data into the backup, timestamping with (for example) a zfsSnap naming. You will keep the snapshot data forever
A typical disaster-recovery plan will require the use of USB devices, like hard disks or USB sticks. It's not something zfs particularly loves, almost always without encryption, and most importantly something you can read easily from other systems
The best choice is "something" that can be restored easily from "whatever, with the easiest possible encryption system. An encrypted USB-based zpaqfranz archive is used identically to archives without encryption (just adding -key). The importance of encryption on mobile devices, which can be stolen or lost, is fundamental