Setting up syncoid for offsite backup

Hello.

I’ve been lurking here for awhile and not quite been able to figure out what I’m doing. As a ZFS neophyte, I’m just trying to wrap my head around using sanoid/syncoid. But, I think I’ve been using too many disparate sources and recommendations and find myself more confused than I started.

I have several servers for both personal and business use and after listening to 2.5 Admins for several years, finally made the leap to ZFS when rebuilding my primary server last year. However, I never got around to really taking advantage of all it’s benefits. I think that last night I was finally able to get sanoid running automatic snapshots on my test server.

The part I have confused myself on is getting syncoid setup to push (or pull??) those to/from my offsite backup.

I’ve found numerous blog posts of people doing it, as well as numerous partially related topics here; but I feel like I’ve walked away more uncertain about the process than anything. I’m comfortable with the Linux CLI, but know very little about ZFS.

Can anyone recommend a good guide for getting syncoid setup?

2 Likes

There are a few if you Google around.

However, here’s the bare bones of it.

Sanoid = snapshot management. This should be running on both sides, but you want to disable autosnap on the backup host.

Syncoid = replication tool. GENERALLY you want to run this as a cron job from the backup host, and do a pull style replication.

The documentation on Github is pretty good for getting it up and running. sanoid/INSTALL.md at master · jimsalterjrs/sanoid · GitHub.

The wiki also has some example templates you can use as a base:

Though, as I learned recently, be careful about trailing spaces in /etc/sanoid/sanoid.conf! :joy:

1 Like

The basics are as follows, assuming you want to run syncoid on the target pulling from the source (pull backup) as opposed to running it on the source pushing to the target (push backup):

  • generate an SSH key on the target. for now, just generate one for root–later, when you’re feeling fancy, you can set up ZFS delegation and use an unprivileged user account, but for right now it sounds like you need to see a W as soon as possible.

  • copy the pubkey from the target to the source. Place that pubkey in the source’s /root/.ssh/authorized_keys file. If you’re utterly unfamiliar with this, this can be as simple as literally just putting the pubkey in /root/.ssh and naming it authorized_keys. Later, if you need more than one key to work, you just put extra keys in the same file after the first one, each on their own line. There is no additional syntax to worry about.

  • Now, make sure your SSH key sharing worked–you should be able to ssh root@source from your target machine and immediately get a prompt. If not, don’t go any further–you need to get this part right before going any further.

  • Once you’ve got SSH working using keys, you’re ready to roll: syncoid -r root@source:sourcepool/dsname targetpool/dsname will replicate the dataset sourcepool/dsname and all children from the source machine to targetpool/dsname (and so forth) on the target system.

Essentially, syncoid makes ZFS replication look and feel like a much faster version of rsync. Note that in addition to the datasets themselves, you get all snapshots which were taken on the source present on the target as well.

ALSO note, you should be running Sanoid on the target as well as the source–but on the target, the module referring to replicated-in datasets should use the backup or hotspare templates, not the production template. This is because you should not attempt to take snapshots locally of datasets you routinely replicate in from a different source; at best, incoming replication wipes out all the snapshots you took locally (it has to, this is part of how replication works) and at worst, you wind up with same-name but different-GUID snapshots that don’t match and can’t be used as replication targets, and you wind up having to figure out how to unsnarl a confusing mess. :slight_smile:

If you have further questions, ask: but try to get through the SSH key sharing bits and confirm that you can SSH from target to source successfully first, please.

1 Like