I'm facing an interesting data recovery challenge after a malicious hack
last week.  It seems all the hacker did was log in to the machine and
"rm -rf /" and despite being assured backups were taken off-site daily it
seems that the only surviving full backup of the MySQL data files is from
August last year.  We do have an incremental backup for the day before the
hack, but what use is that without the previous increment?  I don't need to
tell you how pleased I am...

We've been able to use e2undel to recover all the files from the partition
where MySQL data was but identifying them is a horrendous task.  By grepping
I've been able to find the .frm files and spot which tables they relate to.
Using "file" and some very useful additions to /usr/share/magic I found on
the net I can also spot the .ISM files, though can't tell which tables they
belong to.

Finding the .ISD files though seems impossible... file reports them as just
"data" along with loads of other stuff, and I've tried looking for patterns
in the inode numbers to help identify them, to no avail.

Has anyone attempted an operation like this before, and if so did you have
any success?  Is there anything within a .ISM or .ISD file to say which
table it relates to?  Or can anyone suggest a way of automating combining a
known .frm file with a suspected .ISD file and using isamchk to see if it
can be rebuilt?

TIA

Chris Newman
[EMAIL PROTECTED]


---------------------------------------------------------------------
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/           (the list archive)

To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php

Reply via email to