Don't take the database down for backups.
I can think of no logical reason why you'd want to kill the DB to back it up, since it's just a big "read" operation.
Referential integrity might be a reason.
Good point, though if this is a concern, the OP will probably use the built-in enforcement of referential integrity and transaction support of whatever database they are running.
I don't know what an "OP" is, though I'm not sure it's relevant to my point. What I'm saying is that I don't think it's a good idea to back up a live database, because at that point you can't enforce referential integrity any more.
If a single database is spread over files A, B, and C, then in the time it took for a naive backup to grab file A, files B and C may have changed such that the database cannot be restored to an internally-consistent state using files A, B, and C. At this point, enforcement of referential integrity would actually work against you.
Bottom line is that I wouldn't trust a backup of a live database, ever. I would take every step to avoid relying on such a backup.
*cough* postgresql ;)
However, I agree -- don't back up the database directly -- use whatever utilities the database provides to dump the database, then back up the dump. Depending on how well the dump utility works, you might be able to do away with the downtime.
mysql has mysqldump, and postgresql has pg_dump. Both of these are pretty much all you'd need, and neither requires any site downtime.
Exactly. Use the DB to make the snapshot, then back up the snapshot.
cheers,
Travis
--------------------------------------------------------------------- michal migurski- contact info and pgp key: sf/ca http://mike.teczno.com/contact.html
-- Travis Low <mailto:[EMAIL PROTECTED]> <http://www.dawnstar.com>
-- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
