e2image
Save critical ext2/ext3/ext4 filesystem metadata to a file
see also :
dumpe2fs - debugfs
Synopsis
e2image
[ -rsI ] device image-file
add an example, a script, a trick and tips
examples
source
echo "e2image
-r $ORIG_IMG $RAW_IMG"
$E2IMAGE -r $i
$RAW_IMG
md5sum $RAW_IMG >> $MD5_TMP
echo "e2image -Q
$ORIG_IMG $QCOW2_IMG"
echo "e2image
-Q $ORIG_IMG $QCOW2_IMG"
$E2IMAGE -Q $i
$QCOW2_IMG
md5sum $QCOW2_IMG >> $MD5_TMP
source
for _file in mke2fs tune2fs e2fsck
e2image e2undo resize2fs mklost+found chattr lsattr
do
_output_cpiod_bin_file "/${_file}"
"/${_file}.elf"
description
The
e2image program will save critical ext2, ext3, or
ext4 filesystem metadata located on device to a file
specified by image-file. The image file may be
examined by dumpe2fs and debugfs, by using the
-i option to those programs. This can assist an
expert in recovering catastrophically corrupted filesystems.
In the future, e2fsck will be enhanced to be able to use the
image file to help recover a badly damaged filesystem.
If
image-file is -, then the output of
e2image will be sent to standard output, so that the
output can be piped to another program, such as
gzip(1). (Note that this is currently only supported
when creating a raw image file using the -r
option, since the process of creating a normal image file,
or QCOW2 image currently requires random access to the file,
which cannot be done using a pipe. This restriction will
hopefully be lifted in a future version of
e2image.)
It is a very
good idea to create image files for all of filesystems on a
system and save the partition layout (which can be generated
using the fdisk -l command) at regular
intervals --- at boot time, and/or every week or so. The
image file should be stored on some filesystem other than
the filesystem whose data it contains, to ensure that this
data is accessible in the case where the filesystem has been
badly damaged.
To save disk
space, e2image creates the image file as a sparse
file, or in QCOW2 format. Hence, if the sparse image file
needs to be copied to another location, it should either be
compressed first or copied using the
--sparse=always option to the GNU version
of cp. This does not apply to the QCOW2 image, which
is not sparse.
The size of an
ext2 image file depends primarily on the size of the
filesystems and how many inodes are in use. For a typical 10
gigabyte filesystem, with 200,000 inodes in use out of 1.2
million inodes, the image file will be approximately 35
megabytes; a 4 gigabyte filesystem with 15,000 inodes in use
out of 550,000 inodes will result in a 3 megabyte image
file. Image files tend to be quite compressible; an image
file taking up 32 megabytes of space on disk will generally
compress down to 3 or 4 megabytes.
availability
e2image is part of the e2fsprogs package and is available
from http://e2fsprogs.sourceforge.net.
qcow2 image files
The -Q option will create a QCOW2 image file instead of a
normal, or raw image file. A QCOW2 image contains all the
information the raw image does, however unlike the raw image it
is not sparse. The QCOW2 image minimize the amount of disk space
by storing data in special format with pack data closely
together, hence avoiding holes while still minimizing size.
In order to send filesystem to the maintainer as a part of bug
report to e2fsprogs, use following commands (replace hda1 with
the appropriate device):
e2image -Q /dev/hda1 hda1.qcow2
bzip2 -z hda1.qcow2
This will only send the metadata information, without any data
blocks. However, the filenames in the directory blocks can still
reveal information about the contents of the filesystem that the
bug reporter may wish to keep confidential. To address this
concern, the -s option can be specified. This will cause
e2image to scramble directory entries and zero out any
unused portions of the directory blocks before writing the image
file. However, the -s option will prevent analysis of
problems related to hash-tree indexed directories.
Note that QCOW2 image created by e2image is regular QCOW2
image and can be processed by tools aware of QCOW2 format such as
for example qemu-img.
raw image files
The -r option will create a raw image file instead of a
normal image file. A raw image file differs from a normal image
file in two ways. First, the filesystem metadata is placed in the
proper position so that e2fsck, dumpe2fs, debugfs, etc. can be
run directly on the raw image file. In order to minimize the
amount of disk space consumed by a raw image file, the file is
created as a sparse file. (Beware of copying or
compressing/decompressing this file with utilities that don’t
understand how to create sparse files; the file will become as
large as the filesystem itself!) Secondly, the raw image file
also includes indirect blocks and directory blocks, which the
standard image file does not have, although this may change in
the future.
Raw image files are sometimes used when sending filesystems to
the maintainer as part of bug reports to e2fsprogs. When used in
this capacity, the recommended command is as follows (replace
hda1 with the appropriate device):
e2image -r /dev/hda1 - | bzip2 > hda1.e2i.bz2
This will only send the metadata information, without any data
blocks. However, the filenames in the directory blocks can still
reveal information about the contents of the filesystem that the
bug reporter may wish to keep confidential. To address this
concern, the -s option can be specified. This will cause
e2image to scramble directory entries and zero out any
unused portions of the directory blocks before writing the image
file. However, the -s option will prevent analysis of
problems related to hash-tree indexed directories.
Note that this will work even if you substitute "/dev/hda1" for
another raw disk image, or QCOW2 image previously created by
e2image.
restoring filesystem metadata using an image file
The -I option will cause e2image to install the metadata
stored in the image file back to the device. It can be used to
restore the filesystem metadata back to the device in emergency
situations.
WARNING!!!! The -I option should only be used as a
desperation measure when other alternatives have failed. If the
filesystem has changed since the image file was created, data
will be lost. In general, you should make a full image
backup of the filesystem first, in case you wish to try other
recovery strategies afterwards.
see also
dumpe2fs ,
debugfs
author
e2image
was written by Theodore Ts’o (tytso[:at:]mit[:dot:]edu).