Hi, Michael
Btrfs send/receive can transfer incremental snapshots as well - you're
looking for the "-p" or "parent" parameter. On the other hand, it might
not be the right tool for the job.
If you're 100% happy with your old disk's *content*/layout/etc (just not
happy with the disk's reliability), try an overnight/over-weekend
ddrescue instead:
http://www.forensicswiki.org/wiki/Ddrescue
What I've done in the past is scripted ddrescue to recover as much data
as possible. Its like using dd between two disks except that it can keep
a log of bad sectors that can be retried later. The log also helps by
ensuring that if you cancel the operation, you can start it again and it
will continue where it left off.
Additionally, you can have it skip big sections of the disk when it
comes across bad sectors - and it can "trim" these sections on
subsequent runs.
Btrfs send/receive has the advantage that you can run it while your
system is still active. DDrescue has the advantage that it is very good
at recovering 99% of your data where a disk has lots of bad sectors.
For btrfs, send/receive the main subvolumes then, afterward,
send/receive the snapshots using the "parent" parameter, "-p". There
*is* the possibility that this needs to be reversed - as in, the backup
should be treated as the parent instead of the other way around:
btrfs send /home | btrfs receive /mnt/new-disk/home
btrfs send -p /home /backups/home-2014-04-08 | btrfs receive
/mnt/new-disk/backups/.
____
Below is from the last scriptlet I made when I last did the ddrescue
route (in that case I was recovering a failing NTFS drive). It was
particularly bad and took a whole weekend to recover. The new disk
worked flawlessly however. :)
How I've used ddrescue in the past is to connect the failing and new
disk to a server. Alternatively, using USB, you could boot from a rescue
CD/flash drive and do the rescue there.
a) Identify the disks in /dev/disk/by-<whatever-you-choose> and put
those values into the bash script below. ensure that it refers to the
disk as a whole (not a partition for example). This ensures that
re-ordering of the drives after a reboot won't affect the process.
b) Set up a log file location on a separate filesystem - a flash drive
is ideal unless you've gone the "server" route, where I normally just
put the log into a path on the the server as so:
/root/brendan-laptop.recovery.log
#!/bin/bash
src_disk=/dev/disk/by-id/ata-ST3250410AS_6RYF5NP7
dst_disk=/dev/disk/by-id/ata-ST3500418AS_9VM2ZZQS
#log=/path/to/log
log=~/brendan-laptop.recovery.log
#Sector size (default is 512 - newer disks should probably be 4096)
sector_size=4096
#Force writing to a block device - disable if you're backing up to an
image file
#force=""
force="-f"
# We want to skip bigger chunks to get as much data as possible before
the source disk really dies
# For the same reason, we also want to start with (attempting) to
maintain a high read rate
#Minimum read rate in MB/s before skipping
min_readrate=10485760
#Default skip size is 64k.
for skip_size in 65536 16384; do
#Going forward
ddrescue -r 1 -a $min_readrate -b $sector_size -d $force -K $skip_size
$src_disk $dst_disk $log
#Going in reverse
ddrescue -r 1 -a $min_readrate -b $sector_size -d $force -K $skip_size
-R $src_disk $dst_disk $log
done
#Default skip size is 64k.
#This time re-trying all failed/skipped sections
for skip_size in 4096; do
#Going forward
ddrescue -r 1 -a $min_readrate -b $sector_size -d $force -K $skip_size
-A $src_disk $dst_disk $log
#Going in reverse
ddrescue -r 1 -a $min_readrate -b $sector_size -d $force -K $skip_size
-R -A $src_disk $dst_disk $log
done
#Default skip size is 64k.
for skip_size in 1024 256 64 ; do
#Going forward
ddrescue -r 1 -b $sector_size -d $force -K $skip_size $src_disk
$dst_disk $log
#Going in reverse
ddrescue -r 1 -b $sector_size -d $force -K $skip_size -R $src_disk
$dst_disk $log
done
echo "Done. Run an chkdsk/fsck/whatever-might-be appropriate for the new
disk's filesystem(s)"
On 10/04/14 15:21, Michael Schuerig wrote:
SMART indicates that my notebook disk may soon be failing (an
unreadable/uncorrectable sector), therefore I intend to exchange it. The
disk contains a single btrfs filesystem with several nested(!)
subvolumes, each with several read-only snapshots in a .snapshots
subdirectory.
As far as I can tell, btrfs currently does not offer a sensible way to
duplicate the entire contents of the old disk onto a new one. I can use
cp, rsync, or send/receive to copy the "main" subvolumes. But unless I'm
missing something obvious, the snapshots are effectively lost. btrfs
send optionally takes multiple clone sources, but I've never seen an
example of its usage.
If that's what "experimental" means, I'm willing to accept it. However,
I'd like to emphasize that there's still something missing. Of course,
most of all I'd like to be proved wrong.
Michael
--
__________
Brendan Hide
http://swiftspirit.co.za/
http://www.webafrica.co.za/?AFF1E97
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
