support quality (Re: dump | restore fails: unknown tape headertype 1853384566)

[Peter Schuller]

> 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.schuller at infidyne.com>'
Key retrieval: Send an E-Mail to getpgpkey at scode.org
E-Mail: peter.schuller at infidyne.com Web: http://www.scode.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090326/f3076714/attachment.pgp