Syncoid Issue: cannot restore to snapshot_18:00:03_hourly: destination already exists

Hey everyone

I’ve been setting up syncoid on a fresh install of proxmox 9.1.4 (zfs-2.3.4-pve1) with Sanoid/Syncoid (2.2.0) and ran into a “destination already exists” error.
The server has two exos 16 TB HDDs, with one having the dataset tank and the other tank-backup. The rationale behind it is to take snapshots to roll back if necessary, replicating to the second HDD as internal backup if the first harddisk fails, as well as to two additional 16 TB exos on the backup server for remote backup.

├── homeserver
│   ├── HDD1
│   │   └── tank
│   └── HDD2
│       └── tank-backup (internal backup)
│
└── backupserver (1Gbit connection)
    ├── HDD1
    │   └── backupserver-tank-backup-1 (external backup)
    └── HDD2
        └── backupserver-tank-backup-2 (external backup)

This issue arises so far only for the internal backup. The external backup is done via a user that has zfs allow send,hold which so far worked, whereas the internal backup is done with root. Sanoid is set as shown below, pruning being the same for tank and tank-backup, autosnap being deactivated for tank-backup. All datasets are encrypted, tank has the key loaded, tank-backup not.

I’m not quite sure where to pinpoint the issue to. I tried so far:

  • explicitly giving root receive,create,destroy,rollback,hold,release for the datasets in question
  • set tank-backup to readonly
  • adjust the syncoid.servie to set a flock in case multiple runs were the issue
  • staggered the timing compared to sanoid snapshotting
  • –no-privilege-elevation tag (in unisono with explicitly zfs allow what the user can do, in this case everything)

The manual solution is destroying the destination snapshot that causes the error, resetting the service and manually run it.

The only difference I have not yet tried on the main host compared to the backupserver is adding --recvoptions=“u”. There are in total four datasets that are synced this way, the one that created the least problem is tank/appdata/photos, which serves as storage for a photo-owncloud instance (and thus sees regular changes), the others are for immich and owncloud-data, both services have not yet been set up.

Thanks a lot for any inputs or suggestions!

### zfs datasets in question
tank/backups/pbs-config            14.1M  9.44T  8.80M  /tank/backups/pbs-config
tank/backups/pve-config            30.9M  9.44T  23.7M  /tank/backups/pve-config
tank-backup/backups/pbs-config     13.6M  9.44T  8.77M  none
tank-backup/backups/pve-config     30.7M  9.44T  23.7M  none
### systemctl status syncoid-config-backups.service

× syncoid-config-backups.service - Syncoid replicate config backup datasets
     Loaded: loaded (/etc/systemd/system/syncoid-config-backups.service; static)
     Active: failed (Result: exit-code) since Fri 2026-02-20 07:41:35 CET; 37s ago
 Invocation: 3297e23ba82b457894d81c0d4953fea7
TriggeredBy: ● syncoid-config-backups.timer
    Process: 967546 ExecStart=/usr/sbin/syncoid --no-sync-snap --create-bookmark --sendoptions=w --delete-target-snapshots tank/backups/pve-config tank-backup/backups/pve>
    Process: 967800 ExecStart=/usr/sbin/syncoid --no-sync-snap --create-bookmark --sendoptions=w --delete-target-snapshots tank/backups/pbs-config tank-backup/backups/pbs>
   Main PID: 967800 (code=exited, status=2)
   Mem peak: 18M
        CPU: 945ms

