On Fri, Feb 2, 2024 at 6:39 PM Grant Edwards <grant.b.edwa...@gmail.com> wrote: > > On 2024-01-31, Rich Freeman <ri...@gentoo.org> wrote: > > > In any case, these COW filesystems, much like git, store data in a > > way that makes it very efficient to diff two snapshots and back up > > only the data that has changed. [...] > > In order to take advantage of this, I assume that the backup > destination and source both have to be ZFS?
So, the data needs to be RESTORED to ZFS for this to work. However, the zfs send command serializes the data and so you can just store it in files. Those files can only be read back into zfs. It is probably a bit more typical to just pipe the send command into zfs receive (often over ssh) so that you're just directly mirroring the filesystem, and not storing the intermediate data. > Do backup source and > destination need to be in the same filesystem? Or volume? Or Pool? No on all of these, but they can be. > If you'll forgive the analogy, we'll say the the functionality of > rsync (as used by rsnapshot) is built-in to ZFS. Is there an > application that does with ZFS snapshots what the rsnapshot > application itself does with rsync? There are a few wrappers around zfs send. I'm using sys-fs/zfs-auto-snapshot and what looks like a much older version of: https://github.com/psy0rz/zfs_autobackup > > I googled for ZFS backup applications, but didn't find anything that > seemed to be widespread and "supported" the way that rsnapshot is. They're less popular since many just DIY them, but honestly I think the wrapper is a nicer solution. It will rotate backups, make sure that snapshots aren't needed before deleting them, and so on. In order to do an incremental backup the source/destination systems need to have matching snapshots to base them on, so that is important if backups are sporadic. If you're just saving all the send streams then knowing which ones are obsolete is also important, unless you want to have points in time. -- Rich
