> However, whether either of these approaches is sufficient is another > matter. One of the real problems with live transaction processing > systems is a means to know when there is a failure exactly what you > lost. This is not a trivial problem to solve and requires plenty of > thought before implementation, especially if you cannot afford the > outage time necessary to take the snapshots - in some cases even that > (relatively) short outage time is unacceptable.
I would like to point out that if the backup strategy is correct, a COMMIT is guaranteed to be correctly honored, and the problem of determining what was lost has more to do with the birds-eye view of to what point in time the database was reverted as part of emergency recovery, than any difficulty in understanding what actually happens during snapshot recovery. I completely understand that you have various requirements in production that makes it a non-solution to just get a consistent snapshot at some arbitrary point in time without synchronizing with other software components somehow, but such issuse are into the realm of application design and integration with the backup procedure, and we are no longer talking about the viability of obtaining a consistent backup of a single database through snapshotting. -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schul...@infidyne.com>' Key retrieval: Send an E-Mail to getpgp...@scode.org E-Mail: peter.schul...@infidyne.com Web: http://www.scode.org
pgpHwSW72mDdH.pgp
Description: PGP signature
