Hi All,
I use syncoid to replicate a pool to a second machine. The send is raw. however when i am rebooting my system while a send is taking place it wont resume… it fails when i rerun syncoid.
i dont use --no-resume so that is not the problem. the command i use with syncoid is:
/usr/sbin/syncoid --source-bwlimit=80M --sendoptions=“wLecpR” --pv-options=“-pterbf” --no-sync-snap --no-clone-handling --no-privilege-elevation --create-bookmark --sshport=2222 examplepool root@server:examplepool
anybody knows why it wont resume? now when i dont think about it and reboot while syncoid is running i need to resync from scratch…
You actually might want to try --no-resume as a mitigation while (or instead of) you figure that out. That argument prevents Sanoid from attempting to use ZFS’s resume feature, but that doesn’t mean your synchronization won’t pick right up again–it just means it picks up from the most recent fully replicated snapshot, rather than from a partially replicated snapshot.
Say you run syncoid --no-resume on a dataset with 50 snapshots, and it craps out in the middle of the 26th snapshot. When syncoid --no-resume runs again, with the exact same command syntax, it begins again at the start of the 26th snapshot. So you’re not technically “resuming” in the sense of the zfs send and receive commands, but you are definitely “resuming” in the sense of picking your replication effort back up from essentially where you left off the last time.
Hi,
It wont work. Even with the --no-resume. The output of syncoid is
Sep 05 07:41:52 ESX syncoid[3783532]: warning: cannot send ‘incuspool/incus/virtual-machines/firewall.block@autosnap_2025-09-05_07:00:19_hourly’: signal received
Sep 05 07:41:52 ESX syncoid[3783532]: cannot send ‘incuspool’: I/O error
Sep 05 07:41:52 ESX syncoid[3783358]: WARN: resetting partially receive stateSep 05 07:41:52 ESX syncoid[3783386]: ‘incuspool/backup_esx_incuspool’ does not have any resumable receive state to abort
Sep 05 07:41:52 ESX syncoid[3783358]: CRITICAL ERROR: ssh -p 2222 -S /tmp/syncoid-root@backupserver-1757050859-1726 root@backupserver zfs receive -A
‘’“'”‘incuspool/backup_esx_incuspool’“'”‘’ failed: 256 at /usr/sbin/syncoid line 2177.
Sep 05 07:41:52 ESX systemd[1]: syncoid.service: Main process exited, code=exited, status=1/FAILURE
Sep 05 07:41:52 ESX systemd[1]: syncoid.service: Failed with result ‘exit-code’.
Sep 05 07:41:52 ESX systemd[1]: Failed to start syncoid.service - replicate ZFS filesystems.
Sep 05 07:41:52 ESX systemd[1]: syncoid.service: Consumed 1min 13.457s CPU time, 46.4M memory peak.
Ps the command i use for syncoid is
/usr/sbin/syncoid --no-resume --source-bwlimit=80M --sendoptions=“wLecpR” --pv-options=“-pterbf” --no-sync-snap --no-clone-handling --no-privilege-elevation --create-bookmark --sshport=2222 incuspool root@backupserver:incuspool/backup_esx_incuspool
zpool status incuspool, please. Sure looks like you’ve got on-disk corruption, and that’s why you can’t replicate.
I have no disk corruption.Already checked this. i recreated the pool. and it is syncing again. It only happens when the sync is stopped because of a reboot for example. When o try to sync after the reboot it errors out with the error above.
Here is the pool output.
root@backupserver:~# zpool status -t
pool: incuspool
state: ONLINE
scan: resilvered 1.78T in 15:17:46 with 0 errors on Sat Aug 30 05:23:57 2025
config:
NAME STATE READ WRITE CKSUM
incuspool ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ata-PNY_2TB_SATA_SSD_PNB12258005500200298-part5 ONLINE 0 0 0 (100% trimmed, completed at Sun Sep 7 00:29:37 2025)
ata-PNY_2TB_SATA_SSD_PNB20255015930100168-part5 ONLINE 0 0 0 (100% trimmed, completed at Sun Sep 7 00:29:56 2025)
mirror-1 ONLINE 0 0 0
ata-PNY_2TB_SATA_SSD_PNB12257009060100417-part5 ONLINE 0 0 0 (100% trimmed, completed at Sun Sep 7 00:29:56 2025)
ata-PNY_2TB_SATA_SSD_PNB20255015930100170-part5 ONLINE 0 0 0 (100% trimmed, completed at Sun Sep 7 00:29:50 2025)
errors: No known data errors
pool: rpool
state: ONLINE
scan: resilvered 4.39G in 00:00:26 with 0 errors on Fri Aug 29 14:05:47 2025
config:
NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ata-PNY_2TB_SATA_SSD_PNB12258005500200298-part4 ONLINE 0 0 0 (100% trimmed, completed at Sun Sep 7 00:25:26 2025)
ata-PNY_2TB_SATA_SSD_PNB20255015930100168-part4 ONLINE 0 0 0 (100% trimmed, completed at Sun Sep 7 00:25:32 2025)
mirror-1 ONLINE 0 0 0
ata-PNY_2TB_SATA_SSD_PNB12257009060100417-part4 ONLINE 0 0 0 (100% trimmed, completed at Sun Sep 7 00:25:48 2025)
ata-PNY_2TB_SATA_SSD_PNB20255015930100170-part4 ONLINE 0 0 0 (100% trimmed, completed at Sun Sep 7 00:25:33 2025)
errors: No known data errors
I hear you, but ZFS send is dying. That’s not a syncoid issue, it’s either an issue on your system (eg corruption, hardware errors, etc) or a bug in ZFS itself.
If you run syncoid with --debug it will show you the actual commands it’s running. Try running the exact same ZFS send comand, but piping it through pv to dev/null instead of across an SSH tunnel.