WAL-G is a simple and efficient archival restoration tool for PostgreSQL that simplifies Continuous Archiving and Point-in-Time Recovery (PITR) and can store backups in S3, Google Cloud Storage, Azure, Swift, remote host (via SSH), or local file system.
In order to set up continuous backups, you need to do the following:
Configure wal-g
access to external storage
For example. If you use GCP GCS you should configure ENV Variables
WALG_GS_PREFIX=gs://my-bucket/walg-folder
GOOGLE_APPLICATION_CREDENTIALS=/path/to/service/account.json
Enable archiving of logs in Postgres and specify archive command and restore_command
{% code title="postgresql.conf" %}
archive_command = 'wal-g wal-push %p'
restore_command = 'wal-g wal-fetch %f %p'
{% endcode %}
For taking a backup you should run wal-g backup-push
inside the AidboxDb container
wal-g backup-push $PGDATA
wal-g backup-list
You can always restore the database from base backup if your database is corrupted.
wal-g delete retain FULL 30 --confirm
This will delete all but 30 latest backups.
WAL-G includes wal-g wal-verify
a command that checks backup integrity.
wal-g wal-verify integrity timeline # perform integrity and timeline checks
wal-g wal-verify integrity # perform only integrity check
- Configure WAL-G access to external storage
- Download backup
wal-g
backup-pull
$PGDATA
- Configure the
wal-g wal-fetch
restore command - Start Postgres
Postgres download all the missing logs and read them on start.
{% hint style="info" %} In replica mode Postgres operates in "read-only" mode, continues to receive WAL logs and lags minimum one WAL file behind main instance. {% endhint %}
You can configure incremental backups with env variable WALG_DELTA_MAX_STEPS
.
So the backup will be faster, but the recovery process will take longer.
- WAL-G is not a replacement of
pg_dump
.pg_dump
is used to create a logical dump of one or several DBs in cluster. - WAL-G doesn't schedule backup automatically.