Re: pg_basebackup --incremental

Thanks, Ron. Very helpful.

On Wed, Oct 29, 2025 at 12:12 PM Ron Johnson <ronljohnsonjr(at)gmail(dot)com>
wrote:

> pgbackrest does WAL archiving for you, as seen here: $ dir
> /Database/backups/pgbackrest/ total 64 drwxr-x--- 3 nobody nobody 21
> 2024-06-08 21: 35: 11 archive/ drwxr-x--- 3 nobody nobody 21 2025-06-11 13:
> 04: 10 backup/ Thus, it obviates the need
> ZjQcmQRYFpfptBannerStart
> This Message Is From an External Sender
> This message came from outside your organization.
>
> ZjQcmQRYFpfptBannerEnd
> pgbackrest does WAL archiving for you, as seen here:
> $ dir /Database/backups/pgbackrest/
> total 64
> drwxr-x--- 3 nobody nobody 21 2024-06-08 21:35:11 archive/
> drwxr-x--- 3 nobody nobody 21 2025-06-11 13:04:10 backup/
>
> Thus, it obviates the need for the rsync commands.
>
> If, like me, you still want the WAL files to *also* be somewhere else,
> then create a cron job to rsync {repo1-path}/pgbackrest/archive to <insert
> destination here> every15 minutes or so. Add "--del" to remove the WALs
> that pgbackrest deletes when it purges the oldest saveset.
>
> On Wed, Oct 29, 2025 at 2:26 PM Sam Stearns <sam(dot)stearns(at)dat(dot)com> wrote:
>
>> Awesome. Thank you, Ron.
>>
>> We have our archive_command set to push WAL's to standby as such:
>>
>> archive_command = 'test ! -f /postgres_wal_archive/rtsstage/%f && rsync
>> -a %p /postgres_wal_archive/rtsstage/%f && rsync -a %p
>> postgres(at)10(dot)36(dot)160(dot)48:/postgres_wal_archive/rtsstage/%f'
>>
>> How does incorporating pgbackrest affect that setup?
>>
>> On Wed, Oct 29, 2025 at 10:53 AM Ron Johnson <ronljohnsonjr(at)gmail(dot)com>
>> wrote:
>>
>>> I'm certain this is all in the User Guide: $ grep -rh archive
>>> $PGDATA/postgresql. conf* archive_mode = on #archive_command = '/bin/true'
>>> archive_command = 'pgbackrest --stanza=nfs archive-push %p' Since changing
>>> archive_mode
>>> ZjQcmQRYFpfptBannerStart
>>> This Message Is From an External Sender
>>> This message came from outside your organization.
>>>
>>> ZjQcmQRYFpfptBannerEnd
>>> I'm certain this is all in the User Guide:
>>> $ grep -rh archive $PGDATA/postgresql.conf*
>>> archive_mode = on
>>> #archive_command = '/bin/true'
>>> archive_command = 'pgbackrest --stanza=nfs archive-push %p'
>>>
>>> Since changing archive_mode requires a restart, but
>>> changing archive_command just requires a reload, it's useful to have both
>>> of those archive_command lines in your config. Always keep "archive_mode =
>>> on" but disable it by setting archive_command to /bin/true (which will be a
>>> rare occurrence).
>>>
>>> On Wed, Oct 29, 2025 at 1:40 PM Sam Stearns <sam(dot)stearns(at)dat(dot)com> wrote:
>>>
>>>> Hi Ron,
>>>>
>>>> If I may, please. What are the postgres.conf parameters you set
>>>> specifically for pgBackRest?
>>>>
>>>> Thanks,
>>>>
>>>> Sam
>>>>
>>>> On Tue, Oct 28, 2025 at 3:21 PM Sam Stearns <sam(dot)stearns(at)dat(dot)com>
>>>> wrote:
>>>>
>>>>> Thanks, Ron! We'll take another look at pgBackRest.
>>>>>
>>>>> On Tue, Oct 28, 2025 at 10:52 AM Ron Johnson <ronljohnsonjr(at)gmail(dot)com>
>>>>> wrote:
>>>>>
>>>>>> On Tue, Oct 28, 2025 at 1: 43 PM Sam Stearns <sam. stearns@ dat.
>>>>>> com> wrote: Howdy, We're running version 17. 6. Would anyone be able to
>>>>>> point me to, or provide, some sample use cases / scripts / usage to deploy
>>>>>> a pg_basebackup full + --incremental
>>>>>> ZjQcmQRYFpfptBannerStart
>>>>>> This Message Is From an External Sender
>>>>>> This message came from outside your organization.
>>>>>>
>>>>>> ZjQcmQRYFpfptBannerEnd
>>>>>> On Tue, Oct 28, 2025 at 1:43 PM Sam Stearns <sam(dot)stearns(at)dat(dot)com>
>>>>>> wrote:
>>>>>>
>>>>>>> Howdy,
>>>>>>>
>>>>>>> We're running version 17.6. Would anyone be able to point me to, or
>>>>>>> provide, some sample use cases / scripts / usage to deploy a pg_basebackup
>>>>>>> full + --incremental strategy as a backup solution, please?
>>>>>>>
>>>>>>
>>>>>> The question confuses me a bit (though maybe because weekly "full",
>>>>>> and remainder "incremental" is pretty standard). PgBackRest really is
>>>>>> quite simple and easy to configure if you back up to a local mount point
>>>>>> (even when that mount point is NFS).
>>>>>>
>>>>>> This is in the "postgres" crontab:
>>>>>> 15 01 * * Sun Type=full; pgbackrest backup --stanza=nfs --type=$Type
>>>>>> &> logs/pgbackrest_$(date +"\%F_\%T")_${Type}.log
>>>>>> 15 01 * * 1-6 Type=incr; pgbackrest backup --stanza=nfs --type=$Type
>>>>>> &> logs/pgbackrest_$(date +"\%F_\%T")_${Type}.log
>>>>>>
>>>>>> And this is my /etc/pgbackrest.conf:
>>>>>> [global]
>>>>>> repo1-path=/Database/backups/pgbackrest
>>>>>> repo1-cipher-type=aes-256-cbc
>>>>>> repo1-cipher-pass=<redacted>
>>>>>> repo1-bundle=y
>>>>>> repo1-bundle-limit=20MiB
>>>>>> repo1-bundle-size=200MiB
>>>>>> [nfs]
>>>>>> pg1-path=/Database/17/data
>>>>>> resume=n
>>>>>> start-fast=y
>>>>>> stop-auto=y
>>>>>> compress-type=zst
>>>>>> log-level-console=detail
>>>>>> log-level-file=info
>>>>>> log-path=/var/lib/pgsql/logs/pgbackrest
>>>>>> retention-full=4
>>>>>> process-max=<nproc * 3/4>
>>>>>> [nfs:archive-push]
>>>>>> compress-type=zst
>>>>>>
>>>>>>
> --
> Death to <Redacted>, and butter sauce.
> Don't boil me, I'm still alive.
> <Redacted> lobster!
>

--

Samuel Stearns
Team Lead - Database
c: 971 762 6879 | o: 971 762 6879 | DAT.com

<https://www.dat.com/?utm_medium=email&utm_source=DAT_email_signature_link>