On Thu, 2003-07-10 at 09:13, Olaf Frączyk wrote:
> On Thu, 2003-07-10 at 15:55, lambada@xxxxxxxxx wrote:
> > Hi
> >
> > Every root logging is a potential proof of stupididy.
> > It happens that since I had a problem (probably due to Nvidia drivers)
> > with my xfs home partition, I typed mkfs.xfs and not fsck.xfs (by the
> > way, I should have done an xfs_repair). The slight difference with this
> > commands ruined my day and a little more than 15 days of work.
> xfsdump is your friend :) In my company we do full backup every day with
> incremental backups during the day.
> BTW. mkfs.xfs should tell you that you are going to format device with
> existing filesystem. If it didn't it is a bug.
It should, that is what the -f option is for, of course, once you have
run into it a few times you type -f without thinking about it.
> > 1) Even if I imagine that I have no luck to reconstruct my partition as it
> > is possible with ext2, I am asking if it possible to recover any files
> > (even in a flatted directory)
> I don't think so. Probably you could find someone who can get some data,
> but it will cost really much. And I suppose it will get in tens thousand
> of USD, so it depends how much valuable data you have erased.
mkfs is probably simpler to recover from than rm -r -f, since rm will
overwrite a lot of metadata.
We actually did recover the names for a couple of hundred thousand
files which ended up in lost+found the other week. If mkfs is all
that has happened to the fs, then most of the state is still there,
it is just disconnected - and the root inode is reset.
Unfortunately it requires a lot of work with modified xfs_db executables
to get back from this point - scan the disk looking for directory blocks
via magic number, dump out the inode number/name pairs found. Go to the
inode addresses, read the inodes, find the extent information, read the
data and reassemble it. The work involved depends very much on what
happened to the filesystem to lose data, which means we could write
commands for xfs_db until we are blue in the face, and still not deal
with the next case which comes up.
Backup's are meant for circumstances like this.
Steve
--
Steve Lord voice: +1-651-683-3511
Principal Engineer, Filesystem Software email: lord@xxxxxxx
|