Does UrBackup provide a documented, supported way with an exact tool/version and command to read a specified logical sector (in particular, an NTFS volume’s BPB-declared backup boot sector) directly from a .vhdxz image without restoring or fully decompressing the image, and without modifying the backup? If so, how do the image’s compressed/sparse layout and logical offsets map to the requested NTFS sector, and what output confirms the operation is read-only and performs no repair? If not, is there another supported source-side inspection method? Thank you.
There is no documented tool for reading a single sector, but on a Linux server you can get read-only raw access with mount-vhd:
urbackupsrv mount-vhd -f /path/Image_C_xxx.vhdxz -m /mnt/img -t /mnt/imgraw
This starts a FUSE process that exposes the volume as one file, /mnt/imgraw/volume, and then mounts the file system from it read-only at /mnt/img. You can read the raw file directly, e.g.
dd if=/mnt/imgraw/volume bs=512 skip=N count=1 | od -A x -t x1z
I tried this with server 2.5.38 on a .vhdxz file.
Offsets: inside the image the volume starts at byte 524288 (UrBackup puts a made-up MBR in front). The “volume” file already has that removed, so NTFS sector N is at byte N * 512.
Decompression: the file is compressed in blocks with an index, so only the blocks you read get decompressed. Reading one sector read about 2 MB of an 800 MB image here. Areas that were unused at backup time are not stored and read as zeros.
Read-only: the image file is opened read-only, the “volume” file has mode 0444 and opening it for writing fails with “Permission denied”. Nothing in that path repairs anything. There is no output that says so; the checksum and modification time of the image file were unchanged after mounting and reading in my test. Don’t use “urbackupsrv decompress-file” for this: it replaces the image file with the uncompressed one.
The catch for your case: the NTFS backup boot sector is the last sector of the partition, one sector past the “total sectors” value in the boot sector. The image is exactly “total sectors” long (checked on an image of a Windows volume), so the backup boot sector is not in it. You would have to read it on the source disk itself.