There was a power outage so one of my buddies (buddy A) went down. When the power came back and it booted, I got this error message:

BuddyBackup

Aborting backup. Source dataset 'cache/appdata' does not exist!

However, when I looked at my zfs datasets, they had all loaded fine and my containers were all running fine. I also noticed that the other buddy (buddy B) could not connect to buddy A anymore. Buddy A's sshd server failed to start on boot, so I started it. I also tried invoking a reboot on the server myself, when it booted this time, there was no error and the sshd server started fine.

I'm not sure if this is a bug with BuddyBackup not setting something up with ssh because it can't find the dataset, or with unraid failing to clean things up during a power outage.

Hi, I am handing on this plugin.

But I found that this plugin is only for backing up the dataset; I can not use it to take snapshots automatically.

My plan is like:

cache\appdate and cache\system keep 12 hourly snapshots, 3 daily snapshots on the dataset cache;

Back up all the above to extend the HDD dataset, once per day. But on the HDD dataset, I like to keep 12 hourly snapshots, 3 weekly snapshots, and 1 monthly snapshot.

I did not find the solution to configure the snapshots for cache. Could you give some idea about that?

My syslog is getting filled up with errors from buddybackup. Any idea what might be causing this?

Apr  3 02:12:53 yoshi sshd-session[764655]: Close session: user buddybackup from x.x.x.x port 35514 id 0
Apr  3 02:12:54 yoshi sshd-session[764655]: Starting session: forced-command (key-option) '/usr/local/emhttp/plugins/buddybackup/deps/restrict_zfs' for buddybackup from x.x.x.x port 35514 id 0
Apr  3 02:12:54 yoshi sshd-session[764655]: Close session: user buddybackup from x.x.x.x port 35514 id 0

Edited April 3Apr 3 by cherrybullet
formatting

On 4/3/2026 at 11:19 AM, cherrybullet said:

My syslog is getting filled up with errors from buddybackup. Any idea what might be causing this?

Apr  3 02:12:53 yoshi sshd-session[764655]: Close session: user buddybackup from x.x.x.x port 35514 id 0
Apr  3 02:12:54 yoshi sshd-session[764655]: Starting session: forced-command (key-option) '/usr/local/emhttp/plugins/buddybackup/deps/restrict_zfs' for buddybackup from x.x.x.x port 35514 id 0
Apr  3 02:12:54 yoshi sshd-session[764655]: Close session: user buddybackup from x.x.x.x port 35514 id 0

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.

If i want to migrate to plugin from Spaceinvader script + sanoid plugin , should be removed sanoid plugin first?

1 hour ago, Masterwishx said:

If i want to migrate to plugin from Spaceinvader script + sanoid plugin , should be removed sanoid plugin first?

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

@Pirat Checked the plugin ,its really cool , sorry that took me so much time to get on it from spaceinvaider script ....

Just for info :

1. As i understand, its check every 15 min of sanoid config for snapshots retention / creation , will be cool maybe to have also manually create snapshot by button ?

2. Maybe also will be cool to have default-auto-generated addon path in case if not exist for Destination dataset like, when i choose pool/dataset it will add source pool_dataset after it (with button create dataset) :

   cache_appdata in disk3/zfs_backups/cache_appdata when ZFS dataset to backup: cache/appdata

Example from script:

destination_pool="disk3"  #this is the zpool in which your destination dataset will be created
parent_destination_dataset="zfs_backups" #this is the parent dataset in which a child dataset will be created containing the replicated data (zfs replication)
...
...
source_path="$source_pool"/"$source_dataset"
source_dataset_flat=$(echo $source_dataset | sed 's|/|_|g')
zfs_destination_path="$destination_pool"/"$parent_destination_dataset"/"$source_pool"_"$source_dataset_flat"

We can create it manually before it off course ....

Edited May 16May 16 by Masterwishx

Also will awesome to add option for we can add sound (speaker) notify like in Spaceinvaderone script...

I'm confused a little:

1. We don't have cron for snapshots (or should be made in check of 15m?), so not sure when snapshot should be made (in test server it was done but in my main sever still no snapshot was made)

2. Also as i understand for local backup we don't need set cron if we set backup to run after snapshot? So it need cron only when remote or not set after snapshot?

@Pirat maybe you need to add help description for options to get more info for options...

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

We don't have cron for snapshots (or should be made in check of 15m?), so not sure when snapshot should be made (in test server it was done but in my main sever still no snapshot was made)

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.

Also as i understand for local backup we don't need set cron if we set backup to run after snapshot? So it need cron only when remote or not set after snapshot?

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.

