ampgsql — Amanda Application to interface with PostgreSQL
Ampgsql is an Amanda Application API script. It should not be run by users directly. It implements on-line backups of PostgreSQL databases in conjunction with WAL archiving.
Tablespaces are not currently supported.
On versions of PostgreSQL earlier than 8.2, if the database is
quiet during a full backup, then the backup may not complete until
enough database activity takes place to trigger the archiving of the
current WAL file. Consider adjusting the PG-MAX-WAL-WAIT property from
its default (60s) to compensate. Note that you will need to increase
dtimeout
on the server accordingly.
This application implements the backup strategy described in http://www.postgresql.org/docs/current/static/continuous-archiving.html. For a level zero (full) backup, ampgsql:
execute PG_START_BACKUP()
dump the data directory
execute PG_STOP_BACKUP()
wait for the final WAL file to be archived
back up the required WAL files
optionally delete WAL files that are no longer necessary
The two dumps are made with GNU Tar, to data_dir.tar
and
archive_dir
, respectively. They are then combined into a
single tar file.
A level N backup creates a single tar file containing all WAL files since the previous level N-1 backup.
This section lists the amanda.conf(5) properties that control ampsql's functionality. See amanda-applications(7) for information on application properties and how they are configured.
This section lists the amanda-client.conf(5) properties that control ampsql's functionality. If a property is prefixed with the diskname and an underscore, then it will be used when that diskname is being backed up. For example, if the properties PG-DATADIR and foo-PG-DATADIR are set, the value of PG-DATADIR will be used when bar and baz are being backed up, but foo-PG-DATADIR will be used when foo is being backed up. Disknames are specified in the disklist(5).
The maximum amount of time to wait for PG_STOP_BACKUP to archive a WAL file. In versions of PostgreSQL before 8.2, PG_STOP_BACKUP does not automatically archive the latest WAL file, so a quiet database may wait a very long time before archiving the WAL file. Default: 60 seconds. Set to 0 to wait forever.
Read the postgres documentation carefully before attempting a recovery. This section is only a rough guide to the process.
The data recovered from a postgres backup consists of a data tarball and one or more archive tarballs. The data contains the state of the database at the time the full backup was performed, and the archive tarballs contain postgres WAL files that must be re-run to generate a consistent state.
Ensure that the database server is shut down, and move the existing data
directory aside. Untar the data tarball over this directory, and verify
that ownership and permissions are correct. Untar all of the archive
tarballs into a single directory - the archive directory. Create a
recovery.conf
in the data directory, owned by the
proper user and with proper permissions. Add a
restore_command to it, e.g.,
restore_command = 'cp /path/to/archive_dir/%f "%p"'
Start the database server, and examine the logs to track the process of
the recovery. When the recovery is complete, the server will transition
into a running state, and will move the recovery.conf
file aside so that it will not attempt a recovery on the next
invocation.
amanda(8), amanda.conf(5), amanda-client.conf(5), amanda-applications(7)
The Amanda Wiki: http://wiki.zmanda.com/
This manual page was written by
.