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' For an overview of creating and managing ZFS storage pools see the. See zfs (8) for information on managing datasets.
All datasets within a storage pool share the same space. A storage pool is a collection of devices that provides physical storage and data replication for ZFS datasets. I tried to clear that token by running: zfs recv -A 'srcpool/samplefs' The zpool command configures ZFS storage pools. 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. 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 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)
