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 1u7Sh1-00Gt8y-Cb for pgsql-general@arkaria.postgresql.org; Wed, 23 Apr 2025 05:30:43 +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 1u7Sgz-003Dc2-0P for pgsql-general@arkaria.postgresql.org; Wed, 23 Apr 2025 05:30:41 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1u7Sgy-003Dbu-Ev for pgsql-general@lists.postgresql.org; Wed, 23 Apr 2025 05:30:41 +0000 Received: from mail-yb1-xb2f.google.com ([2607:f8b0:4864:20::b2f]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1u7Sgw-001Tbq-3B for pgsql-general@postgresql.org; Wed, 23 Apr 2025 05:30:40 +0000 Received: by mail-yb1-xb2f.google.com with SMTP id 3f1490d57ef6-e6a8aa771e8so4858397276.3 for ; Tue, 22 Apr 2025 22:30:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1745386239; x=1745991039; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=tNZwiEnsu+r0GQ+43OfwBAS6Q3xE5QpOlnPEEcRFRCo=; b=iyQan5WHcuhxhhrstTg8wFQQEj7+hydfTwk6FvrhnxnJxzZpmmTrb0cMLYMJaoDgNf 5Sacy7IwGlHIjvs41t/kY0UpXWrUpVaXpVmhTABEULP/dMyEY4rYQyi+63shormCGoK0 rjOjvxIAx9mYNMH2xpt0mdNA0h2U2PVDVjRQwQXbU4n8WWXzENjWtuZUbzVSa9Nfx0mc tYvKeWKZD3s9FKteaSp0wqlSDh/uqy2P9QYOmrLO9LVNbuS9gcURPYjZULijw12r42WE f0MEO4oJJWRX4+uWbo2c1kLJSp7ppGQN3F3Ha7+/Fgg2AM4kpmCEild14p4ajWuGU0Vf FgyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745386239; x=1745991039; h=cc: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=tNZwiEnsu+r0GQ+43OfwBAS6Q3xE5QpOlnPEEcRFRCo=; b=kzY4avw6tedYDKPS7uQ7NgUmK2TQ/b09OpkD0jPBuzQW6QxwGu3LVywkPlYojhdZ0+ AYuT9S6nBOaaGsUzbHUUESv+otlb9HY1Fu5YRo284WPATUb84ddlmTZlIqMZvTw7GH9S /JpPhxQkcB8iC916Eym2CqC36QrJn12AIo+MT0FqazlA1P/y/BVjSp1zkH0IVpuXXA1h tFpf1GRB8MaV+r3PcIOMxLEX/lsKAvntzodhNdSiGvJNcrmYBnQPGrmyEtYNW0UIrt+I iO9GKCNXDdjdhqxleKujqEdLfs34DufnYkbIvhlcAT8LLLUSIT+KGvXPEtP7JbCJAcX9 p8aw== X-Gm-Message-State: AOJu0YwScPxBm6RGq+0GWNGHAPG3bIBPvvz5oxERVhPGT9FWqbKfNOTu RavkgI3Tz/JjTlEoY4uKQmHoINAbIKASQZ4oXcAZmJUM5XQrjUMYxdVG5nxS6JcMwJrlECaho1Y d0M9sBGSiTq5hA3sEvPw3GNQ2sdM= X-Gm-Gg: ASbGncsZJk/B1n5nE62yzF4euauD+twoL6DngZ4kaVOjH1ZlfUUfK+hxv26yZbP0B9t GhlJm5ehMD64VHxdj5eeiW1lcTxsyyaG4yZ2raD7E6dGNbN30lleii0FA0yPEcl2o+mOro6+YS8 B9Fmi1MrTX2rZqYW1lJnrHCys= X-Google-Smtp-Source: AGHT+IGu0j51rpqLE39Tm2jWamcA1lFaxoqhGX2xQVuvdW07RoujH0qgnIqwJemW7roFazICsveajrDhspg62+Hoa/o= X-Received: by 2002:a05:6902:1448:b0:e72:8216:7a82 with SMTP id 3f1490d57ef6-e7297dfaba6mr24086399276.26.1745386238590; Tue, 22 Apr 2025 22:30:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: KK CHN Date: Wed, 23 Apr 2025 11:02:52 +0530 X-Gm-Features: ATxdqUGGo4M9xKmuNvKhwxM3WctAF6_4j0S72LDIgYr0cDTPamMkxeNcqDcubo8 Message-ID: Subject: Re: Pgbackrest fails due after an ISP change To: Greg Sabino Mullane Cc: pgsql-general Content-Type: multipart/alternative; boundary="000000000000bf46b606336b66bb" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000bf46b606336b66bb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi List, Thanks for the clarification. If I want to start a fresh backup to the same repo server ( the one which fails the pgbackrest backup due to the file system full outage) what all are the steps I have to perform on the Repo Server and the DB server ? AFAIK, These all are the steps required , correct me if I'm wrong. 1. Stop the stanza on both repo server as well as on DB server ( $sudo -u myuser pgbackrest --stanza=3DMy_RepoX --force stop) 2. Then delete the stanza from either Repo Server or DB server ( by the delete stanza option ) Is the deletion of the stanza needed to be performed only at the Repo server is enough ? 3. After deletion of the stanza, delete the folders in the repo server archive, backup respectively by ( rm -f archive , rm -rf backup folders for My_RepoX ?) 4. Then execute the same stanza create command from the reposerver ? ( $ sudo -u myuser pgbackrest --stanza=3DMy_RepoX --log-level-console=3Dinf= o stanza-create)? 5. Then Check the stanza creation and config all perfect by ( sudo -u myuser pgbackrest --stanza=3DMy_RepoX --log-level-console=3Dinfo check ) 6. If the step 5 success, schedule the full backup from the cron I hope this will help me to take backup afresh in case an existing pgbackrest backup fails ( whatever the stupid reason what happened as in my case ) . ( In my case pgbackrest fails due to the scenario I faced, I mean due to the file system full and didn't notice it for 24 hours, even after made space of the partition /root which got full, later on the pgbackrest backups from cron scheduler unable to complete the backup) If anything is wrong or not sufficient as in the 6 steps AFAIK (As this a live Repo Server for other DB Clusters too, more than 10 nos, nothing should go wrong) , please correct/guide me Thank you, Krishane On Mon, Apr 21, 2025 at 9:49=E2=80=AFPM Greg Sabino Mullane wrote: > > > On Mon, Apr 21, 2025 at 9:03=E2=80=AFAM KK CHN wrote= : > >> >> ERROR: [082]: WAL segment 000000010000022000000038 was not archived >> before the 60000ms timeout >> > ... > >> How can I make the full backup command not to check the WAL was archive= d >> or not to the repo server for atleast once ? >> > > You cannot. WAL is an integral part of the backups. You should run the > pgbackrest "check" command and look at your Postgres logs to figure out w= hy > WAL files are not being archived. Once that is solved, try the backup aga= in. > > https://pgbackrest.org/command.html#command-check > > > Cheers, > Greg > > -- > Crunchy Data - https://www.crunchydata.com > Enterprise Postgres Software Products & Tech Support > > --000000000000bf46b606336b66bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi List,=C2=A0

