The title speaks for itself. With XigmaNAS, the only feasible backup option is to use rsync. They do have a third party extension called “zrep” which is fine, but I’m looking to do most of the backkup via the GUI. Rsync is available via the GUI.
Can we just get a list of pros and cons to using rsync vs replication?
There was this thread but it didn’t really cover the question I’m asking.
A few come to mind. rsync is generally slower as the number of files increases, and more system intensive. rsync is typically used as just a copy of the current system. It’s typically not versioned, which is bad IMHO, versioned “backups” are pretty useful for many cases. Delete a file a few days ago, oops, not on the rsync copy. It can be with some storage/cloud systems though. rsync typically goes to a non bitrot protected filesystem, so, not as “safe” though it can be.
I actually rsync a small number of things as part of my overall backup strategy, it does what it does but it’s inferior to replication as the entire process is end to end checked with replication.
Probably other reasons. Just off the top of my head.
So, what if one were to user rsync, but have snapshot tasks on both the remote side and the local side?
Does rsync overwrite files that change? Even if it does, if I were to have snapshots on both sides (providing of course datasets have been created beforehand) would that not mitigate the risk of it overwriting some files?
I could just roll back to an earlier snapshot if I have to.
So, rsync does what you tell it. So, yes, it could overwrite files but if you want a current copy of your data, you’d want it to.
So, you take a snapshot of the local side and you lose the pool. Obviously, the local snapshots are useless, but you have your remote copy. If you are taking snapshots on the remote side, that implies it’s using zfs. So, you could take snapshots and rsync. Though, rsync very slow compared to replication, but if that is not something Xigma does, I guess it’s a substitute and if it’s the best you can do then it is.
The one thing about replication I hate is it doesn’t play well when I have snapshots of the dataset I’m replicating on the receiving side.
Why does it complain so much? I have to then delete all snapshots on the receiving end before it starts working.
It doesn’t play at all 
Why does it complain so? To prevent you automatically blowing away your backup when you rollback the source
If you tick the “replicate from scratch” checkbox that should force it to rollback the destination.
After it has, then untick again.
Do go on…
How does it work then? I haven’t been able to fully understand why.
What if I want to do the backup, and have additional snapshots on the receiving side?
You can’t.
So lets get this straight.
I have one backup server that is configured to PULL replicate from my main server. This backup server does all the work.
I then have my main server that I want to create snapshots for in order to roll back on when something happens.
Are you saying I can’t do this?
And why is it that there are snapshots present on my backup and main servers of the same datasets?
What does this mean then?
ZFS replication is generally going to be faster, particularly if you have small changes on bulk files (eg. VM images, ISO’s, etc.).
That said, rsync has its place. I usually use it as a better version of cp/mv. It supports tunneling through SSH natively and progress/status reports, which make it handy if I’m making a lengthy transfer through SSH and I want to monitor the progress.
Google is not helping me with this next question.
Is there a detailed article explaining the ins and outs of why snapshots cannot be created on ZFS datasets if they are part of a replication task/process?
You can create snapshots on the destination dataset of a replication, but they will have to be destroyed before anotehr replication from the source can be performed.
end of story.
The low down technical reason is that each snapshot requires an uber-block update, and the destination has to be rolled back to the previous uber-block (ie snapshot) in order to roll forwards with the updated sequence of blocks in the replication.
(to be fair, I’m actually not 100% clear on how this actually works with respect to datasets, but basically, a snapshot is a reference to a specific uberblock)
Ergo, if you rollback the source, and then were to replicate that change to the destination, it would rollback the destination too.
That could irretrievably lose the data that was “backed up” to the destination, ergo, once you rollback the source, which irretrievably loses data on the source, it requires manual intervention to replicate that rollback to the destination.
If you create a snapshot on the destination, even if there are no changes, then the next replication to that destination (doesn’t matter if its pull or push) will only be able to proceed, once the destination is rolled back to the most recent snapshot that both the source and destination have in common, which is what the “replicate from scratch” checkbox does
the “same as source” option means that when the replication completes, any snapshots that are part of the replication set (ie based on schema etc) will be deleted from the destination if no longer present on the source.
Now, you can configure a custom deletion policy for a schema, not sure if this is supported in the replication ui, but that would allow you to customize when a certain snapshot scheme is deleted. And you could then add a snapshot task to take those snapshots… which expires very quickly… BUT if the replication task is set to hold pending snapshots, and use a custom expiry on the destination, then that accomplishes the ephemeral snapshot on the source, but long retention on the destination, while allowing other ephemeral snapshots to have shorter retentions.
So the snapshots that exist on the source and destination are exactly the same, and that is the only way they can be present on both sides?
Because there are definitely snapshots on both sides of the replication task.
I was thinking there can be NO snapshots on the receiving side, but it seems that if they are the same, then no problem with replication.
Yes.
You could diverge the destination… but if you ever wanted to replicate the source to the destination again, the destination would have to be rolled back to a common base, assuming the same destination… and not just abother… for example you could do a local replication on the destination, and then replicate to that other destination…
If you want to do something else, say two way synchronizing, then replication is not the tool, and either rsync, or maybe syncthing is
Ok. I was just curious as to how there can be snapshots on the destination, but it has to match exactly the source snapshot.
So, by way of example I have minutly, hourly and weekly snaps on the source… the hourly and weekly are replicated to a backup destination.
I also wanted to have “monthly” snaps on the destination which do not get deleted.
The only way to accomplish this is to have the source take the monthlys, replicate them, but not have the source delete them on the destination, then the source can delete the monthlys after they have been replicated.
How Snapshots Really Work - Matt Ahrens, BSDCAN 2019
Everything clear now? Or have I confused the situation more
