Pirat

I've pushed hotfix version 2026.10.18 that should solve this issue. Give it a test! The problem was that the usb boot drive is formatted as FAT32, and Unraid mounts it without execution file permissions, which disallows running a script file from its filename and shebang only. To work around this, you can either type "bash /boot/config/plugins/buddybackup/hooks/pre-snapshot.sh" in the hook field, or just update the plugin since it will now detect this and automatically execute the hooks via bash (or set shebang interpreter) when needed.

Version 2026.10.16 is now out! Changelog: - Support multi-dataset replication using a single shared SSH key across multiple destination datasets [#38] - Support custom SSH ports for remote BuddyBackup destinations - Configurable daily snapshot time with 1-minute cron heartbeat and asynchronous backup triggers [#25] (from your suggestion @cherrybullet ) - Native atomic ZFS recursion and automatic baseline snapshots for newly created child datasets [#36] - Automatically restore receiver user and group configuration across server reboots [#37] (fix for your issue @Bladeinger ) - Auto-suggest destination sub-dataset paths from source dataset and detect duplicate destinations [#26]

Hi, thanks for using the plugin and letting me know about this! I believe this is the exact same issue as reported in https://github.com/Piratkopia13/unraid-buddybackup/issues/37. It is resolved in the next version of the plugin, which I should be able to release in a couple of days. If you want a quick workaround until then, running this after a reboot on the receiver server should resolve it: ``` gid=$(id -g buddybackup) getent group "$gid" >/dev/null 2>&1 || groupadd -g "$gid" buddybackup usermod -d /home/buddybackup -s /bin/bash buddybackup chown -R buddybackup:buddybackup /home/buddybackup ```

This is a good point, especially useful to control the timing of when containers restart. I've added support for this in the next update that will go out very soon! You will be able to set the snapshot time per entry like this:

@menthor I've just pushed version 2026.09.27, which adds support for your use case. After updating the plugin on both servers, here is how you would set it up: On the receiving Server (Buddy's Backups tab): Destination parent dataset: cache/appdata Immutable dataset: Set to No (keeps the datasets mounted at /mnt/cache/appdata/ and writable for your hot-standby containers, instead of write-protected and unmounted). On the sending Server (Backup and restore tab): ZFS dataset to backup: cache/appdata Backup child datasets: Yes Skip parent dataset: Yes (replicates all child datasets without nesting/duplicating the parent) Destination dataset: cache/appdata (matching the receiver's parent dataset directly is now supported) Test Connection should now pass cleanly, and the backup will mirror all child datasets directly into cache/appdata/ on the standby server. Let me know how it works for you!

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.