Thanks for th= e clarification.=C2=A0=C2=A0

=C2=A0If I want to st= art a fresh backup to the same repo server ( the one which fails the pgback= rest backup due to the file system full outage) what all are=C2=A0 the step= s I have to perform on the Repo Server and the DB server ?

AFAIK,=C2=A0 =C2=A0 These all are the steps=C2=A0 required , corre= ct me=C2=A0if I'm wrong.

1.=C2=A0 Stop the=C2= =A0 =C2=A0stanza on both repo server as well as on DB server=C2=A0 =C2=A0 = =C2=A0 ( $sudo -u=C2=A0 myuser=C2=A0 pgbackrest --stanza=3DMy_RepoX=C2=A0 -= -force stop)=C2=A0
2.=C2=A0 Then delete the stanza from either Re= po Server or DB server (=C2=A0 by the delete stanza option ) Is the deletio= n of the stanza needed to be performed=C2=A0only at the Repo server is enou= gh ?
3.=C2=A0 After deletion of the stanza,=C2=A0 =C2=A0delete th= e folders in the repo server=C2=A0 =C2=A0archive, backup respectively by ( = rm -f=C2=A0 =C2=A0archive=C2=A0 =C2=A0 , rm -rf backup=C2=A0 =C2=A0folders= =C2=A0 for My_RepoX ?)
4. Then execute the same=C2=A0 stanza crea= te command=C2=A0 from the reposerver=C2=A0 ?=C2=A0 ( $ sudo -u myuser pgbac= krest=C2=A0 --stanza=3DMy_RepoX=C2=A0 --log-level-console=3Dinfo stanza-cre= ate)?
5.=C2=A0 Then Check the stanza creation and config all perf= ect by=C2=A0 (=C2=A0=C2=A0sudo -u myuser pgbackrest --stanza=3DMy_RepoX=C2= =A0 --log-level-console=3Dinfo check )=C2=A0
6.=C2=A0 =C2=A0If th= e step 5 success,=C2=A0 =C2=A0schedule the full backup from the cron=C2=A0<= /div>


I hope=C2=A0 this will help me to t= ake backup afresh in case an existing pgbackrest backup=C2=A0 fails ( whate= ver the stupid reason what happened as in my case ) .=C2=A0

<= /div>
( In my case pgbackrest fails due to the scenario I faced, I mean= due to the file system full=C2=A0 and didn't notice it for 24 hours, e= ven after made space of the partition=C2=A0/root which got full,=C2=A0 late= r on the pgbackrest backups from cron scheduler unable to complete the back= up)


=C2=A0 =C2=A0If anything is wro= ng or not sufficient as in the 6 steps AFAIK (As this a live Repo Server fo= r other=C2=A0DB Clusters too, more than 10 nos, nothing should go wrong) ,= =C2=A0 =C2=A0please correct/guide me=C2=A0 =C2=A0

= Thank you,
Krishane



On Mon, Apr 21, 2025 at 9:49=E2=80=AFPM Greg Sabino Mullane <htamfids@gmail.com> wrote:


On Mon, Apr 21, 2025 at 9:03=E2=80=AFAM KK CHN <kkchn.in@gmail.com>= wrote:

ERROR: [082]: WAL segment 00000001000002200000= 0038 was not archived before the 60000ms timeout
...=C2=A0
How can I make the full backup command not to= check the=C2=A0 WAL was archived or not=C2=A0 to the repo server for atlea= st once ?

You cannot. WAL is an= integral part of the backups. You should run the pgbackrest "check&qu= ot; command and look at your Postgres logs to figure out why WAL files are = not being archived. Once that is solved, try the backup again.
Greg

--
Enterprise Postgres S= oftware Products & Tech Support

--000000000000bf46b606336b66bb--