28
option to those programs. This can be used by an expert in assisting
29
the recovery of catastrophically corrupted filesystems. In the future,
28
option to those programs. This can assist an expert in
29
recovering catastrophically corrupted filesystems. In the future,
30
30
e2fsck will be enhanced to be able to use the image file to help
31
31
recover a badly damaged filesystem.
35
is -, then the output of
35
is \-, then the output of
37
37
will be sent to standard output, so that the output can be piped to
38
38
another program, such as
40
(Note that is currently only supported when
40
(Note that this is currently only supported when
41
41
creating a raw image file using the
43
43
option, since the process of creating a normal image file currently
44
requires random-access access to the file, which can not be done using a
44
requires random access to the file, which cannot be done using a
45
45
pipe. This restriction will hopefully be lifted in a future version of
50
option will create a raw image file instead of a normal image file.
51
A raw image file differs
52
from a normal image file in two ways. First, the filesystem metadata is
53
placed in the proper position so that e2fsck, dumpe2fs, debugfs,
54
etc. can be run directly on the raw image file. In order to minimize
55
the amount of disk space consumed by a raw image file, the file is
56
created as a sparse file. (Beware of copying or
57
compressing/decompressing this file with utilities that don't understand
58
how to create sparse files; the file will become as large as the
59
filesystem itself!) Secondly, the raw image file also includes indirect
60
blocks and data blocks, which the current image file does not have,
61
although this may change in the future.
63
It is a very good idea to periodically (at boot time and
64
every week or so) to create image files for all of
65
filesystems on a system, as well as saving the partition
66
layout (which can be generated using the using
68
command). Ideally the image file should be stored on some filesystem
70
the filesystem whose data it contains, to ensure that its data is
48
It is a very good idea to create image files for all of
49
filesystems on a system and save the partition
50
layout (which can be generated using the
52
command) at regular intervals --- at boot time, and/or every week or so.
53
The image file should be stored on some filesystem other than
54
the filesystem whose data it contains, to ensure that this data is
71
55
accessible in the case where the filesystem has been badly damaged.
73
57
To save disk space,
76
60
Hence, if the image file
77
61
needs to be copied to another location, it should
78
62
either be compressed first or copied using the
80
option to GNU version of
64
option to the GNU version of
83
67
The size of an ext2 image file depends primarily on the size of the
84
68
filesystems and how many inodes are in use. For a typical 10 gigabyte
85
69
filesystem, with 200,000 inodes in use out of 1.2 million inodes, the
86
image file be approximately 35 megabytes; a 4 gigabyte filesystem with
70
image file will be approximately 35 megabytes; a 4 gigabyte filesystem with
87
71
15,000 inodes in use out of 550,000 inodes will result in a 3 megabyte
88
72
image file. Image files tend to be quite
89
73
compressible; an image file taking up 32 megabytes of space on
90
74
disk will generally compress down to 3 or 4 megabytes.
76
.SH RESTORING FILESYSTEM METADATA USING AN IMAGE FILE
80
option will cause e2image to install the metadata stored in the image
81
file back to the device. It can be used to restore the filesystem metadata
82
back to the device in emergency situations.
87
option should only be used as a desperation measure when other
88
alternatives have failed. If the filesystem has changed since the image
89
file was created, data
91
be lost. In general, you should make a full image
92
backup of the filesystem first, in case you wish to try other recovery
93
strategies afterwards.
98
option will create a raw image file instead of a normal image file.
99
A raw image file differs
100
from a normal image file in two ways. First, the filesystem metadata is
101
placed in the proper position so that e2fsck, dumpe2fs, debugfs,
102
etc. can be run directly on the raw image file. In order to minimize
103
the amount of disk space consumed by a raw image file, the file is
104
created as a sparse file. (Beware of copying or
105
compressing/decompressing this file with utilities that don't understand
106
how to create sparse files; the file will become as large as the
107
filesystem itself!) Secondly, the raw image file also includes indirect
108
blocks and directory blocks, which the standard image file does not have,
109
although this may change in the future.
111
Raw image files are sometimes used when sending filesystems to the maintainer
112
as part of bug reports to e2fsprogs. When used in this capacity, the
113
recommended command is as follows (replace hda1 with the appropriate device):
116
\ \fBe2image \-r /dev/hda1 \- | bzip2 > hda1.e2i.bz2\fR
118
This will only send the metadata information, without any data blocks.
119
However, the filenames in the directory blocks can still reveal
120
information about the contents of the filesystem that the bug reporter
121
may wish to keep confidential. To address this concern, the
123
option can be specified. This will cause
125
to scramble directory entries and zero out any unused portions
126
of the directory blocks before writing the image file. However,
129
option will prevent analysis of problems related to hash-tree indexed
94
134
was written by Theodore Ts'o (tytso@mit.edu).
97
is part of the e2fsprogs package and is available from anonymous
137
is part of the e2fsprogs package and is available from
98
138
http://e2fsprogs.sourceforge.net.
100
140
.BR dumpe2fs (8),
added
removed
misc/e2image.8.in
