Hi Ted and others,
I created a new partition on my disk, and without
noticing the change in the hdaX of the partition i did
an mke2fs /dev/hdaX. :(
Unfortunately it was my /home partition and was an
ext3 partition earlier. Can anyone please advice on
how to
retrieve the old data.
I read that mke2fs nukes all the meta information, so
does that mean all inodes are destroyed and there is
no hope for me ?!?!?
i did a cat /dev/hdaX > /dev/hdaY, which was an empty
partition earlier so that I can play around a bit. I
tried couple of things with debugfs but coudn't go
much far.
thanks
john
__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
On Wed, Nov 05, 2003 at 09:56:01PM -0800, Robert Gyazig wrote:
> Hi Ted and others,
>
> I created a new partition on my disk, and without
> noticing the change in the hdaX of the partition i did
> an mke2fs /dev/hdaX. :(
>
> Unfortunately it was my /home partition and was an
> ext3 partition earlier. Can anyone please advice on
> how to retrieve the old data.
>
> I read that mke2fs nukes all the meta information, so
> does that mean all inodes are destroyed and there is
> no hope for me ?!?!?
Unfortunately, you're correct. The location of which blocks were
associated with which inodes are irretrievably lost.
If you had backed up the metadata using an e2image command, you would
have been fine, but that command takes a while to run, so most people
don't bother to do this. (Not a bad idea for the absolute paranoids
in the house would be to run e2image out of a cron script and save the
image file on some *other* filesystem.)
I've thought about making mke2fs run e2image and saving the result
somewhere else, but that takes a long time, and people would get
annoyed if I did that. Still, enough people have gotten screwed by
this that I've been tempted to add this as an option. Another
possibility is for mke2fs to notice when the filesystem is already
formatted using ext2/3, and then printing a warning message and
waiting 10 seconds before continueing, so the user has a chance to
type control-C. This would probably be the least annoying as far as
already existing scripts that use mke2fs, although of course there
would be an option to turn this behaviour off.
> i did a cat /dev/hdaX > /dev/hdaY, which was an empty
> partition earlier so that I can play around a bit. I
> tried couple of things with debugfs but coudn't go
> much far.
You can use a disk editor to find the text strings of critical files
that you wish to rescue, and hope they were contiguously allocated,
but that's probably the best you can do....
Sorry, but that's the current Unix design philosophy, which is to
assume that the system administrator knows what he/she is doing. I
never, ever type the mke2fs command without a certain amount of fear
and trepidition, and always check and triple check before doing so.
Still, as Linux becomes more mainstream, we do need to think about
adding safety checks so that to avoid accidents by less careful system
administrators. The challenge is to figure out ways of doing so in
the least obstrusive way as possible, to avoid annoying the existing
population.
- Ted
P.S. The other approach, which might also be the right one, is to use
a front-end program --- call it newfs --- which does many more safety
checks and which could do things like use e2image to backup the inode
blocks before doing an mke2fs. That way, administrators can choose
whether they want the additional safety checks or not.
On Thursday 06 November 2003 14:34, Theodore Ts'o wrote:
> On Wed, Nov 05, 2003 at 09:56:01PM -0800, Robert Gyazig wrote:
> > Hi Ted and others,
> >
> > I created a new partition on my disk, and without
> > noticing the change in the hdaX of the partition i did
> > an mke2fs /dev/hdaX. :(
> >
> > Unfortunately it was my /home partition and was an
> > ext3 partition earlier. Can anyone please advice on
> > how to retrieve the old data.
> >
> > I read that mke2fs nukes all the meta information, so
> > does that mean all inodes are destroyed and there is
> > no hope for me ?!?!?
>
> Unfortunately, you're correct. The location of which blocks were
> associated with which inodes are irretrievably lost.
>
> If you had backed up the metadata using an e2image command, you would
> have been fine, but that command takes a while to run, so most people
> don't bother to do this. (Not a bad idea for the absolute paranoids
> in the house would be to run e2image out of a cron script and save the
> image file on some *other* filesystem.)
>
> I've thought about making mke2fs run e2image and saving the result
> somewhere else, but that takes a long time, and people would get
> annoyed if I did that. Still, enough people have gotten screwed by
> this that I've been tempted to add this as an option. Another
> possibility is for mke2fs to notice when the filesystem is already
> formatted using ext2/3, and then printing a warning message and
> waiting 10 seconds before continueing, so the user has a chance to
> type control-C. This would probably be the least annoying as far as
> already existing scripts that use mke2fs, although of course there
> would be an option to turn this behaviour off.
>
> > i did a cat /dev/hdaX > /dev/hdaY, which was an empty
> > partition earlier so that I can play around a bit. I
> > tried couple of things with debugfs but coudn't go
> > much far.
>
> You can use a disk editor to find the text strings of critical files
> that you wish to rescue, and hope they were contiguously allocated,
> but that's probably the best you can do....
>
> Sorry, but that's the current Unix design philosophy, which is to
> assume that the system administrator knows what he/she is doing. I
> never, ever type the mke2fs command without a certain amount of fear
> and trepidition, and always check and triple check before doing so.
> Still, as Linux becomes more mainstream, we do need to think about
> adding safety checks so that to avoid accidents by less careful system
> administrators. The challenge is to figure out ways of doing so in
> the least obstrusive way as possible, to avoid annoying the existing
> population.
>
> - Ted
>
> P.S. The other approach, which might also be the right one, is to use
> a front-end program --- call it newfs --- which does many more safety
> checks and which could do things like use e2image to backup the inode
> blocks before doing an mke2fs. That way, administrators can choose
> whether they want the additional safety checks or not.
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Hi!
> If you had backed up the metadata using an e2image command, you would
> have been fine, but that command takes a while to run, so most people
> don't bother to do this. (Not a bad idea for the absolute paranoids
> in the house would be to run e2image out of a cron script and save the
> image file on some *other* filesystem.)
Assuming I have e2image (I'm actually started to thinking it is pretty
good idea)... how do I restore it?
Pavel
--
Horseback riding is like software...
...vgf orggre jura vgf serr.
So anything like e2image available for reiserfs?
[and not of the mkisofs | cdrecord variety]
Cheers,
MaZe.
On Thu, Nov 06, 2003 at 04:01:48PM +0100, Pavel Machek wrote:
> Hi!
>
> > If you had backed up the metadata using an e2image command, you would
> > have been fine, but that command takes a while to run, so most people
> > don't bother to do this. (Not a bad idea for the absolute paranoids
> > in the house would be to run e2image out of a cron script and save the
> > image file on some *other* filesystem.)
>
> Assuming I have e2image (I'm actually started to thinking it is pretty
> good idea)... how do I restore it?
<Blush> The libext2fs library routines are there, but the userspace
tools haven't been written yet. What I've done the few times when
I've used it is to let debugfs access the image file, and use it
mostly for examination purposes.
What I'll probably do is add debugfs commands that allow you to copy
the superblock/block group descriptors, or the inode table, or the
block/inode allocation bitmaps from the image file back to the
filesystem. As I said, the library routines are there, but debugfs
front ends haven't been written yet. If someone has a critical
situation requiring them, I could probably throw together patches
within a day or so.
- Ted
Hi!
> > > If you had backed up the metadata using an e2image command, you would
> > > have been fine, but that command takes a while to run, so most people
> > > don't bother to do this. (Not a bad idea for the absolute paranoids
> > > in the house would be to run e2image out of a cron script and save the
> > > image file on some *other* filesystem.)
> >
> > Assuming I have e2image (I'm actually started to thinking it is pretty
> > good idea)... how do I restore it?
>
> <Blush> The libext2fs library routines are there, but the userspace
> tools haven't been written yet. What I've done the few times when
> I've used it is to let debugfs access the image file, and use it
> mostly for examination purposes.
>
> What I'll probably do is add debugfs commands that allow you to copy
> the superblock/block group descriptors, or the inode table, or the
> block/inode allocation bitmaps from the image file back to the
> filesystem. As I said, the library routines are there, but debugfs
> front ends haven't been written yet. If someone has a critical
> situation requiring them, I could probably throw together patches
> within a day or so.
I guess I'll start recomending e2image to people trying software
suspend ;-). It really seems like neat tool for "easy backups".
Pavel
--
Horseback riding is like software...
...vgf orggre jura vgf serr.
On Fri, Nov 07, 2003 at 07:43:13AM +0200, Szakacsits Szabolcs wrote:
>
> I know xfs_copy (it's my preferred fs in the last 6+ years) but the last
> time I checked it (before I sent my earlier email) it couldn't copy only
> metadata as e2image (always) and ntfsclone (optionally) can do:
You are correct (I should read the whole thread before piping up!),
thats on my ToDo list now - would be a very handy developers tool.
cheers.
--
Nathan
On Thu, 6 Nov 2003, Maciej Zenczykowski wrote:
> So anything like e2image available for reiserfs?
AFAIK, no for other filesystems (saving only metadata), only for NTFS
(e2image gave the inspiration):
http://linux-ntfs.sourceforge.net/man/ntfsclone.html
It clones either all used data or only metadata to a mountable image at the
sector level (so it's much more efficient than dd if disk is far away to be
full).
Szaka
On Fri, Nov 07, 2003 at 06:35:03AM +0200, Szakacsits Szabolcs wrote:
> On Thu, 6 Nov 2003, Maciej Zenczykowski wrote:
>
> > So anything like e2image available for reiserfs?
>
> AFAIK, no for other filesystems (saving only metadata), only for NTFS
> (e2image gave the inspiration):
SEE ALSO
xfs_copy(8).
cheers.
--
Nathan
On Fri, 7 Nov 2003, Nathan Scott wrote:
> On Fri, Nov 07, 2003 at 06:35:03AM +0200, Szakacsits Szabolcs wrote:
> > On Thu, 6 Nov 2003, Maciej Zenczykowski wrote:
> >
> > > So anything like e2image available for reiserfs?
> >
> > AFAIK, no for other filesystems (saving only metadata), only for NTFS
> > (e2image gave the inspiration):
>
> SEE ALSO
> xfs_copy(8).
I know xfs_copy (it's my preferred fs in the last 6+ years) but the last
time I checked it (before I sent my earlier email) it couldn't copy only
metadata as e2image (always) and ntfsclone (optionally) can do:
http://oss.sgi.com/projects/xfs/manpages/xfs_copy.html
If it also can then the man page might be updated.
Szaka
On Thu, 6 Nov 2003, Pavel Machek wrote:
> > > > If you had backed up the metadata using an e2image command, you would
> > > > have been fine, but that command takes a while to run, so most people
> > > > don't bother to do this. (Not a bad idea for the absolute paranoids
> > > > in the house would be to run e2image out of a cron script and save the
> > > > image file on some *other* filesystem.)
> > >
> > > Assuming I have e2image (I'm actually started to thinking it is pretty
> > > good idea)... how do I restore it?
> >
> > <Blush> The libext2fs library routines are there, but the userspace
> > tools haven't been written yet. What I've done the few times when
> > I've used it is to let debugfs access the image file, and use it
> > mostly for examination purposes.
> >
> > What I'll probably do is add debugfs commands that allow you to copy
> > the superblock/block group descriptors, or the inode table, or the
> > block/inode allocation bitmaps from the image file back to the
> > filesystem. As I said, the library routines are there, but debugfs
> > front ends haven't been written yet. If someone has a critical
> > situation requiring them, I could probably throw together patches
> > within a day or so.
>
> I guess I'll start recomending e2image to people trying software
> suspend ;-). It really seems like neat tool for "easy backups".
Note that according to Ted's first post, e2image backs up the _metadata_. He
didn't mention the real data...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Fri, Nov 07, 2003 at 06:35:03AM +0200, Szakacsits Szabolcs wrote:
> http://linux-ntfs.sourceforge.net/man/ntfsclone.html
>
> It clones either all used data or only metadata to a mountable image at the
> sector level (so it's much more efficient than dd if disk is far away to be
> full).
Can it avoid seeking all over the place when copying the data? This
would be really cool for fast backups and getting data off a dying
disk.
Andrew
Hi!
> > > > > If you had backed up the metadata using an e2image command, you would
> > > > > have been fine, but that command takes a while to run, so most people
> > > > > don't bother to do this. (Not a bad idea for the absolute paranoids
> > > > > in the house would be to run e2image out of a cron script and save the
> > > > > image file on some *other* filesystem.)
> > > >
> > > > Assuming I have e2image (I'm actually started to thinking it is pretty
> > > > good idea)... how do I restore it?
> > >
> > > <Blush> The libext2fs library routines are there, but the userspace
> > > tools haven't been written yet. What I've done the few times when
> > > I've used it is to let debugfs access the image file, and use it
> > > mostly for examination purposes.
> > >
> > > What I'll probably do is add debugfs commands that allow you to copy
> > > the superblock/block group descriptors, or the inode table, or the
> > > block/inode allocation bitmaps from the image file back to the
> > > filesystem. As I said, the library routines are there, but debugfs
> > > front ends haven't been written yet. If someone has a critical
> > > situation requiring them, I could probably throw together patches
> > > within a day or so.
> >
> > I guess I'll start recomending e2image to people trying software
> > suspend ;-). It really seems like neat tool for "easy backups".
>
> Note that according to Ted's first post, e2image backs up the _metadata_. He
> didn't mention the real data...
Thats okay, during my experiments I'm likely to kill some metadata but
hopefully I can't damage too much data... e2image seems perfect for
that.
Pavel
--
Horseback riding is like software...
...vgf orggre jura vgf serr.
On Fri, Nov 07, 2003 at 11:33:42AM +0100, Geert Uytterhoeven wrote:
> > I guess I'll start recomending e2image to people trying software
> > suspend ;-). It really seems like neat tool for "easy backups".
>
> Note that according to Ted's first post, e2image backs up the _metadata_. He
> didn't mention the real data...
Right. The idea is that there are a few blocks that if destroyed,
cause the loss of a vast amount of data. That's why backing up the
metadata is so important....
- Ted
On Fri, 7 Nov 2003, Andrew Pimlott wrote:
> On Fri, Nov 07, 2003 at 06:35:03AM +0200, Szakacsits Szabolcs wrote:
> >
> > http://linux-ntfs.sourceforge.net/man/ntfsclone.html
> >
> > It clones either all used data or only metadata to a mountable image at the
> > sector level (so it's much more efficient than dd if disk is far away to be
> > full).
>
> Can it avoid seeking all over the place when copying the data? This
First it validates the block allocation bitmap then uses it. So seeks are
minimized and it indeed gave performance improvement:
http://marc.theaimsgroup.com/?l=linux-ntfs-dev&m=105032147728258&w=2
> would be really cool for fast backups and getting data off a dying disk.
For disks with bad sectors, etc I always recommended 'dd noerror ...' but
yes, there are cases when it's safe thus it make sense to support this as
well - added to TODO list. Cheers,
Szaka