[GENERAL] Backup strategy using 'wal_keep_segments' - Mailing list pgsql-general

From Rhhh Lin
Subject [GENERAL] Backup strategy using 'wal_keep_segments'
Date
Msg-id DB6PR1001MB1141ACC9D4BA85F44399E933AE410@DB6PR1001MB1141.EURPRD10.PROD.OUTLOOK.COM
Whole thread Raw
Responses Re: [GENERAL] Backup strategy using 'wal_keep_segments'
Re: [GENERAL] Backup strategy using 'wal_keep_segments'
List pgsql-general

Hi,


Version 9.4...

Per the PG docs, to facilitate continuous WAL archiving and PITR recovery... 
"To enable WAL archiving, set the wal_level configuration parameter to archive (or hot_standby), archive_mode to on, and specify the shell command to use in the archive_command configuration parameter."

This instruction is fine and I have a solid understanding of the implementation of these parameters, what they do and the why behind them, i.e. in order to maintain a continuous chain of database changes in the WAL stream.

My question however is this...
A colleague recently suggested that instead of implementing an 'archive_command' to push archivable WALs to a secondary location (for further backup to tape for example), we could instead persist the WAL files in their current location by setting the "wal_keep_segments" parameter to an extreme value e.g. 1000 and have the 'archive_command' do nothing.

So, something like...
wal_keep_segments=1000
archive_command='cd .'

And then periodically copy the archived WAL_files from the pg_xlog directory out to tape, removing as we go?

Is this approach feasible? Assuming obviously, we have sufficient disk space to facilitate 1000 WAL files etc.
But from a point-in-time recovery, and backup perspective - are we missing anything if we were to adopt this non-standard approach?

Regards

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: [GENERAL] parray_gin and \d errors in PG10
Next
From: Michael Paquier
Date:
Subject: Re: [GENERAL] Backup strategy using 'wal_keep_segments'