ampgsql

AMPGSQL(8)               System Administration Commands               AMPGSQL(8)



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.

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.

       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.

       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.

       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.

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.

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

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

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



Amanda 3.3.3                       01/10/2013                         AMPGSQL(8)