AMPGSQL(8)

📦
version 3.5.4 · 8 versions
, in fedora 43

💅 AMPGSQL(8) 💅

okay bestie, welcome to the ampgsql page from the System Administration Commands section of the manual — she's niche, she's powerful, and she's about to back up your Postgres without ever taking it offline. iykyk. 🫶

✨ NAME ✨

ampgsql — the Amanda Application that lets Amanda interface with PostgreSQL. it's giving "backup bestie" energy fr fr.

🌸 DESCRIPTION 🌸

So like, Ampgsql is an Amanda Application API script. that means she is not for you to run by hand, bestie — do not just type her name into a terminal and expect magic, because that is not the vibe. 💀

What she does do is implement on-line backups of PostgreSQL databases in conjunction with WAL archiving. iconic behaviour, honestly.

📢 Note: Tablespaces are not currently supported. not me crying about it. 😭
⚠️ 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. so consider adjusting the PG-MAX-WAL-WAIT property from its default (60s) to compensate. but heads up — you will need to increase dtimeout on the server accordingly. 🕐

🦋 DISKLIST 🦋

the diskdevice must be the cluster data directory. so if it's "/var/lib/pgsql/data", you go:

HOST DISKNAME /var/lib/pgsql/data DUMPTYPE

or

HOST /var/lib/pgsql/data DUMTYPE

literally pick one, no cap. ⭐

👑 OPERATION 👑

this application implements the backup strategy described at http://www.postgresql.org/docs/current/static/continuous-archiving.html. educated queen. 📚

For a level zero (full) backup, ampgsql will:

  • 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. then they get 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. incremental slay. ✨

🎀 PROPERTIES 🎀

this section lists the amanda.conf(5) properties that control ampsql's functionality. see amanda-applications(7) for the tea on application properties and how they're configured. ☕

  • ARCHIVEDIR — the directory that WAL segment files get archived to, as specified by the archive_command in PostgreSQL'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 — the database to connect to. defaults to "template1" (which exists by default, thankfully 🫶).
  • DIRECTORY — for the restore command only; the data is recovered 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 interpreted 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 reduces 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 credentials 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. periodt.

this section lists the amanda-client.conf(5) properties that control ampsql's functionality. so here's the cute part: 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 — the directory that WAL segment files are archived to, as specified by the archive_command in PostgreSQL'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 interpreted 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 credentials 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. do not come for me if you skip the docs, bestie. 😭

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

  1. Ensure that the database server is shut down, and move the existing data directory aside.
  2. Untar the data tarball over this directory, and verify that ownership and permissions are correct.
  3. Untar all of the archive tarballs into a single directory — the archive directory.
  4. Create a recovery.conf in the data directory, owned by the proper user and with proper permissions.
  5. Add a restore_command to it, e.g.
restore_command = 'cp /path/to/archive_dir/%f "%p"'
  1. 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. main character energy tbh. 👑

⭐ 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

🔥 SEE ALSO 🔥

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

The Amanda Wiki: http://wiki.zmanda.com/ — go read it, she ate. 💅

🍓 AUTHOR 🍓

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

okay that's the whole page, bestie — written by hand with love. this icon was brought to you by Amanda 3.5.4, dated 07/23/2025. now go archive those WAL files and slay 💜✨🎀

📦 where this page comes from