File system checking on ext3 after a system crash
Sev Binello
sev at bnl.gov
Mon Apr 9 20:14:51 UTC 2007
We have backups etc but that's all very time consuming when trying to
restore in an operational env.
So, I thought well we could run e2image every night,
and if the file system is totally shot (ie. sometimes after e2fsck we
don't have much of a file system left),
to the point where we have to restore from backup,
then hey we could give e2image a shot and just lose a limited amount of
data.
Is that too naive ?
I got the impression below, that creating an image may be too time
consuming ?
I'm talking about filesystems about 500Gb, and don't change a real lot.
Thanks.
-Sev
Theodore Tso wrote:
> On Mon, Apr 09, 2007 at 02:29:57PM -0400, Sev Binello wrote:
>
>>> 3) Periodically, and at a non-peak time, use the e2image program to
>>> save a backup copy of the filesystem metadata. Do this *especially*
>>> if you don't have space to do a real backup. This will give you at
>>> least some measure of a saving throw against a single bad disk write
>>> (caused by malfunctioning storage hardware, or the aforementioned
>>> buggy binary-only graphical driver written in C++ with the pointer
>>> error) from destroying a huge numer of files.
>>>
>> I noted this response with interest.
>> I was unaware of this tool.
>>
>
> It's been around since e2fsprogs 1.20 (May 20, 2001), but it hasn't
> gotten a lot of play outside of my "Recovering From Hard Drive
> Disasters" Usenix tutorial. Anyone feel like writing a HOWTO
> document? :-)
>
>
>> I did a quick test and looks simple to use, are there any caveats or
>> hidden gotchas ?
>> I understand it will only restore to the state it was in when the
>> image was taken,
>> but in a pinch that maybe an alternative we could use.
>>
>
> In general I'd recommend against using the e2image -I option. As I've
> stated in the man page, it is rarely the right answer. It's there
> primarily so I can do a demonstration of recovering from a mke2fs (and
> it is quite the impressive demo), but unless the e2image is very
> fresh, it is very likely that it will do more harm than good.
>
> The main use of the e2image file is that you can use it with debugfs:
>
> debugfs -d /dev/sda2 -i sda2.e2i
>
> Now you can use the dump and rdump commands to copy out critical files
> from the damaged filesystem.
>
>
>> Any idea how long it takes to create/restore ?
>>
>
> The main cost is the time to read the entire inode table from the
> filesystem and write it back out to the e2image file, so it really
> depends on the size of the filesystem. On my
> when-I-have-time-for-a-quick-hack list, I have adding a new option to
> e2image which assumes that the filesystem bitmap blocks are
> trustworthy and will only back up the portion of the inode table which
> is actually in use. That will almost certainly be in the next version
> of e2fsprogs, since that's a pretty simple change.
>
>
>> Would it make sense to run on a daily basis ?
>>
>
> If you have sufficient amounts of off-peak time, yes!
>
>
>> Also, wondering if you could point me to documentation explaining
>> how to
>> respond to e2fsck questions when it finds problems in the file system.
>>
>
> Hmm, there really isn't any. In general the right answer is almost
> always 'yes', but sometimes I'll take a quick look at the filesystem
> using debugfs before answering yes just in case manual intervention
> could do a better job.
>
> The big thing is that if e2fsck wants to relocate an inode table, you
> almost always want to stop and backup metadata blocks using e2image
> first. In fact I'm thinking about revamping that logic since right
> now the potential for doing great harm to the filesystem is far too
> high. So the fact that you might want to say 'n' there is really more
> of a sane of a e2fsck bug, or at least misdesign, more than anything
> else.
>
> Regards,
>
> - Ted
>
--
Sev Binello
Brookhaven National Laboratory
Upton, New York
631-344-5647
sev at bnl.gov
More information about the Ext3-users
mailing list