Edited May 16May 16 by Pirat

9 minutes ago, Pirat said:

Since I never used that myself.

I will add these to my backlog.

Thanks, sure I will add as future request in github

12 minutes ago, Pirat said:

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),

In my main sever I have already snapshots + Backups from script (system_ssd/appdata) made yesterday at 20:00 and I don't see that plugin made any snapshot or backup Hovewer in dashboard it wrote that made somethink..

Also added snapshot for flash/boot and also can't see any snapshots.

I can see in log only that synchronise ok

Also seems we need to add retensions for local backups in snapshots menu, do you think will be useful to add strict mode option maybe to syncoid?

If it not over complicate the plugin?

23 minutes ago, Pirat said:

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.

    system_cache_ssd/appdata@autosnap_2026-05-13_20:00:03_daily	56 KiB	232 KiB	56 KiB	off	0	2026-05-13 20:00:03	
	system_cache_ssd/appdata@autosnap_2026-05-14_20:00:03_daily	56 KiB	232 KiB	56 KiB	off	0	2026-05-14 20:00:03	
	system_cache_ssd/appdata@autosnap_2026-05-15_20:00:04_daily	0 B	232 KiB	56 KiB	off	0   	2026-05-15 20:00:04	
	system_cache_ssd/appdata@syncoid_MyTower_2026-05-15:20:00:17-GMT03:00	0 B	232 KiB	0 B	off	0	2026-05-15 20:00:17	

sanoid.conf

[system_cache_ssd/appdata]
    recursive = yes
    autosnap = yes
    autoprune = yes
    hourly = 0
    monthly = 3
    daily = 7
    yearly = 0
    weekly = 4
    post_snapshot_script = /usr/local/emhttp/plugins/buddybackup/scripts/rc.buddybackup.php send_backup "aa4ed6a1" 2>&1 | /usr/local/emhttp/plugins/buddybackup/scripts/log.sh
[flash/boot]
    recursive = no
    autosnap = yes
    autoprune = yes
    hourly = 0
    monthly = 3
    daily = 7
    yearly = 0
    weekly = 4
    post_snapshot_script = /usr/local/emhttp/plugins/buddybackup/scripts/rc.buddybackup.php send_backup "81370285" 2>&1 | /usr/local/emhttp/plugins/buddybackup/scripts/log.sh
[disk7/zfs_backups/system_cache_ssd_appdata]
    recursive = yes
    autosnap = no
    autoprune = yes
    hourly = 0
    monthly = 3
    daily = 7
    yearly = 0
    weekly = 4
[disk7/zfs_backups/flash_boot]
    recursive = no
    autosnap = no
    autoprune = yes
    hourly = 0
    monthly = 3
    daily = 7
    yearly = 0
    weekly = 4

snapshots.cfg

[7e4d1070]
dataset="system_cache_ssd/appdata"
recursive="yes"
autosnap="yes"
autoprune="yes"
hourly="0"
monthly="3"
daily="7"
yearly="0"
weekly="4"
trigger="aa4ed6a1"
[755c4461]
dataset="flash/boot"
recursive="no"
autosnap="yes"
autoprune="yes"
hourly="0"
monthly="3"
daily="7"
yearly="0"
weekly="4"
trigger="81370285"
[ecbc2001]
dataset="disk7/zfs_backups/system_cache_ssd_appdata"
recursive="yes"
autosnap="no"
autoprune="yes"
hourly="0"
monthly="3"
daily="7"
yearly="0"
weekly="4"
trigger="no"
[4a91a312]
dataset="disk7/zfs_backups/flash_boot"
recursive="no"
autosnap="no"
autoprune="yes"
hourly="0"
monthly="3"
daily="7"
yearly="0"
weekly="4"
trigger="no"

backups.cfg

[aa4ed6a1]
enable="no"
source_dataset="system_cache_ssd/appdata"
recursive="yes"
backup_cron="0 20 * * *"
type="local"
destination_host=""
destination_dataset="disk7/zfs_backups/system_cache_ssd_appdata"
[81370285]
enable="no"
source_dataset="flash/boot"
recursive="yes"
backup_cron="10 20 * * *"
type="local"
destination_host=""
destination_dataset="disk7/zfs_backups/flash_boot"

Log

