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.

Hi @Pirat , thank you for the update! It does fix things. However, there are a couple of quirks.

The logs of the post snapshot script all print with the same timestamp. Here's my log, you can see the post-snapshot script only has one timestamp, even though in a couple of lines it's waiting 30s. However, the pre-snapshot script does show varying timestamps as it executes.

2026-10-23 04:03:09: Starting sonarr
2026-10-23 04:03:09: Waiting 30s after starting sonarr...
2026-10-23 04:03:09: Starting radarr
2026-10-23 04:03:09: Waiting 30s after starting radarr...
2026-10-23 04:03:09: Starting bazarr
2026-10-23 04:03:09: All containers restarted successfully.
2026-10-23 04:04:06: Successfully synced local backup!
2026-10-23 04:04:06: [[rc.buddybackup finished]]

Another thing is, the cron jobs for some backups are no longer working, the backups never run. I don't see them in the logs, and if I click on "send backup now" they do send successfully. So maybe the cron scheduling isn't working.

I asked an ai about it and it said this

Bug: Scheduled backup cron jobs are silently deleted when optional fields (destination_user, pre_backup_script, post_backup_script) are blank.

Location: /usr/local/emhttp/plugins/buddybackup/scripts/rc.buddybackup.php in update_backups_from_config() (lines 1214–1225).

Issue: When backups are saved via the WebGUI, optional fields left blank are written to backups.cfg as empty strings (destination_user="", pre_backup_script="", post_backup_script=""). In update_backups_from_config(), $allow_empty for remote backups only allows destination_port, and hooks are omitted from $allow_empty entirely. Any backup with empty optional fields is treated as invalid, causing unlink("$plugin_path/$file") to delete the cron file and skip calling add_backup_cron_file($uid, $cfg).

Proposed Fix:

$allow_empty = array('pre_backup_script', 'post_backup_script', 'destination_user', 'destination_port');

if ($is_local) {

$allow_empty[] = 'destination_host';

}

Hi @cherrybullet ,

Thanks for reporting these! Both issues are now fixed in the 2026.10.25 release that just went live:

1. Scheduled backups dropping cron jobs: The AI analysis was correct. update_backups_from_config() was treating blank optional fields (hooks, destination user, etc.) as invalid entries and silently unlinking their cron files. The scheduler now checks strictly required fields only, and updating the plugin automatically regenerates the missing cron jobs from your config.

2. Identical hook log timestamps: Hook output was previously buffered until the command finished before writing to the log, which caused all lines to share the final completion timestamp. Output is now streamed line-by-line in real time, so delays and sleeps will show their accurate individual timestamps.

Update to 2026.10.25 and give it a test. Let me know if everything runs smoothly for you now!

On 10/14/2026 at 10:14 PM, Pirat said:

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

Unfortunetly the issue is back again after updating and rebooting to unraid 7.3.4.

And the workaround isn't helping this time.

What can I do to make everything work again?

Thank you in advance!

On 10/27/2026 at 7:12 AM, Bladeinger said:

Unfortunetly the issue is back again after updating and rebooting to unraid 7.3.4.

And the workaround isn't helping this time.

What can I do to make everything work again?

Thank you in advance!

Hey, just to double check - are you using Buddy backup version 2026.10.25 on both receiver and sender?

I am feeling stupid now... 🙄

As I wanted to check the version, I realized that the Buddy Backup Plugin wasn't installed anymore.

Obviously vanished during the update/reboot-process. Very strange...

Re-installed it and all 5 Clients are replicating without problems again.

BTW: Are there any plans to implement pull-replication?

Cheers!