views:

122

answers:

4

I'm hoping this will be a simple answer for one of you.

We've got PHP/MySQL running on a single board computer for a product that will be a web-based admin tool. This product will be a 'set it and forget it' application.

One of our concerns (whether or not it's valid) is MySQL table/dbase corruption.

We have processes running continually on this little box that can diagnose the corruption, or catch dbase errors and act accordingly.

We are creating backups regularly via these same processes. Our thought is that if we sense corruption or catch a dbase error, that we'll briefly pause our processes and do a restore of the table from the most recent backup. Our hope is that this will fix the corruption.

The question is: If a MySQL table is corrupted, can we perform a backup restore?

I suppose a follow-up question would be if our logic above is correct. Will a backup restore correct a table corruption issue?

I know this sounds silly, but we're not that familiar with the MySQL backend. Our fear is that if the dbase (or a table) is somehow corrupted, that this will also impede a backup restore.

Can some of you weigh in on this?

Thanks so much.

A: 

I think that's the whole point of having a back-up isn't it?

Besides, if the table is already corrupt, what's the worst that could happen when you try to restore it?

I say go for it.

mgroves
+1  A: 

Yes, it will. Keep in mind that you'll only have data up until your last backup, so you'll lose whatever went in from that time to the corruption time, but this is generally a day at most.

The backup is a copy of the database in whatever state it was in during backup. If you restore a corrupt database with a clean backup, you'll be hunky dory. For this reason, keep monthly backups and the last seven days, as well. Just in case one of your backups is hosed.

Eric
This is a very small dbase, but vital to the product, and so we're actually doing backups every 5 minutes. If at any point, one of our processes catches a dbase read/write error, we attempt to diagnose and then run the restore from file.
Ducain
+1  A: 

I think even before you think of that, you need to put in place measures to ensure that corrupt tables are never backed up. Because if you restore a backup and the backup itself happens to be corrupt, you are right back where you started.

What storage engine are you using?

Conrad
We are using InnoDb. I've read that in 99% of cases, InnoDB will 'take care of' corruption issues. I...just have a hard time believing that.
Ducain
+1  A: 

One thing to think about; Depending on how your database is structured restoring a single table from backup can cause problems with referential integrity.

Mendelt
Could you briefly comment on that further?
Ducain
If you have relations to or from that table then restoring a single table backup with different content can cause foreign keys to point to none existing rows. This might not be a problem depending how your application handles this.
Mendelt