2026-05-16 09:45:15: Successfully synced local backup!
2026-05-16 09:45:15: [[rc.buddybackup finished]]
2026-05-16 10:00:14: Successfully synced local backup!
2026-05-16 10:00:14: [[rc.buddybackup finished]]
2026-05-16 10:15:15: Successfully synced local backup!
2026-05-16 10:15:15: [[rc.buddybackup finished]]
2026-05-16 10:30:28: Successfully synced local backup!
2026-05-16 10:30:28: [[rc.buddybackup finished]]
2026-05-16 10:45:14: Successfully synced local backup!
2026-05-16 10:45:14: [[rc.buddybackup finished]]
2026-05-16 11:00:15: Successfully synced local backup!
2026-05-16 11:00:15: [[rc.buddybackup finished]]
2026-05-16 11:15:15: Successfully synced local backup!
2026-05-16 11:15:15: [[rc.buddybackup finished]]
2026-05-16 11:30:18: Successfully synced local backup!
2026-05-16 11:30:18: [[rc.buddybackup finished]]
2026-05-16 11:45:15: Successfully synced local backup!
2026-05-16 11:45:15: [[rc.buddybackup finished]]
2026-05-16 12:00:14: Successfully synced local backup!
2026-05-16 12:00:14: [[rc.buddybackup finished]]
2026-05-16 12:15:14: Successfully synced local backup!
2026-05-16 12:15:14: [[rc.buddybackup finished]]
2026-05-16 12:30:15: Successfully synced local backup!
2026-05-16 12:30:15: [[rc.buddybackup finished]]
2026-05-16 12:45:15: Successfully synced local backup!
2026-05-16 12:45:15: [[rc.buddybackup finished]]
2026-05-16 13:00:38: Successfully synced local backup!
2026-05-16 13:00:38: [[rc.buddybackup finished]]
2026-05-16 13:15:16: Successfully synced local backup!
2026-05-16 13:15:16: [[rc.buddybackup finished]]

Finally the first snapshot for /flash/boot was made in 14:15, interesting how sanoid choose when to make snapshot with (0 7 4 3 0)...

@Masterwishx

Also seems we need to add retensions for local backups in snapshots menu, do you think will be useful to add strict mode option maybe to syncoid?

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.

Finally the first snapshot for /flash/boot was made in 14:15, interesting how sanoid choose when to make snapshot with (0 7 4 3 0)...

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?

36 minutes ago, Pirat said:

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.

OK ,got it

37 minutes ago, Pirat said:

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.

So not better to add also option with schedule for snapshots/retention or better to let sanoid choose time ?

39 minutes ago, Pirat said:

Have you figured out all your issues then?

Well, for now only flash/boot made snapshot/backup but i cant see syncoid like this:

flash/boot@syncoid_MyTower_2026-05-15:20:00:17-GMT03:00	0 B	232 KiB	0 B	off	0	2026-05-15 20:00:17	

Only have:

    flash/boot@autosnap_2026-05-16_14:15:02_monthly	0 B	2.45 GiB	2.45 GiB	off	0	2026-05-16 14:15:02	
	flash/boot@autosnap_2026-05-16_14:15:02_daily	0 B	2.45 GiB	0 B	        off	0	2026-05-16 14:15:02	
	flash/boot@autosnap_2026-05-16_14:15:02_weekly	0 B	2.45 GiB	0 B	        off	0	2026-05-16 14:15:02	

For system_cache_ssd/appdata still have NOT made any snapshots/backups , maybe sanoid waiting for make it in same time that old snapshots/backups was made by script (20:00) ?

    system_cache_ssd/appdata@autosnap_2026-05-14_20:00:03_daily	56 KiB	232 KiB	56 KiB	off	0	2026-05-14 20:00:03	
	system_cache_ssd/appdata@autosnap_2026-05-15_20:00:04_daily	0 B	232 KiB	56 KiB	off	0	2026-05-15 20:00:04	
	system_cache_ssd/appdata@syncoid_My_Tower_2026-05-15:20:00:17-GMT03:00	0 B	232 KiB	0 B	off	0	2026-05-15 20:00:17	

Edited May 16May 16 by Masterwishx

@Pirat After talking to Ai, sanoid debug and more investigation for system_ssd_cache/appdata found that some of child datasets was made snapshots/backup in random times but not all and not parent dataset.

In the script that used befor, it used : sanoid --take-snapshots

--take-snapshots is a forced snapshot mode.

It means:

- Sanoid always creates a snapshot

- for every dataset with autosnap=yes

- exactly at the time you run it (20:00)

- even if the dataset did NOT change

- even if the interval did NOT expire

- even if daily/weekly/monthly is not due

This is why:

✔ All snapshots were created at exactly 20:00

✔ All datasets had the same timestamp

✔ Backups ran immediately after

✔ Behavior was predictable and synchronized

