I have a damaged hard disk with a lot of read errors. I'm currently doing a btrfs replace, but after 24 hours at just over 5% done, this is a problem: it's my work computer; I'm currently booted onto a Live USB, but I need to go back to the existing Ubuntu to continue my work (it has a really hard time booting in with all the read errors, but is able to make it sometimes).
Note: the entire hard disk, or at least this partition of it, curently reads at ~500 KBps, even when there aren't read errors – the btrfs replace status currently reports 0 read errors.
So I have two options:
1) just shut down, reboot into the other OS, and try to run the same btrfs replace start command I first ran.
2) cancel the current replace operation, which may take forever (I already tried a cancel before, a minute into the replace, and it seemed to take just as long to cancel) and would undo a day's hard-earned transfer progress.
3) admit defeat and just settle into this LiveUSB OS for the next 2-3 weeks and pray that the cleaning people don't bump the USB stick.
Best Answer
Reviving this question because it's the top Google result when searching for "btrfs replace resume" and the existing answer doesn't tell the whole story.
The replace process automatically resumes after a reboot (much like a balance). I've even had to do a hard-reset during a replace operation and the process happily continued after rebooting and remounting the filesystem. So my guess is that it wasn't the interrupted replace operation itself that gave sssheridan all these problems, but rather the circumstances of having to boot from a dying harddisk.
When mounting after an interrupted replace, a log-line like this is printed:
The last number is the completion percentage.