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