On 9/27/2026 at 1:49 PM, Pirat said:

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

Thank a lot vor all your efforts! 👍

I will test next weekend and come back asap

On 9/27/2026 at 1:49 PM, Pirat said:

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

Thank a lot vor all your efforts! 👍

I will test next weekend and come back asap

23 hours ago, menthor said:

Thank a lot vor all your efforts! 👍

I will test next weekend and come back asap

Thank a lot vor all your efforts! 👍

I will test next weekend and come back asap

Hi @Pirat ,

I had some time to do some testing and yes, the new feature works perfectly fine for my use case.
Again, thanks a lot!

Using ZFS send/receive with your tool is so conveiniant and makes backup way faster compared to file-based sync.

To avoid lenghtly chats here in the forum, I have created issues on your Github.

No worries, nothing serious, just some tweaks ;)

Hi Pirat, I just installed the new version that adds hooks support.

One question, is it possible to specify when snapshots run, like on a cron job? I see that the cronjob setting is available for backups, but can't find something like it for snapshots. I was hoping to add pre/post hooks to stop/start docker containers, but I prefer stopping them at like 4am when most people are asleep.

Right now, I have this retention setting, which creates one snapshot per day at around 12 am.

Thanks a lot for this great plugin!

I use it for snapshot replications from 6 unraid servers to my unraid server.

Worked great for several months.

But now, after restarting my server (update to unraid 7.3.3), not one single replication is working anymore.

All replications show this message:

Event: Unraid Status
Subject: BuddyBackup
Description: Sending backup failed. Error code 2. Full output: [email protected]: Permission denied (publickey).
[email protected]: Permission denied (publickey).
CRITICAL ERROR: ssh connection echo test failed for [email protected] with exit code 255
Importance: alert

ssh connection from all servers is still working. Not any key has changed.

What can I do to make the replications work again?

On 10/9/2026 at 11:12 AM, cherrybullet said:

Hi Pirat, I just installed the new version that adds hooks support.

One question, is it possible to specify when snapshots run, like on a cron job? I see that the cronjob setting is available for backups, but can't find something like it for snapshots. I was hoping to add pre/post hooks to stop/start docker containers, but I prefer stopping them at like 4am when most people are asleep.

Right now, I have this retention setting, which creates one snapshot per day at around 12 am.

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:

3 hours ago, Bladeinger said:

Thanks a lot for this great plugin!

I use it for snapshot replications from 6 unraid servers to my unraid server.

Worked great for several months.

But now, after restarting my server (update to unraid 7.3.3), not one single replication is working anymore.

All replications show this message:

Event: Unraid Status
Subject: BuddyBackup
Description: Sending backup failed. Error code 2. Full output: [email protected]: Permission denied (publickey).
[email protected]: Permission denied (publickey).
CRITICAL ERROR: ssh connection echo test failed for [email protected] with exit code 255
Importance: alert

ssh connection from all servers is still working. Not any key has changed.

What can I do to make the replications work again?

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
```

Edited October 14Oct 14 by Pirat

Thank you for your quick response.

Your workaround makes all backups work again.

Perfect support here!

Some coffees are on their way...

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]

I tried adding pre/post-snapshot hooks, and saw this in the log

2026-10-17 02:00:01: sh: line 1: /boot/config/plugins/buddybackup/hooks/pre-snapshot.sh: Permission denied
2026-10-17 02:00:01: WARN: pre_snapshot_script failed, 32256 at /usr/local/emhttp/plugins/buddybackup/deps/sanoid line 1841.
2026-10-17 02:00:01: Running post-snapshot hook (timeout 300s)..
2026-10-17 02:00:01: No state file found. Containers were either not stopped or the file was deleted.

So the pre-snapshot hook fails to run, but post-snapshoot hook does run. The scripts are supposed to stop/start containers, I tested running them before putting them into backupbuddy hooks.

10 hours ago, cherrybullet said:

I tried adding pre/post-snapshot hooks, and saw this in the log

2026-10-17 02:00:01: sh: line 1: /boot/config/plugins/buddybackup/hooks/pre-snapshot.sh: Permission denied
2026-10-17 02:00:01: WARN: pre_snapshot_script failed, 32256 at /usr/local/emhttp/plugins/buddybackup/deps/sanoid line 1841.
2026-10-17 02:00:01: Running post-snapshot hook (timeout 300s)..
2026-10-17 02:00:01: No state file found. Containers were either not stopped or the file was deleted.

So the pre-snapshot hook fails to run, but post-snapshoot hook does run. The scripts are supposed to stop/start containers, I tested running them before putting them into backupbuddy hooks.

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.