Date: Thu, 26 Mar 2009 16:53:49 +0100 From: Peter Schuller <peter.schuller@infidyne.com> To: Karl Denninger <karl@denninger.net> Cc: "Jack L. Stone" <jacks@sage-american.com>, freebsd-stable@freebsd.org, fs@freebsd.org Subject: Re: support quality (Re: dump | restore fails: unknown tape headertype 1853384566) Message-ID: <20090326155349.GA47932@hyperion.scode.org> In-Reply-To: <49CBA34B.9070708@denninger.net> References: <49C83673.3000604@aldan.algebra.com> <200903251820.54749.doconnor@gsoft.com.au> <200903251925.36108.doconnor@gsoft.com.au> <3.0.1.32.20090325072137.00ee6b48@sage-american.com> <3.0.1.32.20090326065337.00f081e0@sage-american.com> <3.0.1.32.20090326070807.00f081e0@sage-american.com> <200903261331.n2QDVd4b038485@lava.sentex.ca> <20090326140131.GA45201@hyperion.scode.org> <alpine.BSF.2.00.0903261432350.31074@cyhz.syveoyr.bet> <49CBA34B.9070708@denninger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > However, whether either of these approaches is sufficient is another=20 > matter. One of the real problems with live transaction processing=20 > systems is a means to know when there is a failure exactly what you=20 > lost. This is not a trivial problem to solve and requires plenty of=20 > thought before implementation, especially if you cannot afford the=20 > outage time necessary to take the snapshots - in some cases even that=20 > (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. --=20 / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller@infidyne.com>' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org --azLHFNyN32YCQGCU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAknLpQ0ACgkQDNor2+l1i31CzQCg5UoDaK/ztD4cfo0QV+NkpFfX uaUAnjhT2maKRMhWwSQ8XZMUOMPrMhdh =jjGC -----END PGP SIGNATURE----- --azLHFNyN32YCQGCU--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090326155349.GA47932>