Ubuntu Manpage: ampgsql - Amanda Application to interface with PostgreSQL

Provided by: amanda-common_3.5.1-1ubuntu0.3_amd64

NAME

       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.

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

DIRECTORY
For restore command only, the data is recoved in that directory. Must be a unix path.

FULL-WAL
Which WAL files to archive when doing a full backup.

FULL
Backup all WAL files since the previous full backup.

INCR
Backup all WAL files since the previous backup (incr or full).

NO
Backup all WAL files required for that full backup

The default is "INCR".

GNUTAR-PATH
Path to the GNU tar executable. This option only has an effect during restore. The
default is set when Amanda is built by the --with-gnutar configure option.

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.

INCREMENTAL
Default: NO. If set to "YES", then backup only the WAL files since the previous
backup.

It reduce the size of the backup, but amanda will not be able to restore all
incrementals, the restore must be done manually.It is easier to set the dumptype bump*
parameter to force a bump at every backup.

MAX-WAL-WAIT
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.

PASSFILE
Connect using the creditials in this file. Each line should have the format
"hostname:port:database:username:password". The permissions must permit it to be read
only by the user, or the file will not be used. Only usable with Postgres 8.1 and up.

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

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

REMOVE-FULL-WAL
Default: YES. Remove all WAL files included in the full backup.

REMOVE-INCREMENTAL-WAL
Default: NO. If set to "YES" then remove all WAL files included in the incremental
backup.

STATEDIR
Directory for saving state about backups already made. The default is set when Amanda
is built by the --with-gnutar-listdir configure option.

TMPDIR
Directory to use for temporary files during the backup process. It should have enough
space to store a complete copy of the database. The default is set when Amanda is
built by the --with-tmpdir configure option.

USER
User to connect as. It must be a superuser.

VERBOSE
Do not use the --quiet output of psql.

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

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.

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

PG-PASSFILE

Connect using the creditials in this file. Each line should have the format
"hostname:port:database:username:password". The permissions must permit it to be read
only by the user, or the file will not be used. Only usable with Postgres 8.1 and up.

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

AUTHOR

       Nikolas Coukouma <atrus@zmanda.com>
           Zmanda, Inc. (http://www.zmanda.com)