MIME-Version: 1.0
References: <CAKgGyB_4kn5Sec8jtY4MfvKcaeXTPdsVQd5m8TU3GF4mGcnBMA@mail.gmail.com>
In-Reply-To: <CAKgGyB_4kn5Sec8jtY4MfvKcaeXTPdsVQd5m8TU3GF4mGcnBMA@mail.gmail.com>
From: Greg Sabino Mullane <htamfids@gmail.com>
Date: Tue, 24 Feb 2026 10:49:30 -0500
Message-ID: <CAKAnmmLMG74OpVK0TTCr0dpK_LzJPRXTKOqs-yObJ-w3cUufvQ@mail.gmail.com>
Subject: Re: pgbackrest after a network outage unable to perform backup [fails always]
To: KK CHN <kkchn.in@gmail.com>
Cc: pgsql-general <pgsql-general@postgresql.org>
Content-Type: multipart/alternative; boundary="0000000000007056c0064b93d7a5"
Archived-At: <https://www.postgresql.org/message-id/CAKAnmmLMG74OpVK0TTCr0dpK_LzJPRXTKOqs-yObJ-w3cUufvQ%40mail.gmail.com>
Precedence: bulk

--0000000000007056c0064b93d7a5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Feb 24, 2026 at 5:18=E2=80=AFAM KK CHN <kkchn.in@gmail.com> wrote:

> This goes for hours now, not yet finished. Is this normal behaviour ?
>

Yes, if there is a lot of WAL

My goal is to initiate a full backup afresh on the reposerver , so it
> doesn't matter all the old piled up WAL files
>

You will need to (carefully!) disable pgbackrest archiving, clean up the
old WAL, then start it up again. Basic sequence:

1. Set archive_command to '/bin/true'
2. Kill any existing pgbackrest processes, empty out the spool directory
3. Wait for Postgres to cleanup / recycle the WAL (speed up with a manual
CHECKPOINT)
4. Restore your archive_command to the pgbackrest version
5. Run pgbackrest check to verify WALs are being archived again
6. Run a full backup

Ideally, test these steps on a dev system, and understand why each step and
why in that order. :)


Cheers,
Greg

--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Products & Tech Support

--0000000000007056c0064b93d7a5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Tue, Feb 24, 2026 at 5:18=E2=80=AFAM K=
K CHN &lt;<a href=3D"mailto:kkchn.in@gmail.com">kkchn.in@gmail.com</a>&gt; =
wrote:</div><div class=3D"gmail_quote gmail_quote_container"><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
 rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>This goes for hou=
rs now, not yet finished. Is this normal behaviour ?</div></div></blockquot=
e><div><br></div><div>Yes, if there is a lot of WAL</div><div><br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>My goa=
l is to initiate a full backup afresh on the reposerver , so it doesn&#39;t=
 matter all the old piled up WAL files</div></div></blockquote><div><br></d=
iv><div>You will need to (carefully!) disable pgbackrest archiving, clean u=
p the old WAL, then start it up again. Basic sequence:</div><div><br></div>=
<div>1. Set archive_command to &#39;/bin/true&#39;</div><div>2. Kill any ex=
isting pgbackrest processes, empty out the spool directory</div><div>3. Wai=
t for Postgres to cleanup / recycle the WAL (speed up with a manual CHECKPO=
INT)</div><div>4. Restore your archive_command to the pgbackrest version</d=
iv><div>5. Run pgbackrest check to verify WALs are being archived again</di=
v><div>6. Run a full backup</div><div><br></div><div>Ideally, test these st=
eps on a dev system, and understand why each step and why in that order. :)=
=C2=A0</div><div><br></div><div>=C2=A0</div></div><div dir=3D"ltr" class=3D=
"gmail_signature"><div dir=3D"ltr"><div>Cheers,</div><div>Greg</div><div><b=
r></div><div>--</div><div>Crunchy Data - <a href=3D"https://www.crunchydata=
.com" target=3D"_blank">https://www.crunchydata.com</a></div><div>Enterpris=
e Postgres Software Products &amp; Tech Support</div><div><br></div></div><=
/div></div>

--0000000000007056c0064b93d7a5--