Feb 20 07:41:34 homeserver syncoid[967635]: mbuffer: warning: HOME environment variable not set - unable to find defaults file
Feb 20 07:41:35 homeserver syncoid[967546]:  zfs destroy 'tank-backup/backups/pve-config'@autosnap_2026-02-20_06:00:15_hourly failed: could not find any snapshots to dest>
Feb 20 07:41:35 homeserver syncoid[967800]: NEWEST SNAPSHOT: autosnap_2026-02-20_06:00:15_hourly
Feb 20 07:41:35 homeserver syncoid[967800]: Sending incremental tank/backups/pbs-config@autosnap_2026-02-19_17:00:09_hourly ... autosnap_2026-02-20_06:00:15_hourly (~ 72 >
Feb 20 07:41:35 homeserver syncoid[967832]: mbuffer: warning: HOME environment variable not set - unable to find defaults file
Feb 20 07:41:35 homeserver syncoid[967829]: cannot restore to tank-backup/backups/pbs-config@autosnap_2026-02-19_18:00:03_hourly: destination already exists
Feb 20 07:41:35 homeserver syncoid[967800]: CRITICAL ERROR:  zfs send -w  -I 'tank/backups/pbs-config'@'autosnap_2026-02-19_17:00:09_hourly' 'tank/backups/pbs-config'@'au>
Feb 20 07:41:35 homeserver systemd[1]: syncoid-config-backups.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
Feb 20 07:41:35 homeserver systemd[1]: syncoid-config-backups.service: Failed with result 'exit-code'.
Feb 20 07:41:35 homeserver systemd[1]: Failed to start syncoid-config-backups.service - Syncoid replicate config backup datasets.
### cat syncoid-config-backups.service 

[Unit]
Description=Syncoid replicate config backup datasets

[Service]
Type=oneshot
ExecStart=/usr/sbin/syncoid --no-sync-snap --create-bookmark --sendoptions="w" --delete-target-snapshots tank/backups/pve-config tank-backup/backups/pve-config
ExecStart=/usr/sbin/syncoid --no-sync-snap --create-bookmark --sendoptions="w" --delete-target-snapshots tank/backups/pbs-config tank-backup/backups/pbs-config
### cat syncoid-config-backups.timer 

[Unit]
Description=Daily syncoid replication for config backups

[Timer]
OnCalendar=*-*-* 01:20:00
Persistent=true
RandomizedDelaySec=120
Unit=syncoid-config-backups.service

[Install]
WantedBy=timers.target
### Sanoid.conf excerpts (runs every 15 min)
[template_config]
        autosnap = yes
        autoprune = yes
        hourly = 0
        daily = 60
        weekly = 16
        monthly = 12
        yearly = 2

[template_backupconfig]
        autosnap = no
        autoprune = yes
        hourly = 0
        daily = 60
        weekly = 16
        monthly = 12
        yearly = 2

[tank/backups/pve-config]
        use_template = template_config

[tank/backups/pbs-config]
        use_template = template_config

[tank-backup/backups/pve-config]
        use_template = template_backupconfig

[tank-backup/backups/pbs-config]
        use_template = template_backupconfig
`# snapshots present at the time of error, truncated

=== SOURCE === -> tank for dataset tank/backups/pbs-config
(truncated)
tank/backups/pbs-config@autosnap_2026-02-19_16:00:02_hourly
tank/backups/pbs-config@autosnap_2026-02-19_17:00:09_hourly
tank/backups/pbs-config@autosnap_2026-02-19_18:00:03_hourly
tank/backups/pbs-config@autosnap_2026-02-19_19:00:15_hourly
tank/backups/pbs-config@autosnap_2026-02-19_20:00:14_hourly
tank/backups/pbs-config@autosnap_2026-02-19_21:00:16_hourly
tank/backups/pbs-config@autosnap_2026-02-19_22:00:03_hourly
tank/backups/pbs-config@autosnap_2026-02-19_23:00:16_hourly
tank/backups/pbs-config@autosnap_2026-02-20_00:00:22_daily
tank/backups/pbs-config@autosnap_2026-02-20_00:00:22_hourly
tank/backups/pbs-config@autosnap_2026-02-20_01:00:01_hourly
tank/backups/pbs-config@autosnap_2026-02-20_02:00:01_hourly
tank/backups/pbs-config@autosnap_2026-02-20_03:00:00_hourly
tank/backups/pbs-config@autosnap_2026-02-20_04:00:01_hourly
tank/backups/pbs-config@autosnap_2026-02-20_05:00:01_hourly
tank/backups/pbs-config@autosnap_2026-02-20_06:00:15_hourly
=== DEST === -> tank-backup for dataset tank/backups/pbs-config
(truncated)
tank-backup/backups/pbs-config@autosnap_2026-02-19_16:00:02_hourly
tank-backup/backups/pbs-config@autosnap_2026-02-19_17:00:09_hourly
tank-backup/backups/pbs-config@autosnap_2026-02-19_18:00:03_hourly <== Seems to be the issue?
tank-backup/backups/pbs-config@autosnap_2026-02-19_19:00:14_hourly
tank-backup/backups/pbs-config@autosnap_2026-02-19_20:00:14_hourly
tank-backup/backups/pbs-config@autosnap_2026-02-19_21:00:16_hourly
tank-backup/backups/pbs-config@autosnap_2026-02-19_22:00:03_hourly
tank-backup/backups/pbs-config@autosnap_2026-02-19_23:00:16_hourly
tank-backup/backups/pbs-config@autosnap_2026-02-20_00:00:23_daily
tank-backup/backups/pbs-config@autosnap_2026-02-20_00:00:23_hourly
tank-backup/backups/pbs-config@autosnap_2026-02-20_01:00:01_hourly
tank-backup/backups/pbs-config@autosnap_2026-02-20_02:00:01_hourly
tank-backup/backups/pbs-config@autosnap_2026-02-20_03:00:01_hourly
tank-backup/backups/pbs-config@autosnap_2026-02-20_04:00:00_hourly
tank-backup/backups/pbs-config@autosnap_2026-02-20_05:00:01_hourly
tank-backup/backups/pbs-config@autosnap_2026-02-20_06:00:16_hourly
=== SOURCE === -> tank for dataset tank/backups/pve-config
(truncated)
tank/backups/pve-config@autosnap_2026-02-19_16:00:02_hourly
tank/backups/pve-config@autosnap_2026-02-19_17:00:09_hourly
tank/backups/pve-config@autosnap_2026-02-19_18:00:02_hourly
tank/backups/pve-config@autosnap_2026-02-19_19:00:14_hourly
tank/backups/pve-config@autosnap_2026-02-19_20:00:15_hourly
tank/backups/pve-config@autosnap_2026-02-19_21:00:15_hourly
tank/backups/pve-config@autosnap_2026-02-19_22:00:02_hourly
tank/backups/pve-config@autosnap_2026-02-19_23:00:16_hourly
tank/backups/pve-config@autosnap_2026-02-20_00:00:22_daily
tank/backups/pve-config@autosnap_2026-02-20_00:00:22_hourly
tank/backups/pve-config@autosnap_2026-02-20_01:00:01_hourly
tank/backups/pve-config@autosnap_2026-02-20_02:00:00_hourly
tank/backups/pve-config@autosnap_2026-02-20_03:00:01_hourly
tank/backups/pve-config@autosnap_2026-02-20_04:00:01_hourly
tank/backups/pve-config@autosnap_2026-02-20_05:00:00_hourly
tank/backups/pve-config@autosnap_2026-02-20_06:00:16_hourly
=== DEST ===-> tank for dataset tank/backups/pve-config
(truncated)
tank-backup/backups/pve-config@autosnap_2026-02-19_16:00:02_hourly
tank-backup/backups/pve-config@autosnap_2026-02-19_17:00:09_hourly
tank-backup/backups/pve-config@autosnap_2026-02-19_18:00:02_hourly
tank-backup/backups/pve-config@autosnap_2026-02-19_19:00:14_hourly
tank-backup/backups/pve-config@autosnap_2026-02-19_20:00:15_hourly
tank-backup/backups/pve-config@autosnap_2026-02-19_21:00:15_hourly
tank-backup/backups/pve-config@autosnap_2026-02-19_22:00:02_hourly
tank-backup/backups/pve-config@autosnap_2026-02-19_23:00:16_hourly
tank-backup/backups/pve-config@autosnap_2026-02-20_00:00:22_daily
tank-backup/backups/pve-config@autosnap_2026-02-20_00:00:22_hourly
tank-backup/backups/pve-config@autosnap_2026-02-20_01:00:01_hourly
tank-backup/backups/pve-config@autosnap_2026-02-20_02:00:00_hourly
tank-backup/backups/pve-config@autosnap_2026-02-20_03:00:01_hourly
tank-backup/backups/pve-config@autosnap_2026-02-20_04:00:01_hourly
tank-backup/backups/pve-config@autosnap_2026-02-20_05:00:00_hourly
tank-backup/backups/pve-config@autosnap_2026-02-20_06:00:16_hourly`

Any idea why this part is happening?

zfs destroy 'tank-backup/backups/pve-config'@autosnap_2026-02-20_06:00:15_hourly failed: could not find any snapshots to dest...

I have narrowed it down to the autosnap functionality. So far, I have manually upgraded to version 2.3.0 and created the default conf file in /etc/sanoid, where again autosnap is set to 1 (yes). This has caused the same error also in the new version, while when setting it to 0 (no), it does not appear (this causes no snapshots to be taken though (!)).

What I think the problem comes from is that when autosnapping is turned on, it autosnaps the tank datasets, but also the tank-backup. So it transfers the snapshot from tank to tank-backup, but there it finds a similar snapshot with just a few seconds difference and throws this error. Setting autosnap = no in the templates for the tank-backup sanoid conf apparently does nothing, it might be overwritten somewhere downstream to the value that is input by the default config.

I would not be surprised if there is some sort of regex issue in sanoid that confused tank and tank-backup, but unfortunately I’m not familiar enough with sanoid to confirm.

I recently fixed a similar issue in syncoid that was confusing backuppool and pool. You may try to report the issue in github and see if anyone there can help, or fix the issue.

It sounds like you applied the same template to both your source and target, but you only showed us snippets of templates in your sanoid.conf, and not to what each of those templates is applied, so all I can do is spitball.

You should not be taking snapshots on targets, only on sources. That’s why sanoid ships with production AND backup templates.

Here is the sanoid.conf that has caused me problems:

### cat sanoid.conf 
[template_appdata_fast]
        autosnap = yes
        autoprune = yes
        hourly = 24
        daily = 30
        weekly = 8
        monthly = 6
        yearly = 2

[template_appdata_slow]
        autosnap = yes
        autoprune = yes
        hourly = 4
        daily = 60
        weekly = 16
        monthly = 12
        yearly = 3

[template_config]
        autosnap = yes
        autoprune = yes
        hourly = 0
        daily = 60
        weekly = 16
        monthly = 12
        yearly = 2

[template_backupappdata_fast]
        autosnap = no
        autoprune = yes
        hourly = 24
        daily = 30
        weekly = 8
        monthly = 6
        yearly = 2

[template_backupappdata_slow]
        autosnap = no
        autoprune = yes
        hourly = 4
        daily = 60
        weekly = 16
        monthly = 12
        yearly = 3

[template_backupconfig]
        autosnap = no
        autoprune = yes
        hourly = 0
        daily = 60
        weekly = 16
        monthly = 12
        yearly = 2

[tank/appdata/owncloud-data]
        use_template = template_appdata_fast
        recursive = yes

[tank/appdata/immich-data]
        use_template = template_appdata_fast
        recursive = yes

[tank/appdata/photos]
        use_template = template_appdata_slow
        recursive = yes

[tank/backups/pve-config]
        use_template = template_config

[tank/backups/pbs-config]
        use_template = template_config

[tank-backup/appdata/owncloud-data]
        use_template = template_backupappdata_fast
        recursive = yes

[tank-backup/appdata/immich-data]
        use_template = template_backupappdata_fast
        recursive = yes

[tank-backup/appdata/photos]
        use_template = template_backupappdata_slow
        recursive = yes

[tank-backup/backups/pve-config]
        use_template = template_backupconfig

[tank-backup/backups/pbs-config]
        use_template = template_backupconfig

On the backupserver, autosnap is turned off for all templates. I tried now to turn off autosnap in the defaults conf and that has prevented the issue to arise on it. This works there because there is no “original” data but only copies. However, I then tried changing the autosnap = 0 on the main server, which has turned off autosnapping entirely, also for the ones that specifically have autosnap turned on.
Turning this logic around, I removed the target tank-backup datasets on the main server and left only the tank datasets. They are now now pruned anymore, but the issue went away as well.
So lastly, I defined the autosnapping directly in for the dataset itself:

[tank-backup/appdata/owncloud-data]
        use_template = template_backupappdata_fast
        recursive = yes
        autosnap = 0

[tank-backup/appdata/immich-data]
        use_template = template_backupappdata_fast
        recursive = yes
        autosnap = 0

[tank-backup/appdata/photos]
        use_template = template_backupappdata_slow
        recursive = yes
        autosnap = 0

[tank-backup/backups/pve-config]
        use_template = template_backupconfig
        autosnap = 0

[tank-backup/backups/pbs-config]
        use_template = template_backupconfig
        autosnap = 0

And the issue is gone now.

I suspect two possibilities:

  1. sanoid.default.conf autosnap = 1 overwrites the sanoid.conf template setting somewhere;
  2. sanoid.conf template autosnap = 0 is not applied correctly, whereas the dataset-defined one is.

For now, it seems that the issue is solved. But I now wonder if autoprune = yes works at all.

Of course it does. Pruning is nearly as important as taking the snapshots in the first place.

You have datasets on “tank-backup” using your “config” template, which has autosnap enabled.

You might be better off just using the provided templates. It doesn’t look like there’s anything all that special that you’re trying to do with the custom templates that you created and are having trouble figuring out.