Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 2AE7364FD82 for ; Wed, 15 Oct 2008 11:05:24 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 42561-10 for ; Wed, 15 Oct 2008 11:05:11 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by postgresql.org (Postfix) with ESMTP id C429064FE7B for ; Wed, 15 Oct 2008 11:05:11 -0300 (ADT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Kq6zs-0001aJ-W8 for pgsql-performance@postgresql.org; Wed, 15 Oct 2008 14:05:09 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 15 Oct 2008 14:05:08 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 15 Oct 2008 14:05:08 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: pgsql-performance@postgresql.org From: Ivan Voras Subject: Re: Backup strategies Date: Wed, 15 Oct 2008 16:05:06 +0200 Lines: 59 Message-ID: References: <48F4D693.9000304@lerner.co.il> <48F5BBFC.80404@krogh.cc> <48F5D6AE.3000601@lelarge.info> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD782F558150C3E188C7AE7BE" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.17 (X11/20080925) In-Reply-To: X-Enigmail-Version: 0.95.0 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200810/85 X-Sequence-Number: 31666 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD782F558150C3E188C7AE7BE Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Matthew Wakeling wrote: > On Wed, 15 Oct 2008, Ivan Voras wrote: >>> Nope. Even files in data directory change. That's why the documentati= on >>> warns against tools that emit errors for files that change during the= >>> copy. >> >> Ok, thanks. This is a bit off-topic, but if it's not how I imagine it,= >> then how is it implemented? >=20 > The files may change, but it doesn't matter, because there is enough > information in the xlog to correct it all. I'm thinking about these paragraphs in the documentation: """ Be certain that your backup dump includes all of the files underneath the database cluster directory (e.g., /usr/local/pgsql/data). If you are using tablespaces that do not reside underneath this directory, be careful to include them as well (and be sure that your backup dump archives symbolic links as links, otherwise the restore will mess up your tablespaces). You can, however, omit from the backup dump the files within the pg_xlog/ subdirectory of the cluster directory. This slight complication is worthwhile because it reduces the risk of mistakes when restoring. This is easy to arrange if pg_xlog/ is a symbolic link pointing to someplace outside the cluster directory, which is a common setup anyway for performance reasons. """ So, pg_start_backup() freezes the data at the time it's called but still data and xlog are changed, in a different way that's safe to backup? Why not run with pg_start_backup() always enabled? --------------enigD782F558150C3E188C7AE7BE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI9fiSldnAQVacBcgRAna/AJ96Kz0UvlYljejCr6LcoddNrMbxUACfT357 m9aBFRsRpU0g9GvVE7UlzgA= =7mpC -----END PGP SIGNATURE----- --------------enigD782F558150C3E188C7AE7BE--