|The PostgreSQL 9.0 Reference Manual - Volume 3 - Server Administration Guide
by The PostgreSQL Global Development Group
Paperback (6"x9"), 274 pages
RRP £9.95 ($14.95)
Sales of this book support the PostgreSQL project! Get a printed copy>>>
10.3.2 Making a Base Backup
The procedure for making a base backup is relatively simple:
- Ensure that WAL archiving is enabled and working.
Connect to the database as a superuser and issue the command:
labelis any string you want to use to uniquely identify this backup operation. (One good practice is to use the full path where you intend to put the backup dump file.)
pg_start_backupcreates a backup label file, called ‘backup_label’, in the cluster directory with information about your backup, including the start time and label string. It does not matter which database within the cluster you connect to to issue this command. You can ignore the result returned by the function; but if it reports an error, deal with that before proceeding. By default,
pg_start_backupcan take a long time to finish. This is because it performs a checkpoint, and the I/O required for the checkpoint will be spread out over a significant period of time, by default half your inter-checkpoint interval (see the configuration parameter
checkpoint_completion_target). This is usually what you want, because it minimizes the impact on query processing. If you want to start the backup as soon as possible, use:
SELECT pg_start_backup('label', true);This forces the checkpoint to be done as quickly as possible.
- Perform the backup, using any convenient file-system-backup tool such as tar or cpio (not pg_dump or pg_dumpall). It is neither necessary nor desirable to stop normal operation of the database while you do this.
Again connect to the database as a superuser, and issue the command:
SELECT pg_stop_backup();This terminates the backup mode and performs an automatic switch to the next WAL segment. The reason for the switch is to arrange for the last WAL segment file written during the backup interval to be ready to archive.
Once the WAL segment files active during the backup are archived, you are
done. The file identified by
pg_stop_backup's result is the last segment that is required to form a complete set of backup files. If
pg_stop_backupdoes not return until the last segment has been archived. Archiving of these files happens automatically since you have already configured
archive_command. In most cases this happens quickly, but you are advised to monitor your archive system to ensure there are no delays. If the archive process has fallen behind because of failures of the archive command, it will keep retrying until the archive succeeds and the backup is complete. If you wish to place a time limit on the execution of
pg_stop_backup, set an appropriate
Some file system backup tools emit warnings or errors
if the files they are trying to copy change while the copy proceeds.
When taking a base backup of an active database, this situation is normal
and not an error. However, you need to ensure that you can distinguish
complaints of this sort from real errors. For example, some versions
of rsync return a separate exit code for
“vanished source files”, and you can write a driver script to
accept this exit code as a non-error case. Also, some versions of
GNU tar return an error code indistinguishable from
a fatal error if a file was truncated while tar was
copying it. Fortunately, GNU tar versions 1.16 and
later exit with
1 if a file was changed during the backup,
2 for other errors.
It is not necessary to be concerned about the amount of time elapsed
pg_start_backup and the start of the actual backup,
nor between the end of the backup and
few minutes' delay won't hurt anything. (However, if you normally run the
full_page_writes disabled, you might notice a drop
in performance between
effectively forced on during backup mode.) You must ensure that these
steps are carried out in sequence, without any possible
overlap, or you will invalidate the backup.
Be certain that your backup dump includes all of the files under the database cluster directory (e.g., ‘/usr/local/pgsql/data’). If you are using tablespaces that do not reside underneath this directory, be careful to include them as well (and be sure that your backup dump archives symbolic links as links, otherwise the restore will corrupt your tablespaces).
You can, however, omit from the backup dump the files within the cluster's ‘pg_xlog/’ subdirectory. This slight adjustment is worthwhile because it reduces the risk of mistakes when restoring. This is easy to arrange if ‘pg_xlog/’ is a symbolic link pointing to someplace outside the cluster directory, which is a common setup anyway for performance reasons.
To make use of the backup, you will need to keep all the WAL
segment files generated during and after the file system backup.
To aid you in doing this, the
creates a backup history file that is immediately
stored into the WAL archive area. This file is named after the first
WAL segment file that you need for the file system backup.
For example, if the starting WAL file is
0000000100001234000055CD the backup history file will be
named something like
0000000100001234000055CD.007C9330.backup. (The second
part of the file name stands for an exact position within the WAL
file, and can ordinarily be ignored.) Once you have safely archived
the file system backup and the WAL segment files used during the
backup (as specified in the backup history file), all archived WAL
segments with names numerically less are no longer needed to recover
the file system backup and can be deleted. However, you should
consider keeping several backup sets to be absolutely certain that
you can recover your data.
The backup history file is just a small text file. It contains the
label string you gave to
pg_start_backup, as well as
the starting and ending times and WAL segments of the backup.
If you used the label to identify the associated dump file,
then the archived history file is enough to tell you which dump file to
Since you have to keep around all the archived WAL files back to your last base backup, the interval between base backups should usually be chosen based on how much storage you want to expend on archived WAL files. You should also consider how long you are prepared to spend recovering, if recovery should be necessary--the system will have to replay all those WAL segments, and that could take awhile if it has been a long time since the last base backup.
It's also worth noting that the
makes a file named ‘backup_label’ in the database cluster
directory, which is removed by
This file will of course be archived as a part of your backup dump file.
The backup label file includes the label string you gave to
pg_start_backup, as well as the time at which
pg_start_backup was run, and the name of the starting WAL
file. In case of confusion it is
therefore possible to look inside a backup dump file and determine
exactly which backup session the dump file came from.
It is also possible to make a backup dump while the server is
stopped. In this case, you obviously cannot use
you will therefore be left to your own devices to keep track of which
backup dump is which and how far back the associated WAL files go.
It is generally better to follow the continuous archiving procedure above.
|ISBN 9781906966072||The PostgreSQL 9.0 Reference Manual - Volume 3 - Server Administration Guide||See the print edition|