Move bootable disk images across slow links

A 1 TB bootable disk may contain only 100 GB of meaningful data. A raw image created with dd still records every addressable byte. The image file is large because the tool copies the block device, including space the filesystem considers free.

A small transfer requires a clear answer to a bigger question: what must the receiver reproduce exactly?

1. Decide what must survive#

A bootable disk can contain a partition table, EFI system partition, bootloader, hidden metadata, several filesystems, and application data. A file-level copy alone may miss boot structures or ownership and attribute details.

Document the disk layout before choosing a format:

lsblk -o NAME,SIZE,FSTYPE,PARTTYPE,MOUNTPOINTS
sfdisk --dump /dev/sdX
blkid

/dev/sdX is a placeholder. Keep the exported partition layout and device metadata with the backup.

2. Establish a simple compressed baseline#

A compressed raw image is often the easiest first experiment, especially when the source is offline or booted from a rescue environment:

dd if=/dev/sdX bs=16M status=progress | zstd -T0 -10 -o disk.img.zst

This command reads the entire source disk. Compression is effective when unused blocks contain compressible bytes. Free blocks can contain old data and may compress poorly. For a consistent image, stop writers and use an approved offline or snapshot procedure.

A restore test can stream the image to a destination disk of suitable capacity:

zstd -dc disk.img.zst | dd of=/dev/sdY bs=16M status=progress conv=fsync

The restore overwrites the destination disk. Verify device identity in a disposable lab before running it. Never assume /dev/sdY is the correct target.

3. Consider filesystem-aware imaging#

Tools such as Partclone can copy allocated filesystem blocks for supported filesystems. This can dramatically reduce data volume when the disk has much more empty space than used space. The trade-off is that the partition table and other boot components need their own preservation and restore workflow.

Check filesystem support and availability in your approved package repositories. A mixed disk layout may need different handling per partition.

4. When versions differ by only a little#

If version 1.3 closely resembles version 1.2, a delta can reduce transfer size. The sender and receiver must agree on the exact base image. A changed byte offset in a raw image can affect delta efficiency, so measure results with real versions.

For repeatable distribution, record a SHA-256 digest of the base, delta, and reconstructed artifact:

sha256sum disk.img.zst

Reconstruct in a test environment and compare the resulting image digest to the source artifact before restoring onto hardware.

5. Test the entire restore path#

Compression ratio alone is the wrong success metric. Measure transfer size, restore duration, boot success, partition integrity, and application behavior. Test failure and retry when the network link is unstable.

The strongest design keeps both the disk-layout information and a tested restore procedure beside the images. Saving bytes has little value if the reconstructed device cannot boot.