Data rescue scenarios and demos

Purpose

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 in another page.

DO NOT use blkar on failing media directly

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.

SBX container stored in supported file system, file system became corrupted

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

SBX container stored in supported file system, partition table became corrupted or wiped

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

SBX container written into disk directly using tools like dd

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

If it's not aligned, e.g. you used some command like

dd if=test.sbx of/dev/sdb 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

SBX container on disk image but off by 7 bytes (not aligned at sector sized blocks)

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

blkar rescue /dev/sdb rescued_data --from 7 --force-misalign

SBX container on CD/DVD/Blu-rays (UDF file system)

TODO

SBX container is certain to be in some range of the image, want to avoid scanning the entire disk

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 /dev/sdb 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.

Resuming from interruptions

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

Only want to check if image has SBX containers by scanning for just one metadata block

blkar show mode can scan file and block devices, so you can point blkar to the disk you want to scan, similar to rescue mode. By default, show mode stops after finding one metadata block.

blkar show /dev/sdb

blkar show mode also provides --from, --to, and --force-misalign options which behave exactly same as the ones in rescue mode

Only want to rescue SBX container of certain uid

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 /dev/sdb rescued_data --only-pick-uid DEADBEEF0001

Only want to rescue all metadata blocks just to survey the containers that are stored

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 /dev/sdb rescued_data --only-pick-block meta

Only want to index all SBX containers by scanning all metadata blocks

blkar show mode can be configured to show all metadata blocks instead of stopping after one by supplying --show-all flag

blkar show /dev/sdb --show-all > show.log

Only want to index all SBX containers by scanning all metadata blocks, but in JSON

All modes in blkar support JSON output mode, including show mode

So we can just add the flag to the command used above

blkar show /dev/sdb --show-all --json > show.json