Pirat

@Masterwishx Strict mode, as in the snapshots in the destination are always kept mirrored from the source (--delete-target-snapshots), comes with some risks that make me prefer having pruning for local backups be a separate step. For example, if you mistakenly delete one or multiple snapshots on the source, then they will also be removed from the backup. Keeping pruning separate is the safer option. Yeah, Sanoid can be a bit strange with its scheduling, but it should at least be relatively consistent going forward. My daily snapshots are usually taken between 23:30 and 00:15 for reference. Have you figured out all your issues then?

@Masterwishx Thanks for the suggestions! I agree that your first 2 suggestions would be useful. Could you clarify how the sound notification works in Spaceinvaderone's script? Since I never used that myself. I will add these to my backlog. Regarding your questions: The "Snapshot creation and pruning" is pretty much just a GUI for the Sanoid config file. The plugin automatically runs Sanoid every 15 minutes, and when it runs, Sanoid checks whether any new snapshots should be created or pruned according to the config. Sub-hourly snapshots are not exposed in the GUI (I should perhaps add that), so the most frequent backup you can set is hourly by setting snapshot retention hourly > 0. Sanoid will then automatically create snapshots every hour. If you have "Trigger backup after snapshot creation" set together with "Create snapshots automatically: yes", then there is no need to have cron enabled for that backup. Cron schedule for backups is mostly useful for remote backups, as you say, or if you have snapshot creation done externally (as in not with BuddyBackup). The latter case can make cron useful for both local and remote destinations.

Hey! BuddyBackup does not conflict with the sanoid plugin. See https://forums.unraid.net/topic/186256-zfs-buddybackup-plugin-guide/page/2/#findComment-1548639

Hi. The lines you show here are not errors, they are normal sshd logs showing that an SSH session is started or closed, which happens every time BuddyBackup sends a backup to a remote destination. Nothing to worry about! If you get spammed by them, you should probably have a look at your schedules and reduce how often your backups are sent.

The focus of this plugin is to simplify the backup process specifically between two UnRaid machines using this plugin. With that said, it's possible to have the other side run on any OS as long as it's done the same way buddybackup does. See https://github.com/Piratkopia13/unraid-buddybackup/issues/2#issuecomment-2658728152 for my comment on how you could receive backups on a non-UnRaid target, for example.

Thanks for the suggestion! I added it as an issue on the github for future tracking, and my own thoughts on it GitHubAllow using -F flag when running restore · Issue #18 · Pi...From hydkrash on unraid forums (https://forums.unraid.net/topic/186256-zfs-buddybackup-plugin-guide/page/2/#findComment-1572178) : I had to recreate a local pool and dataset. When I was performing ...

What you are showing in the first screenshot is that you have full disk encryption set in Unraid (luks). This is different than zfs dataset encryption. In order to send raw encrypted zfs datasets, they have to be encrypted by zfs. You can still have luks as well but it might be unessesary depending on your needs. The easiest way to create an encrypted zfs dataset in unraid is to use the ZFS master plugin.

Ah, for local destinations you can add a new entry in the snapshot creation and pruning section, disable autosnap and enable auto pruning and set your desired retention there.

Received snapshots are pruned according to the set snapshot retention in the "Buddy's Backups" section on the machine that receives the backups. Regarding snapshots being created on the same day, that does sound weird... Snapshot creation timing is handled by the default sanoid config, see https://github.com/jimsalterjrs/sanoid/blob/master/sanoid.defaults.conf. I have thought about exposing this config under advanced settings in the plugin to allow for more control. Perhaps that could help your case as well 🤔

I don't have anything like this planned, but it's a cool idea! I have enabled discussion on the GitHub repo. Feel free to create a post for finding backup buddies.

Thanks for the suggestions! Sadly, manually creating snapshots that would also be included when Sanoid runs pruning is not really possible afaik. I'm also not seeing any way of excluding child datasets with Sanoid (https://github.com/jimsalterjrs/sanoid/wiki/Sanoid). But let me know if I'm missing something!

Hi @MothyTim BuddyBackup uses its own instance of sanoid and syncoid and will therefore not conflict with the sanoid plugin! However, if you transfer over your backup configs and is happy with buddybackup there is no reason to keep the sanoid plugin installed anymore 😁

You can just add the local destination dataset to the snapshot creation and pruning section. Disable autosnap, enable autoprune and select retention.

Just pushed version 2025.03.02 with support for restoring snapshots from local backups @MowMdown

I will investigate the cron snapshot not being created on a fresh install, that shouldn't happen 🤔 Your syncoid error there looks to me like the destination parent dataset (cache/appdata) doesn't have any snapshots, but all the child datasets do. I think this could happen if you for instance created the destination dataset yourself instead of letting syncoid create it on the first backup. Please verify if that is the case for you, and if it is the easiest way to solve that is manually syncing the oldest snapshot for the parent dataset with `zfs send cache/appdata@name-of-oldest-snapshot | zfs recv -F backup_hdd/zfs_backup/appdata_backup`. Note the -F flag which is destructive and will rollback the destination to match the source. You could also change the backup destination to a new dataset that doesn't exist and re-run the full backup.