Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t9Qyl-00A9bg-R8 for pgsql-admin@arkaria.postgresql.org; Fri, 08 Nov 2024 15:32:55 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1t9Qyi-00AU0z-3B for pgsql-admin@arkaria.postgresql.org; Fri, 08 Nov 2024 15:32:52 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t9Qyh-00AU0r-MG for pgsql-admin@lists.postgresql.org; Fri, 08 Nov 2024 15:32:52 +0000 Received: from mail-oo1-xc29.google.com ([2607:f8b0:4864:20::c29]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1t9Qyd-000rzL-Ib for pgsql-admin@lists.postgresql.org; Fri, 08 Nov 2024 15:32:51 +0000 Received: by mail-oo1-xc29.google.com with SMTP id 006d021491bc7-5ebc0992560so1385800eaf.0 for ; Fri, 08 Nov 2024 07:32:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1731079966; x=1731684766; darn=lists.postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=VwIxRoDWxAevSai/tJ41s2VZqExqHhl2IXcJRWW61fo=; b=YYww/QnzpdaCOT/+HJRpGuscPsYAT+m7CdaxR1/hEOXCvE6eJVqy93GmRylCVtal/C H079xJz39FUgNFeHFwfr8cBdr+Y4dgoiznMgSw+FWSpaLX6/ul7AkgMeOfgTYEWQN0fC Bxg5L/JyDkZn8UA8Ka1/5f4N6ZXYLldbdk1Ch5k4VCWJfFxLZjZOejS9AcLl4PheDknN eJb+xOiAHrRd6L8IMMnqe1TL2p1wUtLtaLv/g53Xcszzi8Hhq5ZWkq+vmKGSrRZ+LQNS lLSCJgHeqo+e6t5gWO/bdSRzglHZY6hvWCcG02g1ClVTxcOTegOIsVvnH2B9qHPFKs2i orTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731079966; x=1731684766; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=VwIxRoDWxAevSai/tJ41s2VZqExqHhl2IXcJRWW61fo=; b=uZJnoJCsxxWV7BI9mP/6JivWwPom1JlPfT7LOW61PxuyqIb3f2+FdD9h/I+9Hx9oGY dXSync0TjCmPdrUhJx04Af9qn7xcz3Gngd48zupjymSRxdAhh0aJeMVtguycP0GXXeGh uz3k2riny1gkBFidv4eGclYcWyyK2zPoAvKBzTlLh1xGpyE0HQDK1rYCRBpbGAs0zAu0 OuPMKjf/tS0P+0IL0Md3uGjFW5BXiuh1adWSUePxdsgRQOv9qDabUXv5xSjnpuydZwX5 seAHzlYUZ7Wzrdpu6lASEy2HkYUMF7K+z9qUVN3qXDibkFUuhkQVEiNhUN/WXHAlggq3 N7Vw== X-Gm-Message-State: AOJu0YwRQyzdPi2NS2MYJAcJ6HPxj9J/3w6zKMQxGDvtI0nIXgfLYNQH cO6k0zshhqYpxpBYTCIWHqTSmxmOAmVk/+8/RaDfDpI0Si6KkzRLreTppkPKoTtqZPYasgjk4PG nRgss+cbIM7gIyRpLeMd2CnUtcg7VaJL+ X-Google-Smtp-Source: AGHT+IFkw/xNClizf0qtXjEdoyxJ6CP5ZdXKW/dmwGm1eUDEwvavl2NIRMah1M4VucX0o0PrkJQrqxlw4fK8J4MZKHo= X-Received: by 2002:a05:6820:1f08:b0:5eb:827b:9bbf with SMTP id 006d021491bc7-5ee57c6b6c8mr2871905eaf.7.1731079966242; Fri, 08 Nov 2024 07:32:46 -0800 (PST) MIME-Version: 1.0 References: <01000193082d1077-34d9461d-49e4-44ef-b83a-0201df4fc0ba-000000@email.amazonses.com> In-Reply-To: From: Ron Johnson Date: Fri, 8 Nov 2024 10:32:34 -0500 Message-ID: Subject: Re: Running rsync backups in pg15 To: Pgsql-admin Content-Type: multipart/alternative; boundary="0000000000007742e406266876bd" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000007742e406266876bd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable According to https://www.postgresql.org/docs/14/continuous-archiving.html#BACKUP-LOWLEVE= L-BASE-BACKUP Section 26.3.3.2, SELECT pg_backup_start('label') is how you start Exclusive Low Level backups. https://www.postgresql.org/docs/release/15.0/ says that this has been removed. On Fri, Nov 8, 2024 at 10:07=E2=80=AFAM Murthy Nunna wrot= e: > Yes. We already have streaming replication. But we still rely on rsync > backups for PITR. We keep two copies of rsync backups. The oldest full > rsync is 7 days. We save all WALs for 8 days. We do not want to change th= is > scheme. There are some bells and whistles during rsync to monitor the > backup. With the introduction of new requirement ( need to run > pg_backup_start/stop in same connection) we end up rewriting our backup > scripts. > > > > As noted earlier, I did a crash test in pg14 (which uses old functions > pg_start_backup/stop in separate connections) but I did not encounter any > issue like lingering backup_label file that prevents cluster restart etc. > What I noticed is pg14 is nicely renaming the backup_label file before > restarting the cluster. > > > > Please (pretty please) somebody tell me (via a URL that explains is good > enough) what problem is solved by introducing the new restriction of havi= ng > to run pg_backup_start/stop in same connection. I am pretty sure I am > missing the point=E2=80=A6 May be I should run the crash test in a differ= ent way to > reproduce the issue. > > > > > > *From:* Ron Johnson > *Sent:* Friday, November 8, 2024 8:09 AM > *To:* pgsql-admin > *Subject:* Re: Running rsync backups in pg15 > > > > That looks a whole lot like the results you get from async Streaming > Replication. > > > > Which is, of course, a DR solution, NOT a backup solution. > > > > -- > --=20 Death to , and butter sauce. Don't boil me, I'm still alive. lobster! --0000000000007742e406266876bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
According to=C2=A0https://www.postgresql.org/docs/14/continuous-archiving.html#BACKUP= -LOWLEVEL-BASE-BACKUP Section 26.3.3.2, SELECT= pg_backup_start('label') is how you start Exclusive=C2=A0Lo= w Level backups.

https://www.postgresql.org/docs/release/15.0/ = says that this has been removed.

On Fri, Nov 8, 2024 at 10:07=E2= =80=AFAM Murthy Nunna <mnunna@fnal.go= v> wrote:

Yes. We already have = streaming replication. But we still rely on rsync backups for PITR. We keep= two copies of rsync backups. The oldest full rsync is 7 days. We save all = WALs for 8 days. We do not want to change this scheme. There are some bells and whistles during rsync to moni= tor the backup. With the introduction of new requirement ( need to run pg_b= ackup_start/stop in same connection) we end up rewriting our backup scripts= .

=C2=A0<= /span>

As noted earlier, I d= id a crash test in pg14 (which uses old functions pg_start_backup/stop in s= eparate connections) but I did not encounter any issue like lingering backu= p_label file that prevents cluster restart etc. What I noticed is pg14 is nicely renaming the backup_label fi= le before restarting the cluster.

=C2=A0<= /span>

Please (pretty please= ) somebody tell me (via a URL that explains is good enough) what problem is= solved by introducing the new restriction of having to run pg_backup_start= /stop in same connection. I am pretty sure I am missing the point=E2=80=A6 May be I should run the crash test in= a different way to reproduce the issue.

=C2=A0<= /span>

=C2=A0<= /span>

From: Ron Johnson <ronljohnsonjr@gmail.com>
Sent: Friday, November 8, 2024 8:09 AM
To: pgsql-admin <pgsql-admin@postgresql.org>
Subject: Re: Running rsync backups in pg15

=C2=A0

That looks a whole lot like the results you get from= async Streaming Replication.

=C2=A0

Which is, of course, a DR solution, NOT a backup sol= ution.

=C2=A0

--



--
Death to <Redacted>, and butter sauce= .
Don't boil me, I'm still alive.
<Redacted>= lobster!
--0000000000007742e406266876bd--