today i wanted to repartition my system, so i decide to back up the data with sending the existing data from all volumes with btrfs send to an external XFS formatted drive and saved the streams as files.
After repartitioning the drive, i wanted to restore my Files using btrfs receive, but it fails on an specific file which i do not need necessarily, but i can’t get any further as the receive stops immediately after hitting the crc32 error.
is there anything i can try to get past the crc32 error and try to recover the remaining data in the stream?
Edit: found the --max-errors option. Hope this will restore the rest of the file.
one lesson learned: run btrfs-receive --dump to test the file before deleting the source, as btrfs send does not verify it’s stream written to a file …
Sidenote: i think the corruption arises because the system went to standby during btrfs send so i expect that there is only one corrupted file in the stream. Keeping my fingers crossed…
Can you file a bug at RHBZ (you can use Fedora Account if you don’t already have an RHBZ account)?
Please include the btrfs-progs and kernel versions, and the exact btrfs send command used, and any messages it generated on the command line following wake from suspend.
And journalctl --no-hostname -o short-monotonic > journal.log
You can use -b flag to pick a prior boot if necessary.
I’m not sure the command can resume following wake from suspend, but it should report that the output file is incomplete due to the stream being interrupted.
The strange thing is that the btrfs send transfer continued normally when the computer was reactivated from standby: there were no warnings in the terminal, and the transfer exited without error. I think there was some sort of sync issue while transferring to the destination disk because my USB drive was connected to the integrated U3425WE monitor hub. Unfortunately, there are no logs as I did all the work from the F43 Live ISO. In general, though, GNOME should not go into standby mode while a command is being executed in a terminal, so I think i should better file a bug against Ptyxis, shouldn’t I?
I don’t have time to try to reproduce this issue at the moment, but I’m happy to do so in the next few weeks.
Destination Disk is XFS Formatted, the command i used was:
i think, this was my fault, i should better use the ‘-f’ option instead using the redirection of stdout to a file. And perhaps make use of protocol v2? i just saw in the man pages, that btrfs send defaults to proto v1.
Today i examined all the data loss and it turns out, that i’ve only lost Stream’s Compatdata and all my VM Disks - nothing serious.
>GNOME should not go into standby mode while a command is being executed in a terminal, so I think i should better file a bug against Ptyxis, shouldn’t I?
I’m not sure.
I think systemd-inhibit applies here, to allow the process to explicitly inhibit suspend/reboot/shutdown.
But if inhibit isn’t used then either the process resumes upon wake or it’s terminated. I don’t know the rules for that though.
