Tag: backup

Waiting for PostgreSQL 17 – Add support for incremental backup.

On 20th of December 2023, Robert Haas committed patch:

Add support for incremental backup.
 
To take an incremental backup, you use the new replication command
UPLOAD_MANIFEST to upload the manifest for the prior backup. This
prior backup could either be a full backup or another incremental
backup.  You then use BASE_BACKUP with the INCREMENTAL option to take
the backup.  pg_basebackup now has an --incremental=PATH_TO_MANIFEST
option to trigger this behavior.
 
An incremental backup is like a regular full backup except that
some relation files are replaced with files with names like
INCREMENTAL.${ORIGINAL_NAME}, and the backup_label file contains
additional lines identifying it as an incremental backup. The new
pg_combinebackup tool can be used to reconstruct a data directory
from a full backup and a series of incremental backups.
 
Patch by me.  Reviewed by Matthias van de Meent, Dilip Kumar, Jakub
Wartak, Peter Eisentraut, and Álvaro Herrera. Thanks especially to
Jakub for incredibly helpful and extensive testing.
 
Discussion: http://postgr.es/m/CA+TgmoYOYZfMCyOXFyC-P+-mdrZqm5pP2N7S-r0z3_402h9rsA@mail.gmail.com

Continue reading Waiting for PostgreSQL 17 – Add support for incremental backup.

Waiting for PostgreSQL 10 – Rename “pg_xlog” directory to “pg_wal”.

On 20th of October, Robert Haas committed patch:

Rename "pg_xlog" directory to "pg_wal".
 
"xlog" is not a particularly clear abbreviation for "write-ahead log",
and it sometimes confuses users into believe that the contents of the
"pg_xlog" directory are not critical data, leading to unpleasant
consequences.  So, rename the directory to "pg_wal".
 
This patch modifies pg_upgrade and pg_basebackup to understand both
the old and new directory layouts; the former is necessary given the
purpose of the tool, while the latter merely avoids an unnecessary
backward-compatibility break.
 
We may wish to consider renaming other programs, switches, and
functions which still use the old "xlog" naming to also refer to
"wal".  However, that's still under discussion, so let's do just this
much for now.
 
Discussion: CAB7nPqTeC-8+zux8_-4ZD46V7YPwooeFxgndfsq5Rg8ibLVm1A@mail.gmail.com
 
Michael Paquier

discussion link

Continue reading Waiting for PostgreSQL 10 – Rename “pg_xlog" directory to “pg_wal".

I have PostgreSQL, loaded some data, and have app using it. Now what?

I had to deal with this question, or some version of it, quite a few times. So, decided to write a summary on what one could (or should) do, after data is in database, and application is running. Namely – setup some kind of replication and backups.

What to use, how, and why? This is what this post is all about.

Continue reading I have PostgreSQL, loaded some data, and have app using it. Now what?

Waiting for 9.4 – Add recovery_target=’immediate’ option.

On 25th of January, Heikki Linnakangas committed patch:

Add recovery_target='immediate' option.
 
This allows ending recovery as a consistent state has been reached. Without
this, there was no easy way to e.g restore an online backup, without
replaying any extra WAL after the backup ended.
 
MauMau and me.

Continue reading Waiting for 9.4 – Add recovery_target='immediate' option.

Win a book contest – PostgreSQL Backup and Restore How-to

pg backup book cover

Around the time that Xzilla wrote about the book, Packt contacted me and asked for a review.

Since I generally don't really read technical books, I declined the offer, but Sandy from Packt was very persistent, and asked if I could inform about book giveaway contest.

The book is definitely PostgreSQL related, and Xzilla suggested to check it out, so here it goes:

Continue reading Win a book contest – PostgreSQL Backup and Restore How-to

OmniPITR – update

As of yesterday OmniPITR got following changes/fixes:

  1. Fixed bug which caused immediate finish request be treated the same as smart finish request.
  2. Fixed problem with using omnipitr-backup-slave on PostgreSQL 9.0 slave, which is using streaming replication.
  3. Added option to omnipitr-restore, so that you can now use it for streaming-replication slaves

I'm very ashamed of the first thing (smart/immediate finish request), as it was simply my lack of test.

Second thing – the problem was that with streaming replication slave behaves a bit differently than normally, and so the backup procedure had to be modified.

As for third – restore command in streaming replication environment has to behave differently than normal restore command – i.e. it should finish, with error, as soon as it will be called for wal file that does not exist in wal archive. Which is direct opposite of what should be done normally.

Now, omnipitr-restore got switch (-sr) to make it work correctly in SR situation.

Links for svn/docs are listed on project page.

Waiting for 9.1 – pg_basebackup

On 23rd of January, Magnus Hagander committed patch which adds:

Add pg_basebackup tool for streaming base backups
 
This tool makes it possible to do the pg_start_backup/
copy files/pg_stop_backup step in a single command.
 
There are still some steps to be done before this is a
complete backup solution, such as the ability to stream
the required WAL logs, but it's still usable, and
could do with some buildfarm coverage.
 
In passing, make the checkpoint request optionally
fast instead of hardcoding it.
 
Magnus Hagander, reviewed by Fujii Masao and Dimitri Fontaine

Continue reading Waiting for 9.1 – pg_basebackup