To reassemble separate disk partition images into a coherent whole in Linux, use the cat command with explicit file ordering to concatenate the binary data streams. This approach creates a single raw image file that preserves the original sector layout and partition boundaries without introducing padding errors or corruption.
dd with bs=1M limits or specialized imaging software, you often end up with multiple small files (e.g., disk.img.01, disk.img.02). The goal is to merge these back into a single logical drive image so you can mount it, inspect the filesystem, or restore it to hardware. The previous advice suggesting complex piping methods was flawed because it ignored strict byte-level alignment. Correct reassembly requires treating each chunk as a contiguous block of bytes in the exact order they appeared on the source media.
Understanding Disk Image Structure
Before merging files, it is crucial to understand what you are working with. A raw disk image is a bit-for-bit copy of a storage device. It contains the Master Boot Record (MBR) or GUID Partition Table (GPT) at the very beginning, followed immediately by the partition data. If you simply concatenate files without ensuring they represent sequential sectors, you will create a "Frankenstein" image where partition tables point to invalid memory addresses, leading to read errors or complete data loss. The most common scenario involves images created by splitting a large file. For example, if you randd if=/dev/sda of=disk.img bs=1M and the system ran out of space, resulting in disk.img.01, disk.img.02, etc., these files are direct slices of the original stream. They do not contain headers or footers; they are pure data. Therefore, the reassembly process is strictly linear. You must ensure that .01 comes first, followed by .02, and so on. Any deviation in this sequence shifts all subsequent partition offsets, rendering the partition table unreadable by standard Linux tools like fdisk or parted.
Step-by-Step Reassembly Process
The safest and most reliable method for reassembling these images is using thecat utility. This command reads files sequentially and writes their contents to standard output. By redirecting this output to a new file, you reconstruct the original binary stream.
First, navigate to the directory containing your split image parts. Ensure you have sufficient free space on your destination drive to hold the fully reassembled image. Then, execute the concatenation command. You must list the files in ascending numerical order.
cat disk.img.01 disk.img.02 disk.img.03 > reassembled_disk.img
This command reads the first part, appends the second, then the third, and writes the combined result to reassembled_disk.img. It is critical to verify the order. If your files are named with zero-padded numbers (e.g., 001, 002), shell globbing patterns like *.img might sort them alphabetically in a way that breaks the sequence if not handled carefully. Always specify the filenames explicitly if there is any doubt about the sorting order.
After the command completes, verify the integrity of the new image. Check the file size against the sum of the individual parts. If disk.img.01 is 1GB, .02 is 1GB, and .03 is 500MB, the final image must be exactly 2.5GB. Use the ls -lh command to confirm the total size matches expectations. A mismatch indicates missing files or incorrect concatenation order.
Validating the Partition Table
Once the image is assembled, you need to confirm that the partition table is intact before attempting to mount any partitions. Usefdisk to inspect the structure. Run the following command, replacing reassembled_disk.img with your actual filename:
sudo fdisk -l reassembled_disk.img
If successful, fdisk will display the partition table, showing start and end sectors for each partition. You should see entries like /dev/sda1 or /dev/sda2 with specific file system types (e.g., Linux filesystem, Windows NTFS). If fdisk reports an error or shows no partitions, the reassembly failed, likely due to wrong file order or corrupted chunks. In this case, do not attempt to mount anything, as doing so could overwrite data.
If the partition table looks correct, you can proceed to mount individual partitions. However, mounting a partition from a disk image requires mapping it to a loop device. You cannot mount the entire image directly unless it contains only one partition and no boot sector conflicts. Instead, identify the starting sector of the desired partition from the fdisk output. Calculate the offset by multiplying the start sector by the sector size (usually 512 bytes). Then, use losetup to create a loop device with the correct offset:
sudo losetup -o 1048576 /dev/loop0 reassembled_disk.img
sudo mount /dev/loop0 /mnt/recovery
In this example, -o 1048576 specifies a 2048-sector offset (2048 * 512 = 1048576). Adjust the offset value based on your specific partition's start sector. Once mounted, you can copy your data off the drive. Remember to unmount and detach the loop device when finished to prevent data corruption.
Common Pitfalls and Verification
One frequent mistake is assuming that file names imply order without verification. Always double-check the sequence. Another issue arises with sparse files. If your original images were created as sparse files,cat will expand them, potentially consuming more disk space than expected. To save space, you can use tar with compression during the initial backup phase, but for reassembly of raw dd images, simple concatenation is best.
Additionally, always work on copies. Never modify the original split image files until you have verified the reassembled image works correctly. If you encounter checksum mismatches during recovery, refer to guides on handling corrupted filesystems. For instance, if you are dealing with BTRFS, you may need to run checksum verification tools after mounting. Also, once your data is safe, remember that your system configuration files like /etc/fstab might need updates if you plan to boot from the restored drive or integrate it permanently.
Frequently Asked Questions
Can I use rsync to reassemble split images?
No,rsync is designed for synchronizing directories and transferring files over networks, not for concatenating binary data streams. Using rsync would treat each chunk as a separate file rather than a continuous block of disk data, resulting in a broken image. Stick to cat or dd for this task.
What if my image files have different extensions?
If your split images have different extensions (e.g.,.img.gz vs .img), you must decompress them first or use appropriate filters. cat does not handle compression transparently. You should gunzip the compressed files into temporary uncompressed files before concatenating them, or use zcat alongside cat if mixing compressed and uncompressed parts, though this is rare and risky.
How do I know which partition number to mount?
Usefdisk -l on the reassembled image to view the partition table. Look for the "Start" column. The partition number corresponds to the entry listed (e.g., sda1, sda2). When using losetup, calculate the byte offset from the "Start" sector value multiplied by 512. Do not guess the partition number; rely on the output of fdisk.
Is it safe to delete the original split image files after reassembly?
Yes, once you have verified that the reassembled image mounts correctly and contains all your data, you can safely delete the original split chunks to free up space. However, always keep a backup of the reassembled image itself until you have successfully recovered all necessary files. Deleting the source is only safe after confirming the target is valid.What should I do if fdisk shows no partitions?
Iffdisk reports no partition table, the reassembly order is likely incorrect, or the image is corrupted. Verify that you concatenated the files in the exact numerical order they were created. Check the file sizes to ensure no chunks are missing. If the order is correct, the source disk may have been uninitialized or the image creation failed midway. In such cases, you may need to recover the partition table using tools like testdisk.