ampgsql: Amanda application to interface with postgresql

DESCRIPTION

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.

Note

Tablespaces are not currently supported.

Note

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.

DISKLIST

The diskdevice must be the cluster data directory, if it is "/var/lib/pgsql/data":

  HOST DISKNAME /var/lib/pgsql/data DUMPTYPE
or
  HOST /var/lib/pgsql/data DUMTYPE

OPERATION

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.

PROPERTIES

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.

ARCHIVEDIR

Directory that WAL segment files are archived to, as specified by the archive_command in PosgreSQL's postgresql.conf. The amanda user on the client must have at least read and execute permission on this directory, and preferably write. Without write permission, Amanda cannot clean up expired WAL and backup files.

CLEANUPWAL

Whether or not to remove old WAL segment files during base backups. Defaults to yes.

Database to connect to. Defaults to "template1" (which exists by default).

CLIENT PROPERTIES

Client properties are deprecated. All properties should be set in the dumptype.

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).

PG-ARCHIVEDIR

PG-CLEANUPWAL

Whether or not to remove old WAL segment files during base backups. Defaults to yes.

PG-DATADIR

Cluster data directory

PG-DB

Database to connect to. Defaults to "template1" (which exists by default).

PG-HOST

Host to connect to. If it starts with "/" it will be interepreted as a directory that holds the socket file. PostgreSQL defaults to /tmp.

PG-MAX-WAL-WAIT

PG-PASSFILE

PG-PASSWORD

Password to use when connecting. Deprecated in favor of passfiles.

PG-PORT

The TCP port to connect to, or the suffix of the socket file. PostgreSQL defaults to 5432.

PG-USER

User to connect as. It must be a superuser.

PSQL-PATH

Path to the psql binary. If not specified, the PATH environment variable will be searched.

RECOVERY

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.

EXAMPLE

In amanda.conf:

define application app_ampgsql {
  plugin "ampgsql"
  property "HOST" "localhost"
  property "ARCHIVEDIR" "/tmp/archivedir"
  property "PASSFILE" "/etc/amanda/ampgsql.passwd"
}
define dumptype dump_ampgsql {
  global
  program "APPLICATION"
  application app_ampgsql
}

The disklist file:

  localhost /var/lib/pgsql/data dump_ampgsql
or
  localhost postgres /var/lib/pgsql/data dump_ampgsql

RELATED TO ampgsql…

amanda(8), amanda.conf(5), amanda-client.conf(5), amanda-applications(7)

The Amanda Wiki: : http://wiki.zmanda.com/

AUTHOR

Nikolas Coukouma <[email protected]>

Zmanda, Inc. (http://www.zmanda.com)

ampgsql (8)