-
Notifications
You must be signed in to change notification settings - Fork 4
Data rescue scenarios and demos
This page discusses scenarios related to retrieval of SBX blocks (i.e. the blocks of the SBX container). Not all scenarios are designed to be realistic, they are designed to illustrate various techniques for you to pick and apply for your specific scenario.
Data rescue/repair is discussed in detail at General data rescue.
If the media is failing, please use proper imaging software to create a clone image first, as described in General data rescue page. DO NOT use blkar directly on failing media.
Suppose we have the disk image stored as disk.img, then we can simply do
mkdir rescued_data
blkar rescue disk.img rescued_data rescue.log
where rescued_data stores the rescued containers, and rescue.log is the log file allowing blkar to resume progress from interruption.
Demo: See the demo for Want to rescue SBX containers from disk image.
Since the partition table is intact, we can still rely on the partition names.
Assuming the corrupted file system occupies the partition /dev/sdb2, then we can use the following command for SBX blocks retrieval
blkar rescue /dev/sdb2 rescued_data
The retrieved SBX blocks are stored in the rescued_data directory
Demo: See the demo for Want to rescue SBX containers from disk image.
Similar to the above case, except we supply the disk directly for blkar to scan.
Assuming the disk is /dev/sdb, then we can execute
blkar rescue /dev/sdb rescued_data
Demo: See the demo for Want to rescue SBX containers from disk image.
Nothing prevents you from writing the SBX container directly into the medium, using command like
dd if=test.sbx of=/dev/sdb
As long as it's aligned (container starts at multiple of 128), then we can just rescue directly
blkar rescue /dev/sdb rescued_data
Demo: See demo for SBX container on disk image but off by some bytes (not aligned at sector sized blocks).
If the write is not aligned, e.g. you used some command like
dd if=test.sbx of/dev/sdb bs=1 seek=123 # off by 123 bytes
you can still use blkar to retrieve the SBX blocks by using both --from and --force-misalign flags
blkar rescue /dev/sdb rescued_data --from 123 --force-misalign
Say one appended disk image to a non-empty file accidentally, but stripping the first few bytes is too expensive to do as you need to create a new file essentially, so obviously it would be best if blkar can tackle misalignment issues
Similar to the above scenario's misaligned case, we can use the following command, assuming we're off by 123 bytes
blkar rescue disk.img rescued_data --from 123 --force-misalign
TODO - not really sure how UDF file system works, if you are familiar with UDF and would like to help, please get in touch with me via gitter, email, issue, PR etc
Say we started with a disk with 3 partitions of sizes 500GiB, 100GiB, 400GiB, and 500GiB unused space, and we are certain we only stored the SBX containers of interest in the second partition (100GiB). Unfortunately the partition table became corrupted, and we cannot point blkar to the partition directly. However, scanning the entire disk is a major waste of time, since only 100GiB of it may actually contain the SBX containers.
We can utilise --from and --to flags to aid us
blkar rescue disk.img rescued_data \
--from $[500 * 1024 * 1024 * 1024] \
--to $[600 * 1024 * 1024 * 1024]
--from and --to round down the number to closest multiple of 128 for alignment unless --force-misalign is supplied, so don't worry too much if the numbers provided are a bit off.
The demo uses a small disk image (~200MiB) rather than a 1.5 TB disk image, but demonstrates the same idea.
blkar handles Ctrl-C gracefully in all modes, including rescue mode. In particular, rescue mode can resume from interruption if you specified a log file to use in the runs (similar to ddrescue).
You can specify the log file to use as the third parameter, like
blkar rescue /dev/sdb rescued_data rescue.log
Note that there is no naming restriction on the log file, so feel free to call it whatever you want.
If rescue.log does not already exist, then blkar will create it and start logging progress into it.
If rescue.log already exists, then blkar will try to parse it and skip to the position recorded in the log file.
blkar updates the log file roughly once every second.
blkar rescue mode provides --only-pick-uid option which you can use pick the uid of the container blocks to look for
This is useful when you know the uid of the container of interest, and the medium has a bunch of other containers you don't care.
Say you know the uid is DEADBEEF0001, then you can use command like
blkar rescue disk.img rescued_data --only-pick-uid DEADBEEF0001
blkar rescue mode provides --only-pick-block option which you can use pick the type of the container blocks to look for. The type can be any, meta, or data.
So to pick only the metadata blocks to rescue, we can use the following command
blkar rescue disk.img rescued_data --only-pick-block meta