Well, I believe I have fixed the daily downtime issue (when the backup occurs at 12:30AM PDT).

Last night will be the last time you guys have anything to complain about on that matter. :p

In addition, I changed the backup script to delete old backups after new ones are created, so we shouldn't have any disk space issues in the near future.

Now, back to that stupid PDA theme >.>

So how did you fix it?

cool matty = uberadmin

Changed it to stop locking the tables and use a different method instead, along with not gzipping anymore.

If the tables aren't being locked, doesn't that mean you can end up with inconsistent data?

no, for the same reason you can do multiple simultaneous reads/writes on a SQL server without corruption.

Like I said in the other thread, I'm not a WEB SCIENTIST, but if mutual exclusion is done at all it'd have to be done on a row-by-row basis rather than on the entire table. I really should read up on MySQL one of these days, but in terms of multithreading this particular problem has been solved for about 30 years or so.

Not if you are dumping the whole table at once. Like Jon'C says, there should be some sort of lock on it (probably something along the lines of a read/write lock).

Not to mention the fact that updates to the database happen on a transactional basis as opposed to some kind of streaming. The database will always work before and after a transaction has completed, and by definition you're guaranteed at least that degree of atomicity on a field.

Basically what I'm trying to say is that, if a person made a post in the middle of backing up the forum db, you'd have his latest posts but his postcount from 10 seconds ago. The database won't be corrupted, but something that would require multiple queries could be off.

That's exactly what I'm suggesting. Putting anything into tihs vb forum happens across multiple queries, and fake "cron" jobs can happen on virtually any request. MySQL doesn't enforce anything in a transaction since by default it doesn't use a storage engine/table type that allows transactions. And most PHP developers (including the vb ones) have no idea wtf a transaction is or how to use one.

that is goddamn retarded

The only possible corruption would be as Jon`C explained, which I would be worried about regardless of the locked tables or not.

And VB has repair functions that I would run after a restore like that anyway just for safety's sake.

The benefits far outweigh the negatives, and there's no other choice.

Honestly, yeah, if someone is posting at the exact time the database is locked the same exact kind of corruption can happen.

Only on the live database, instead of the backup.

So this is still the lesser of two evils.

I have a silly question.

If the Massassi backups are all on the same hard drive as the live server, what happens if the Massassi hard drive dies?

We would all go mad and blow up the internets.

They're periodically copied over to CMs server. Hopefully that will be a nightly occurence shortly. We've had way more problems with the db getting corrupted, hacked, or otherwise destroyed, but that is a possibility we need to keep in mind.

Actually, I think just once a week would be a lot better. Downloading a couple GB of SQL data every night just seems, well, overkill. Especially for my server.

Right now I also have a backup of the website itself (including all the levels and crap) but I don't update that very often since... yeah, it doesn't change. :p

Weekly offsites would probably be fine.