mySQL Errors after Site Attack
 

Our server was recently infiltrated and a couple of viruses were planted. A little while after, we noticed all kinds of SQL errors coming up.

Any ideas what this is?

That looks like an error message from a phpbb bulletin board. I don't believe vBulletin uses any ".idb" designations for its tables. A quick google search only produced a Thread from someone on a PHPbb forum complaining to 123Hostnow about not being able to access his forum and getting alot of errors in files ending with ".idb".

Regards,

You are obviously using MySQL InnoDB tables - and one of your table files has gone missing (threadread). Since the data in that table is not important, the quickest fix is just to recreate the table.

The threadread table still exists and several other tables also have a similar problem.

Is there some way to recover data from more important tables?

Restore them from a backup. You really need to speak to your host about mysql problems.

Try doing a repair on the tables. When they can't be opened that means they are corrupted. Most of the time, a repair will fix it. Sometimes your host may have to get involved, but a current backup would work as well.

Yeah, I've tried the repair/check queries -- no luck though. Just returned the same 'cant open file' error. I've got a a backup, but I'm on a Windows server and don't have SSH. BigDump gives me SQL errors so a staggered dump is pretty much out of the question. Guess I get to split the file up... yay.

Well you only need to update those tables. So delete them, cut out the part in your sql file for each table, and past it into phpmyadmins sql section and it should just add fresh tables. That's how I did it after a major crash. I have never used InnoDB tables so milage may vary.

Out of interest, why are you using innodb tables ?

What are InnoDB tables anyway? I just created a database and let vBulletin do the rest, I don't remember ever having a say in the matter.

The problem with that Jump is that there are only 3 tables that haven't been corrupted. So it's basically pointless to do it table by table...