> > 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.
>
> 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.
Right, but if the database's built-in backup tool is used rather than the
filesystem, it ought to respect the read/write locks that are a natural
by-product of using begin/commit to wrap your transactions. E.g., a call
to pg_dump should be guaranteed to pull the database in an
internally-consistent state, if the application logic uses transactions
correctly. I guess that's probably what you meant by "Use the DB to make
the snapshot, then back up the snapshot." :)
(I say "ought" and "should" because I'm no DB guru, myself)
This popped up on /. yesterday, and it seems relevant:
http://www.oreillynet.com/pub/wlg/4715
---------------------------------------------------------------------
michal migurski- contact info and pgp key:
sf/ca http://mike.teczno.com/contact.html
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
