going to submit a PR but posting this as a reminder.
if running with -r -c -s, and the send gets interrupted, the next time i start zfsbud it deletes the snapshot that needs to be resumed.
here is an example of killing a send and trying to resume while also sending -c. this command gets sent once, killed during tx, then resent:
/home/coolguy/zfsbud/zfsbud.sh -c -r -s dadfs/backup --rsh "ssh backerupper@10.0.0.2 -p22" deleteme/myds
Creating source snapshot: deleteme/myds@zfsbud_20250603144935
Deleting source snapshot: deleteme/myds@zfsbud_20250603143930
Most recent source snapshot: zfsbud_20250603144935
Most recent common snapshot: zfsbud_20250603144853
Sending incremental changes to destination...
^C
Creating source snapshot: deleteme/myds@zfsbud_20250603144942
Deleting source snapshot: deleteme/myds@zfsbud_20250603144935
cannot resume send: 'deleteme/myds@zfsbud_20250603144935' used in the initial send no longer exists
cannot receive: failed to read from stream
i think zfsbud wants me to resume an interrupted tx without -c but why not change the flow of the script to check for an existing token before creating a new snapshot and deleting the old one?
going to submit a PR but posting this as a reminder.
if running with
-r -c -s, and the send gets interrupted, the next time i start zfsbud it deletes the snapshot that needs to be resumed.here is an example of killing a send and trying to resume while also sending
-c. this command gets sent once, killed during tx, then resent:/home/coolguy/zfsbud/zfsbud.sh -c -r -s dadfs/backup --rsh "ssh backerupper@10.0.0.2 -p22" deleteme/mydsi think zfsbud wants me to resume an interrupted tx without
-cbut why not change the flow of the script to check for an existing token before creating a new snapshot and deleting the old one?