| From: | KK CHN <kkchn(dot)in(at)gmail(dot)com> |
|---|---|
| To: | Greg Sabino Mullane <htamfids(at)gmail(dot)com> |
| Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: pgbackrest after a network outage unable to perform backup [fails always] |
| Date: | 2026-02-25 07:26:55 |
| Message-ID: | CAKgGyB8roFcOii2HnAsVPyh3P_z4O3BYcO6+CamWdVFsDP1v6w@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Tue, Feb 24, 2026 at 9:20 PM Greg Sabino Mullane <htamfids(at)gmail(dot)com>
wrote:
> On Tue, Feb 24, 2026 at 5:18 AM KK CHN <kkchn(dot)in(at)gmail(dot)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. :)
>
Thank you Greg .
>
>
> Cheers,
> Greg
>
> --
> Crunchy Data - https://www.crunchydata.com
> Enterprise Postgres Software Products & Tech Support
>
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nandish Bhuva | 2026-02-25 08:28:28 | Timezone handling with timestamp without time zone columns |
| Previous Message | Ron Johnson | 2026-02-24 19:21:39 | Re: Using COPY via pg_background extension |