Testing file system repair attempts on a read-only disk image
I recently got a damaged HFS+ formatted volume for analysis and repair.
Now I did what has to be done first on all data recovery attempts, obviously: Create a dd Disk image from the disk before messing around with it.
As the volume was very large, it would cost a lot of time and disk space to always make a copy of the image, mess around with it and if it fails, restore the original image. Copying around terabytes of data on a slow medium like classic harddisks is taking a lot of time, after all.
So I was searching for a way to operate on a snapshot-overlay of the original image to mess around with it and just dump the snapshot and revert, if something goes wrong.
Fortunately, I found this Stackoverflow post, which describes a way to do what I want.
So here is a little mount script mount_ovl.sh:
#!/bin/sh if [ $# -eq 0 ]; then echo Usage: $0 ro-device \[overlay-size\] echo i.e.: $0 /dev/loop0 exit fi if [ ! -e $1 ]; then echo $1 does not exist exit fi if [ -z "$2" ]; then ovlsz=10G else ovlsz=$2 fi ovl=/tmp/ovl newdevname=ovldev truncate -s$ovlsz $ovl size=$(blockdev --getsz "$1") loop=$(losetup -f --show -- "$ovl") echo "0 $size snapshot $1 $loop P 8" | dmsetup create "$newdevname" echo Mounted $loop to $newdevname
So, to i.e. do a fsck.hfsplus without ruining the original image, I first create a loopf device of the disk image:
# losetup -P /dev/loop0 /mnt/winhexraw.dd
Let’s list the partitions that it autodetected with -P:
# fdisk -lu /dev/loop0 Disk /dev/loop0: 931,5 GiB, 1000170586112 bytes, 1953458176 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: B9D171AA-7F12-4DD2-B1BD-FAE6A14B1DA8 Device Start End Sectors Size Type /dev/loop0p1 40 409639 409600 200M EFI System /dev/loop0p2 409640 1953195991 1952786352 931,2G Apple HFS/HFS+
So /dev/loop0p2 is the partition that needs to be checked.
Now mount it R/W with the script to /dev/mapper/ovldev:
./mount_ovl.sh /dev/loop0p2
Now it can be i.e. checked with
fsck.hfsplus -f /dev/mapper/ovldev
and possibly fixed. In my case, file system was damaged and fsck was unable to fix it, so I finally resorted to HFS+ rescue to get the files off from it. But this little hint can still be useful for futher attempts to i.e. repair the filesystem by hand.
To drop the snapshot again, assuming that it got mounted to /dev/loop1:
dmsetup remove "ovldev" losetup -d /dev/loop1
And to release original loop device for disk image:
losetup -d /dev/loop0
Might become handy some day.