public inbox for [email protected]
help / color / mirror / Atom feedRe: pgbackrest after a network outage unable to perform backup [fails always]
2+ messages / 2 participants
[nested] [flat]
* Re: pgbackrest after a network outage unable to perform backup [fails always]
@ 2026-02-24 15:49 Greg Sabino Mullane <[email protected]>
2026-02-25 07:26 ` Re: pgbackrest after a network outage unable to perform backup [fails always] KK CHN <[email protected]>
0 siblings, 1 reply; 2+ messages in thread
From: Greg Sabino Mullane @ 2026-02-24 15:49 UTC (permalink / raw)
To: KK CHN <[email protected]>; +Cc: pgsql-general
On Tue, Feb 24, 2026 at 5:18 AM KK CHN <[email protected]> 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
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: pgbackrest after a network outage unable to perform backup [fails always]
2026-02-24 15:49 Re: pgbackrest after a network outage unable to perform backup [fails always] Greg Sabino Mullane <[email protected]>
@ 2026-02-25 07:26 ` KK CHN <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: KK CHN @ 2026-02-25 07:26 UTC (permalink / raw)
To: Greg Sabino Mullane <[email protected]>; +Cc: pgsql-general
On Tue, Feb 24, 2026 at 9:20 PM Greg Sabino Mullane <[email protected]>
wrote:
> On Tue, Feb 24, 2026 at 5:18 AM KK CHN <[email protected]> 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. :)
>
Thank you Greg .
>
>
> Cheers,
> Greg
>
> --
> Crunchy Data - https://www.crunchydata.com
> Enterprise Postgres Software Products & Tech Support
>
>
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2026-02-25 07:26 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-02-24 15:49 Re: pgbackrest after a network outage unable to perform backup [fails always] Greg Sabino Mullane <[email protected]>
2026-02-25 07:26 ` KK CHN <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox