e2image exists for the moment just before a risky repair, when a metadata backup is the difference between a bad afternoon and a bad week. It creates a file holding the critical metadata from an ext2, ext3 or ext4 file system, then lets you verify another e2fsprogs tool can read it back. The normal image is compact and suited to inspection; raw and QCOW2 formats exist for a more complete image or a virtual-machine workflow. Allow 10 to 20 minutes, plus the time needed to read the source device.
This guide uses e2image from e2fsprogs 1.47.0, installed here as /usr/sbin/e2image. You need a readable source device or image file, room on a different file system for the destination, and root access if your account cannot read the source. The examples only create files until the restore section: do not test restoration on a valuable device.
First confirm the installed command and identify the file system you mean to image. Use a device path such as /dev/nvme0n1p2 only after checking it carefully. Keep the destination off the file system being captured: if that file system is damaged, its image would be inaccessible too.
$ command -v e2image
/usr/sbin/e2image
$ e2image --help
e2image 1.47.0 (5-Feb-2023)For a mounted system, inspect the device mapping without changing anything:
$ findmnt -no SOURCE,FSTYPE,TARGET /path/to/mount
/dev/nvme0n1p2 ext4 /Replace /dev/nvme0n1p2 and /srv/recovery below with values you have verified. The destination directory should be on separate storage with capacity for the image: a normal image is metadata only, but its size depends on the file system and the number of inodes in use.
Run the basic form as root when the device permissions require it:
$ sudo e2image /dev/nvme0n1p2 /srv/recovery/nvme0n1p2.e2i
e2image 1.47.0 (5-Feb-2023)The command normally writes only critical file system metadata, not regular file contents. It creates a sparse image where possible, so the apparent size and the disk space consumed can differ. dumpe2fs and debugfs can examine the image with their -i option.
Checkpoint: confirm the output exists and is not an unexpectedly huge ordinary file:
$ sudo ls -lh /srv/recovery/nvme0n1p2.e2i
$ sudo du -h /srv/recovery/nvme0n1p2.e2i
$ sudo dumpe2fs -h -i /srv/recovery/nvme0n1p2.e2i | head -n 8
dumpe2fs 1.47.0 (5-Feb-2023)
Filesystem volume name: <none>
Filesystem magic number: 0xEF53Your UUID and feature list will differ. The magic number and a successful reader are useful checks; they do not prove every block is recoverable.
Choose raw format with -r when you need the metadata at the same relative offsets as the source. That lets tools such as debugfs, dumpe2fs and e2fsck operate directly on the raw image. Raw output is sparse, so use a destination with enough apparent capacity and preserve sparseness when copying it.
$ sudo e2image -r /dev/nvme0n1p2 /srv/recovery/nvme0n1p2.raw.e2i
e2image 1.47.0 (5-Feb-2023)
$ sudo dumpe2fs -h /srv/recovery/nvme0n1p2.raw.e2i | head -n 5
dumpe2fs 1.47.0 (5-Feb-2023)
Filesystem volume name: <none>
Filesystem magic number: 0xEF53When moving this file, use a sparse-aware copy or compress it first. For GNU cp, the documented form is:
$ cp --sparse=always /srv/recovery/nvme0n1p2.raw.e2i /mnt/archive/Do not use an arbitrary file-copy or decompression tool and assume holes will survive: a raw image can expand towards the size of the source file system if sparseness is lost.
Use -Q for a QCOW2 image accepted by tools that understand that format, including QEMU tooling. Unlike a raw image, the QCOW2 file is not sparse in the same sense, although its format packs the represented blocks efficiently.
$ sudo e2image -Q /dev/nvme0n1p2 /srv/recovery/nvme0n1p2.qcow2
e2image 1.47.0 (5-Feb-2023)
$ file /srv/recovery/nvme0n1p2.qcow2
/srv/recovery/nvme0n1p2.qcow2: QEMU QCOW Image (v2), ...If you later need a raw image, the installed manual documents conversion from an e2image-generated QCOW2 file:
$ e2image -r /srv/recovery/nvme0n1p2.qcow2 /srv/recovery/nvme0n1p2.raw.e2iKeep the source QCOW2 file until the converted image has passed your checks. Do not assume a QCOW2 file from an unrelated producer has the layout e2image expects.
Metadata images can reveal directory names even without regular file data. If you are sending an image to a maintainer or another party, add -s to scramble directory entries and clear unused directory-block space:
$ sudo e2image -r -s /dev/nvme0n1p2 /srv/recovery/nvme0n1p2-scrubbed.raw.e2iScrambling prevents some directory hash-tree problems from being analysed, so keep an unsanitised copy under your own access controls when that diagnostic detail matters. Treat both forms as sensitive until you have checked their contents.
The source should normally be read-only when creating raw or QCOW2 images. -f overrides that requirement, but a changing source can make the result inconsistent and therefore much less useful. Use it only when a best-effort image beats having none, and record that limitation with the image.
If storage is tight, raw output can go to standard output and through a compressor. This is not supported for the normal or QCOW2 formats, which need random access to the destination.
$ sudo e2image -r -s /dev/nvme0n1p2 - | bzip2 > /srv/recovery/nvme0n1p2.raw.e2i.bz2
e2image 1.47.0 (5-Feb-2023)Check the pipeline's final status rather than trusting the presence of a destination file. In Bash, enable pipe failure reporting first:
$ set -o pipefail
$ sudo e2image -r /dev/nvme0n1p2 - | bzip2 > /srv/recovery/nvme0n1p2.raw.e2i.bz2
$ printf '%s\n' "$?"
0The shell setting persists in the current shell only. If the command fails, keep the diagnostic output, remove the incomplete compressed file after checking its path, and rerun with enough free space.
Warning: e2image -I writes metadata from an image back to a device. If the file system changed after the image was made, data will be lost. The installed manual describes this as a desperation measure.
Before considering it: stop writes to the target, take another full image backup, and preserve the original image. Confirm the device path twice. There is no general undo command here; recovery means restoring from the additional backup or trying another recovery strategy. The form is:
$ sudo e2image -I /dev/nvme0n1p2 /srv/recovery/nvme0n1p2.e2iDo not run that example as a test on a live system. Reading an image with dumpe2fs or debugfs is non-destructive; installing it is not.
dumpe2fs or file confirmed the resulting image is readable and has the expected format.-s used when directory names must be obscured.-I was not used unless the target was backed up, quiesced and positively identified.