Received: from localhost (maia-2.hub.org [200.46.204.187]) by postgresql.org (Postfix) with ESMTP id 63BA89FB3B2 for ; Mon, 23 Apr 2007 14:50:17 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.187]) (amavisd-maia, port 10024) with ESMTP id 40372-01 for ; Mon, 23 Apr 2007 14:50:04 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from howe.textdrive.com (howe.textdrive.com [207.7.108.240]) by postgresql.org (Postfix) with ESMTP id C142C9FB2E0 for ; Mon, 23 Apr 2007 14:50:05 -0300 (ADT) Received: from [10.0.23.134] (unknown [209.149.59.218]) by howe.textdrive.com (Postfix) with ESMTP id 9E42D120EE9 for ; Mon, 23 Apr 2007 17:50:04 +0000 (GMT) Resent-Message-Id: <8F96169E-F47C-45CC-AE8A-0284FD6430CA@o.ptimized.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/alternative; boundary=Apple-Mail-19--672579981 Resent-Date: Mon, 23 Apr 2007 12:49:59 -0500 Message-Id: <09318B6D-8C60-4287-978E-EAE199ACA15E@o.ptimized.com> Resent-To: pgsql-docs@postgresql.org From: "Thomas F. O'Connell" Subject: Incrementally Updated Backups: Docs Clarification Resent-From: "Thomas F. O'Connell" Date: Thu, 19 Apr 2007 15:48:34 -0500 To: pgsql-general@postgresql.org X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.041 tagged_above=0 required=5 tests=AWL=-0.457, BAYES_50=0.001, HTML_40_50=0.496, HTML_MESSAGE=0.001 X-Spam-Level: X-Archive-Number: 200704/26 X-Sequence-Number: 4222 --Apple-Mail-19--672579981 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I'll preemptively apologize for cross-posting this, but I follow the lists via Google Groups, and I never saw this show up on -general there. I see it in the archives, but the lack of discussion on - general makes me wonder if it was widely read. Since it involves what I perceive to be a lack of clarity in the docs, I'll offer to make up for my cross-posting by helping to improve the docs as mentioned below once I get things working... I'm about to begin playing with incrementally updated backups for a warm standby scenario, but I need some help understanding this paragraph in postgres terms. From 23.4.5 in the 8.2.3 docs: "If we take a backup of the standby server's files while it is following logs shipped from the primary, we will be able to reload that data and restart the standby's recovery process from the last restart point. We no longer need to keep WAL files from before the restart point. If we need to recover, it will be faster to recover from the incrementally updated backup than from the original base backup." I'm specifically confused about the meaning of the following phrases: "backup of the standby server's files" - Which files? "reload that data" - What does this mean in postgres terms? "last restart point" - What is this? Wouldn't it be able to restart from the last recovered file, which would presumably occur later than the last restart point? Does this mean make a filesystem backup of the standby server's data directory while it's stopped, and then start it again with that data and the restricted set of WAL files needed to continue recovery? I'd like to see the language here converted to words that have more meaning in the context of postgres. I'd be happy to attempt a revision of this section once I'm able to complete an incrementally updated backup successfully. Here's how I envision it playing out in practice: 1. stop standby postgres server 2. [optional] preserve data directory, remove unnecessary WAL files 3. restart standby server Is that all there is to it? -- Thomas F. O'Connell optimizing modern web applications : for search engines, for usability, and for performance : http://o.ptimized.com/ 615-260-0005 --Apple-Mail-19--672579981 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=US-ASCII
I'll preemptively apologize = for cross-posting this, but I follow the lists via Google Groups, and I = never saw this show up on -general there. I see it in the archives, but = the lack of discussion on -general makes me wonder if it was widely = read. Since it involves what I perceive to be a lack of clarity in the = docs, I'll offer to make up for my cross-posting by helping to improve = the docs as mentioned below once I get things working...

I'm about to begin playing = with incrementally updated backups for a warm standby scenario, but I = need some help understanding this paragraph in postgres terms. =46rom = 23.4.5 in the 8.2.3 docs:

"If we take a backup of the = standby server's files while it is following logs shipped from the = primary, we will be able to reload that data and restart the standby's = recovery process from the last restart point. We no longer need to keep = WAL files from before the restart point. If we need to recover, it will = be faster to recover from the incrementally updated backup than from the = original base backup."

I'm specifically confused = about the meaning of the following phrases:

"backup of the standby = server's files" - Which files?

"reload that data" - What = does this mean in postgres terms?

"last restart point" - What = is this? Wouldn't it be able to restart from the last recovered file, = which would presumably occur later than the last restart = point?

Does = this mean make a filesystem backup of the standby server's data = directory while it's stopped, and then start it again with that data and = the restricted set of WAL files needed to continue recovery? I'd like to = see the language here converted to words that have more meaning in the = context of postgres. I'd be happy to attempt a revision of this section = once I'm able to complete an incrementally updated backup = successfully.

Here's how I envision it = playing out in practice:

1. stop standby postgres = server
2. [optional] preserve data directory, remove = unnecessary WAL files
3. restart standby server

Is that all there is to = it?

optimizing modern web = applications
: for search engines, for usability, and for = performance :

615-260-000= 5
=
= --Apple-Mail-19--672579981--