There are many other working transfers on both machines in both directions using the same commands set. Please note that this problem is only present with ONE filesystem. Question is: Is there a way to clear the receive_resume_token attribute on target filesystem? (on target machine it is destpool/samplefs) On target machine, i get: srcpool/samplefs does not have any resumable receive state to abort On source machine, and: zfs recv -A 'destpool/samplefs'
I tried to clear that token by running: zfs recv -A 'srcpool/samplefs' This is not what i want, since some filesystems are very large and systems crashes are likely in this invironment. The only way to have it working is adding the "-no-resume" flag to syncoid command.
#ZPOOL SEND RESUME OPENZFS MANUAL#
If it finds one, it tries to retrieve the snapshot corresponding to that token on source machine: ssh sourceserver zfs send -t (token stored in receive_resume_token retrieved above) | (network stuff.) | zfs receive -s -F 'destpool/samplefs'Ĭannot resume send: used in the initial send no longer exists ZFS-SEND(8) FreeBSD System Managers Manual ZFS-SEND(8) NAME zfs-send - generate backup stream of ZFS dataset SYNOPSIS zfs send -DLPRbcehnpsvw -I-i. It complains it cannot resume a send/receive transactionĭuring normal operations, syncoid retrieves the receive_resume_token on target machine: /usr/local/sbin/zfs get -H receive_resume_token 'destpool/samplefs' Now, when I run syncoid on target server using: $
I manually created a new snapshot and successfully restored it on target.
I messed up with a snapshot on origin machine: one server panicked during a snapshot transfer and later I deleted the snapshot that was being transferred. I am using syncoid from sanoid project to create copies of ZFS filesystems on a different machine in my test environment (a couple of Raspberry Pi)
0 kommentar(er)
