Date: Thu, 26 Mar 2009 16:40:48 +0100 From: Peter Schuller <peter.schuller@infidyne.com> To: Jake Scott <jake@poptart.org> 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: <20090326154048.GA47539@hyperion.scode.org> In-Reply-To: <alpine.BSF.2.00.0903261432350.31074@cyhz.syveoyr.bet> References: <49C9E635.5010106@kkip.pl> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
--nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > Exactly right - if you backup a database by relying on storage snapshots= =20 > then the best you will end up with is a database that needs to be=20 > recovered when you restore those volumes (crash consistent). That's not = a=20 > good place to be in when your production DB has just blown up. If you have a production db that you care about, your database better not have trouble recoverying from a crash consistent state. But again I'm not suggesting that snapshot based backups be the primary method of backing up. In terms of time-to-recovery, having a crash consistent DB can be a lot quicker to recover than grabbing a dump, whose restoration will tend to be a lot slower than copying files. > Absolutely. You really must use a tool that interacts with the database= =20 > to perform the backup. Most commercial DBs have hooks that allow the=20 > backup routines to call out to custom snapshot facilities. One would=20 > usually request a backup through the database, which would then freeze IO= =20 > to its data files and maybe log files, deal with flushing caches etc and= =20 > then call your snapshot routine. I'm not aware that MySQL and Postgres d= o=20 > though so the best you can do is a dump. I do not think "really must" is appropriate since clearly you can recover without DB specific integration. There may be reasons why it's better to have DB specific integration though (for example, limiting the amount of log reply that will be needed at recovery). The implication above that you cannot use snapshot based mechanisms with PostgreSQL and MySQL is not true; it's just that if you do you have to know what you're doing. --=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 --nFreZHaLTZJo0R7j Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAknLogAACgkQDNor2+l1i30jXwCfRpNF3CpzFl7K0QdjaQN8kuLr RtgAn2Vw6k/WuNwtIdtOXodlxhKsKaf2 =s3Az -----END PGP SIGNATURE----- --nFreZHaLTZJo0R7j--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090326154048.GA47539>