This mode behaves like a cron job, not like an interval manager.

But in plugin use :

sanoid --cron

This mode is interval‑based, not time‑based.

Sanoid decides:

- whether hourly is expired

- whether daily is expired

- whether weekly is expired

- whether monthly is expired

- whether the dataset changed

- whether it should skip the snapshot

Snapshots are created:

- not at a fixed time

- but at the first cron run after the interval expires

- and only if the dataset changed (unless forced)

That seems much better Behavior of sanoid snapshots/Backups.

In any case maybe a good idea to add option for parametr :

noinconsistentsnapshot = yes

This forces Sanoid to create snapshots even if the dataset did not changed?

Also can't see syncoid snapshot/backup for any of datasets...

Edited May 17May 17 by Masterwishx

On 5/16/2026 at 4:21 PM, Pirat said:

My daily snapshots are usually taken between 23:30 and 00:15 for reference.

Do your snapshots for appdata all sub datasets have daily snapshots at every day?

And if you have flash snapshots maybe?

I have strange count of snapshots for appdata sub datasets from 15 to 20... (with old script snapshots).

So this mean after installed plugin it make snapshots not at every day for all subdatasets.

Also for flash it made only one time snapshot ...

Edited May 20May 20 by Masterwishx

From debug:

Filesystem system_cache_ssd/appdata/vaultwarden has:
     15 total snapshots (newest: 34.4 hours old)
          3 monthly
              desired: 3
              newest: 445.4 hours old, named autosnap_2026-05-01_20:00:04_monthly
          8 daily
              desired: 7
              newest: 34.4 hours old, named autosnap_2026-05-18_23:00:02_daily
          4 weekly
              desired: 4
              newest: 181.4 hours old, named autosnap_2026-05-12_20:00:18_weekly


Filesystem disk7/zfs_backups/system_cache_ssd_appdata/binhex-airsonic-advanced has:
     19 total snapshots (newest: 12.2 hours old)
          5 weekly
              desired: 4
              newest: 12.2 hours old, named autosnap_2026-05-19_21:15:01_weekly
          11 daily
              desired: 7
              newest: 12.2 hours old, named autosnap_2026-05-19_21:15:01_daily
          3 monthly
              desired: 3
              newest: 445.4 hours old, named autosnap_2026-05-01_20:00:03_monthly


Filesystem system_cache_ssd/appdata/semaphore has:
     19 total snapshots (newest: 0.2 hours old)
          5 weekly
              desired: 4
              newest: 0.2 hours old, named autosnap_2026-05-20_09:15:01_weekly
          11 daily
              desired: 7
              newest: 0.2 hours old, named autosnap_2026-05-20_09:15:01_daily
          3 monthly
              desired: 3
              newest: 445.4 hours old, named autosnap_2026-05-01_20:00:05_monthly


Filesystem system_cache_ssd/appdata/PuTTY has:
     17 total snapshots (newest: 20.7 hours old)
          3 monthly
              desired: 3
              newest: 445.4 hours old, named autosnap_2026-05-01_20:00:05_monthly
          9 daily
              desired: 7
              newest: 20.7 hours old, named autosnap_2026-05-19_12:45:01_daily
          5 weekly
              desired: 4
              newest: 20.7 hours old, named autosnap_2026-05-19_12:45:01_weekly

Filesystem system_cache_ssd/appdata/YouTrack has:
     21 total snapshots (newest: 15.7 hours old)
          12 daily
              desired: 7
              newest: 15.7 hours old, named autosnap_2026-05-19_17:45:01_daily
          6 weekly
              desired: 4
              newest: 15.7 hours old, named autosnap_2026-05-19_17:45:01_weekly
          3 monthly
              desired: 3
              newest: 445.4 hours old, named autosnap_2026-05-01_20:00:03_monthly

Hi, I have reported this issue on github, and thought I'd also post here in case anyone else has the same problem? I noticed that someone else reported a similar problem, but that issue is closed. Every time I reboot unRAID, I get this error:
2026-05-02 01:30:02: Sending backup failed. Error code 2. Full output: Host key verification failed.
2026-05-02 01:30:02: Host key verification failed.
2026-05-02 01:30:02: CRITICAL ERROR: ssh connection echo test failed for [email protected] with exit code 255

To fix it, I discovered that I need to re-paste my buddy's SSH key! Then it connects OK! Hoping you could look at this?

Thanks,
Tim

Unraid 7.3.1

"Sending backup failed. Error code 2. Full output: WARNING: ZFS resume feature not available on target machine - sync will continue without resume support.