The scenario
You are about to test a new kernel module, migrate to a different desktop environment, or simply want a safety net before a major system update. One wrong command or a corrupted package transaction can leave your system unbootable. You need a complete snapshot of the drive that you can restore later, down to the bootloader and partition table.
What a full disk image actually does
A full disk image is a byte-for-byte copy of your storage device. It captures the partition table, the bootloader, every filesystem, and the empty space between them. Think of it like photographing an entire bookshelf instead of photocopying individual pages. When you restore it, you get back exactly what was there, including the exact block layout. This is powerful for disaster recovery, but it means the image will be the same size as the physical drive, not just the size of your installed files.
File-level backup tools like rsync or tar copy files based on the filesystem tree. They miss unallocated space, bootloader sectors, and partition boundaries. Block-level tools like dd ignore the filesystem entirely. They read raw sectors and write them sequentially. This guarantees a perfect replica, but it also means you cannot selectively restore a single folder from the image without mounting it first.
Always verify your device names before running block-level commands. A single typo can overwrite your active drive. Check the layout first.
Creating a raw image with dd
The dd command is the standard Linux tool for low-level block copying. It reads raw sectors from a source device and writes them to a destination file. Because it operates at the block level, it bypasses the filesystem entirely. This makes it reliable for capturing bootloaders and complex partition schemes, but it also means a single typo can overwrite your active drive. Always verify your device names before running the command.
Here is how to check your current disk layout and identify the correct source device.
lsblk -o NAME,SIZE,TYPE,MOUNTPOINT
# Lists all block devices with their sizes and mount points
# Identify your root drive by looking for the largest block device
# Note the exact name like nvme0n1 or sda, not the partition like nvme0n1p2
Once you have confirmed the source device, run the copy command from a live environment or an unmounted state. Copying a mounted root filesystem can produce an inconsistent image if files change during the read process. Boot from a Fedora Live USB, open a terminal, and execute the following.
sudo dd if=/dev/nvme0n1 of=/run/media/liveuser/external-drive/fedora-backup.img bs=4M status=progress conv=fdatasync
# if specifies the input file, which is the entire physical disk
# of specifies the output file path on an external drive with enough space
# bs=4M sets the block size to 4 megabytes for faster throughput
# status=progress prints periodic transfer statistics to the terminal
# conv=fdatasync forces a physical write to disk before finishing
The command will run silently except for the progress updates. Wait until it reports bytes copied and returns to the shell prompt. Do not interrupt the process. A broken pipe or forced termination will leave you with a truncated image that fails during restoration.
If you want to save space, pipe the output through compression. Raw images of modern drives are often mostly empty space. Compression reduces the final file size dramatically without losing data.
Here is how to compress the image on the fly using gzip.
sudo dd if=/dev/nvme0n1 bs=4M status=progress | gzip -c > /run/media/liveuser/external-drive/fedora-backup.img.gz
# if specifies the input file, which is the entire physical disk
# bs=4M sets the block size to 4 megabytes for faster throughput
# status=progress prints periodic transfer statistics to the terminal
# gzip -c writes the compressed stream to standard output instead of a file
# The redirection operator saves the compressed stream to the target path
Compression adds CPU overhead. The transfer will take longer, but the resulting file will be significantly smaller. Use a fast external drive to avoid bottlenecking the write speed. Always verify the compressed file before deleting the original.
Verifying the raw image
Trusting a backup without verification is a false sense of security. You need to confirm the image contains valid partition tables and readable filesystems before you consider the job complete. The fdisk utility can inspect the image file directly without mounting it.
Here is how to check the partition table inside the saved image.
sudo fdisk -l /run/media/liveuser/external-drive/fedora-backup.img
# Reads the partition table from the image file instead of a physical disk
# Confirms that the EFI system partition and Linux root partition exist
# Verifies the total size matches your original drive capacity
You can also mount individual partitions from the image to verify file integrity. Loop mounting allows the kernel to treat the image file as a block device. Use losetup to attach it, then mount the specific offset. For most users, checking the partition table and comparing the image size against the source drive is sufficient. If the sizes match and fdisk lists the expected partitions, the copy succeeded.
Check the image size against the source drive capacity. A mismatch means the copy was interrupted or the external drive ran out of space. Run ls -lh on the image file and compare it to the SIZE column from your earlier lsblk output. Trust the numbers, not the file manager preview.
Common pitfalls and error patterns
The most dangerous mistake is swapping the if and of arguments. If you accidentally point of at your active drive, dd will overwrite it sector by sector. The terminal will not ask for confirmation. It will simply start destroying your data. Always read the command line twice before pressing enter.
Another frequent issue involves copying a mounted root filesystem. If you run dd on /dev/nvme0n1 while Fedora is actively using it, the resulting image will contain files that were half-written or changed mid-copy. Restoring that image will likely cause filesystem corruption or boot failures. The error usually shows up later as EXT4-fs error or BTRFS: critical error in journalctl -xe. Always use a Live USB or unmount the target drive first.
You might also run into space constraints. A raw image of a 1TB drive will be 1TB, even if you only have 200GB of data on it. If your external drive runs out of space mid-copy, dd will print No space left on device and stop. The resulting file will be useless. Check available space with df -h before starting.
LVM and Btrfs add another layer of complexity. If your Fedora installation uses LVM, the physical volume contains logical volumes that span across the disk. A raw dd image will capture the LVM metadata correctly, but restoring it to a drive with a different sector layout can break the volume group. If you use Btrfs, consider taking a native snapshot instead. Btrfs snapshots are instant, space-efficient, and do not require unmounting the drive. Use block-level imaging only when you need a complete hardware-independent backup.
When to use dd versus Clonezilla
Use dd when you need a quick, scriptable, byte-exact copy and you are comfortable working from a terminal. Use dd when you want to pipe the output through compression or encryption tools like gzip or openssl. Use Clonezilla when you prefer a graphical menu and automatic compression of empty blocks. Use Clonezilla when you need to restore the image to a drive of a different size or when you want to skip unallocated space to save storage. Stay on raw dd if you are automating backups in a cron job or Ansible playbook. Switch to Clonezilla if you are helping a non-technical user or need a guided recovery environment.
Clonezilla handles the partition alignment and filesystem checks automatically. It also provides a built-in verification step that compares checksums after the copy finishes. The tradeoff is that Clonezilla requires a separate bootable USB and a longer setup process. Choose the tool that matches your workflow and your tolerance for manual verification.
Run the verification step before you delete the source files. A silent corruption is worse than a missing backup.