Pirat

Hey! This last update did change the behaviour of the plugin for your specific use case of a hot stand-by destination, as it now forces immutability on the destination with zfs properties. You can do this setup with one backup entry with "Backup child datasets" on, but currently only to a different (new) destination dataset than your cache/appdata, and that would default to unmounted and read-only.. Let me experiment with adding an immutability toggle on the receiver side, and supporting sending to a destination dataset that matches the receiver's configured dataset. Note that this would require "skip parent dataset" also to be enabled on the backup entry. That should support your use case.

Hi everyone, I've just pushed a new release of the plugin (2026.09.23) A few key highlights in this release: Back up to & receive from any OpenZFS system: You're no longer limited to Unraid-to-Unraid setups. You can now send backups to any remote machine running OpenZFS (TrueNAS SCALE, Proxmox VE, Debian, Ubuntu, etc.), as well as receive incoming backups from them (such as native replication tasks from TrueNAS SCALE). When setting up a generic remote host, the UI now generates a one-time copy-paste root command for the remote machine. It sets up the restricted user, SSH forced-command allowlist (restrict_zfs), and delegated ZFS permissions automatically. Backup destination datasets now enforce readonly=on and mountpoint=none by default to keep backups safe and avoid mount collisions. Complete UI Overhaul: The interface across all tabs has been reworked: Clean card layouts with status indicators, telemetry badges, and collapsible sections. Reworked the Unraid dashboard panel into a responsive grid so it no longer causes horizontal scrollbars when zooming in, and brought back the show/hide chevron button. The Buddy's Backups tab now supports multiple incoming buddies independently, each with their own SSH key and isolated status. @jbohbot regarding the Exit Code 2 error (Comment #1628821): This is fixed in 2026.09.23. Newer versions of OpenZFS and Syncoid probe remote capabilities over SSH (zfs version, receive_resume_token, and dataset encryption properties). Previously, the receiver's restricted SSH script rejected those informational queries, which caused the sync to exit with code 2. Those probe commands are now allowlisted, so the handshake completes cleanly. @alucard87.pl and @DasMarx regarding non-Unraid ZFS targets and the SSH $PATH issue (Comment #1580762 / Comment #1594171): Both of these are sorted out: You can now replicate to and receive from non-Unraid ZFS endpoints (Proxmox, TrueNAS SCALE, Debian/Ubuntu). The non-root $PATH issue is fixed in restrict_zfs by explicitly prepending /usr/local/sbin:/usr/sbin:/sbin, so the zfs binary is always found regardless of the remote distro, shell profile, or Unraid version. You can update via the Plugins tab in Unraid or reinstall from Community Apps. Let me know how it works for you!

@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.