Hi Gordon, I'm quite sure this is not a good idea. I do understand, that dd-ing a running system will miss some changes done to the file system while copying. I'm surprised that I didn't end up with some corrupted files, but with no files at all. Also, I'm not interested in restoring the old Suse 13.2 system. I just want some configuration files from it.
Cheers, Michael Am 30.01.2017 um 23:24 schrieb GWB: > << > Hi btrfs experts. > > Hereby I apply for the stupidity of the month award. >>> > > I have no doubt that I will will mount a serious challenge to you for > that title, so you haven't won yet. > > Why not dd the image back onto the original partition (or another > partition identical in size) and see if that is readable? > > My limited experience with btrfs (I am not an expert) is that read > only snapshots work well in this situation, but the initial hurdle is > using dd to get the image back onto a partition. So I wonder if you > could dd the image back onto the original media (the hd sdd), then > make a read only snapshot, and then send the snapshot with btrfs send > to another storage medium. With any luck, the machine might boot, and > you might find other snapshots which you may be able to turn into read > only snaps for btrfs send. > > This has worked for me on Ubuntu 14 for quite some time, but luckily I > have not had to restore the image file sent from btrfs send yet. I > say luckily, because I realise now that the image created from btrfs > send should be tested, but so far no catastrophic failures with my > root partition have occurred (knock on wood). > > dd is (like dumpfs, ddrescue, and the bsd variations) good for what it > tries to do, but not so great on for some file systems for more > intricate uses. But why not try: > > dd if=imagefile.dd of=/dev/sdaX > > and see if it boots? If it does not, then perhaps you have another > shot at the one time mount for btrfs rw if that works. > > Or is your root partition now running fine under Suse 14.2, and you > are just looking to recover a file files from the image? If so, you > might try to dd from the image to a partition of original size as the > previous root, then adjust with gparted or fpart, and see if it is > readable. > > So instead of trying to restore a btrfs file structure, why not just > restore a partition with dd that happens to contain a btrfs file > structure, and then adjust the partition size to match the original? > btrfs cares about the tree structures, etc. dd does not. > > What you did is not unusual, and can work fine with a number of file > structures, but the potential for disaster with dd is also great. The > only thing I know of in btrfs that does a similar thing is: > > btrfs send -f btrfs-send-image-file /mount/read-write-snapshot > > Chances are, of course, good that without having current backups dd > could potentially ruin the rest of your file system set up, so maybe > transfer the image over to another machine that is expendable and test > this out. I use btrfs on root and zfs for data, and make lots of > snapshots and send them to incremental backups (mostly zfs, but btrfs > works nicely with Ubuntu on root, with the occasional balance > problem). > > If dd did it, dd might be able to fix it. Do that first before you > try to restore btrfs file structures. > > Or is this a terrible idea? Someone else on the list should say so if > they know otherwise. > > Gordon -- 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
