aus der reihe "time flies ", der erste host hat endlich den ersten testrun mit #syncoid auf den neuen storage host durch (bzw andersrum. der storage host holt das snapshot gerödel da ab.)

Off the back of setting up a new VM last week (https://hachyderm.io/@forquare/116539562128910028) I know have Headscale [1] running with Headscale-admin [2].

Most of my machines now connected to the new VPN setup, I think I'll wait the weekend out to move do the final move from ZeroTier - I'm camping this weekend and will be less able to fix anything that goes wrong.

I love how easy lots of things are.
#Sanoid installed, configured, and run.
#Syncoid currently sending snapshots to https://zfs.rent/
Not to mention just how simple FreeBSD is to run.

[1] https://headscale.net
[2] https://github.com/GoodiesHQ/headscale-admin

@ironicbadger, borgbackup backup of all my servers in my home and on the Internet to rsync.net which is then rsync’ed down to my main home server running #ZFS. All Linux computers run ZFS, make backups using #sanoid and send to that server using #syncoid. I’m planning to set up a personal remote backup at my in-laws’ place which provides a ZFS send target over #Tailscale

@lakeswimmer I use #rsnapshot. Been using it for years and it works great. I'm also one of the project maintainers so am biased.

In a brand new installation where everything used #ZFS (and really, everything *should* use ZFS - if it's not properly supported in your OS the OS is faulty and you should use a different one) then these days I'd use zfs send/recv, wrapped in #sanoid / #syncoid - https://github.com/jimsalterjrs/sanoid

@shur3d, if you are able to use #ZFS on the machines to be backed up too, you can use its snapshot replication for this. While there are many tools for this, I’ve been using #sanoid + #syncoid for this and it works very well.

My command for syncing #ZFS snapshots (i.e. backing up servers) is getting more complicated by the day. Now we're at:

/usr/local/bin/retry -t 3 -- /bin/timeout -k 30s 20m /usr/local/bin/syncoid --pv-options="-q" --no-privilege-elevation --no-sync-snap -r $SERVER:zroot zpool/data/backup/$SERVER 2>&1

#syncoid

@jamesoff lots of people like #syncoid

@ruari apparently so... I've heard Allan Jude talk about it at least!

And if you think zfs send/recv is good - take a look at Jim Salter's #Sanoid / #Syncoid which orchestrates the process - absolute gold!

Today I had cause to revisit my home lab setup, and that in turn caused me to take a new look at my backup configuration and validate that everything is still in order.

If anyone is curious about setting up 3-2-1 style backups with #ZFS #snapshots using #Sanoid and #Syncoid, perhaps my writeup may be of some service.

https://oxcrag.net/blog/2025/11/16/zfs-backup-strategy-with-sanoid-and-syncoid.html

ZFS Backup Strategy with Sanoid and Syncoid

In my previous post, I discussed how I’ve migrated VMs to new storage. This gave me cause to also take a look at my backup configuration, to ensure I can still come back from catastrophic events.

oxcrag.net
I just had to restore a folder from backup, and it turned out, that my regular #ZFS snapshot service (Sanoid) was not running, I must've stopped the timer some time ago and forgot. But the nightly backups were still running, so the actual lost work is not that much. Test your #backup!
Ps. Thanks for @jimsalter and all other contributors for the amazing tool of #Sanoid and #Syncoid (which saved me this time)!