barman - Backup and Recovery Manager for PostgreSQL
barman [OPTIONS] COMMAND
Barman is an administration tool for disaster recovery of PostgreSQL servers written in Python and maintained by 2ndQuadrant. Barman can perform remote backups of multiple servers in business critical environments and helps DBAs during the recovery phase.
Show program version number and exit.
Do not output anything. Useful for cron scripts.
Show a help message and exit.
-c CONFIG, –config CONFIG
Use the specified configuration file.
Important: every command has a help option
Get any incoming xlog file (both through standard archive_command and streaming replication, where applicable) and moves them in the WAL archive for that server. If necessary, apply compression when requested by the user.
Perform maintenance tasks, such as enforcing retention policies or WAL files management.
Show all the configured servers, and their descriptions.
Show information about SERVER_NAME, including: conninfo, backup_directory, wals_directory and many more. Specify all as SERVER_NAME to show information about all the configured servers.
Show information about the status of a server, including: number of available backups, archive_command, archive_status and many more. For example:
Description: The Giggity database
Passive node: False
PostgreSQL version: 9.3.9
pgespresso extension: Not available
PostgreSQL Data directory: /srv/postgresql/9.3/data
PostgreSQL 'archive_command' setting: rsync -a %p barman@backup:/var/lib/barman/quagmire/incoming
Last archived WAL: 0000000100003103000000AD
Current WAL segment: 0000000100003103000000AE
Retention policies: enforced (mode: auto, retention: REDUNDANCY 2, WAL retention: MAIN)
No. of available backups: 2
First available backup: 20150908T003001
Last available backup: 20150909T003001
Minimum redundancy requirements: satisfied (2/1)
Show diagnostic information about SERVER_NAME, including: Ssh connection check, PostgreSQL version, configuration and backup directories, archiving process, streaming process, replication slots, etc. Specify all as SERVER_NAME to show diagnostic information about all the configured servers.
Nagios plugin compatible output
Collect diagnostic information about the server where barman is installed and all the configured servers, including: global configuration, SSH version, Python version, rsync version, as well as current configuration and status of all servers.
Perform a backup of SERVER_NAME using parameters specified in the configuration file. Specify all as SERVER_NAME to perform a backup of all the configured servers.
forces the initial checkpoint to be done as quickly as possible. Overrides value of the parameter immediate_checkpoint, if present in the configuration file.
forces to wait for the checkpoint. Overrides value of the parameter immediate_checkpoint, if present in the configuration file.
Overrides reuse_backup option behaviour. Possible values for INCREMENTAL_TYPE are:
off: do not reuse the last available backup;
copy: reuse the last available backup for a server and create a copy of the unchanged files (reduce backup time);
link: reuse the last available backup for a server and create a hard link of the unchanged files (reduce backup time and space);
link is the default target if --reuse-backup is used and INCREMENTAL_TYPE is not explicited.
Number of retries of base backup copy, after an error. Used during both backup and recovery operations. Overrides value of the parameter basebackup_retry_times, if present in the configuration file.
Same as --retry-times 0
Number of seconds of wait after a failed copy, before retrying. Used during both backup and recovery operations. Overrides value of the parameter basebackup_retry_sleep, if present in the configuration file.
Show available backups for SERVER_NAME. This command is useful to retrieve a backup ID. For example:
servername 20111104T102647 - Fri Nov 4 10:26:48 2011 - Size: 17.0 MiB - WAL Size: 100 B
In this case, *20111104T102647* is the backup ID.
Show detailed information about a particular backup, identified by the server name and the backup ID. See the Backup ID shortcuts section below for available shortcuts. For example:
Server Name : quagmire
Status : DONE
PostgreSQL Version : 90402
PGDATA directory : /srv/postgresql/9.4/main/data
Base backup information:
Disk usage : 12.4 TiB (12.4 TiB with WALs)
Incremental size : 4.9 TiB (-60.02%)
Timeline : 1
Begin WAL : 0000000100000CFD000000AD
End WAL : 0000000100000D0D00000008
WAL number : 3932
WAL compression ratio: 79.51%
Begin time : 2015-08-28 13:00:01.633925+00:00
End time : 2015-08-29 10:27:06.522846+00:00
Begin Offset : 1575048
End Offset : 13853016
Begin XLOG : CFD/AD180888
End XLOG : D0D/8D36158
No of files : 35039
Disk usage : 121.5 GiB
WAL rate : 275.50/hour
Compression ratio : 77.81%
Last available : 0000000100000D95000000E7
Retention Policy : not enforced
Previous Backup : 20150821T130001
Next Backup : - (this is the latest base backup)
List all the files in a particular backup, identified by the server name and the backup ID. See the Backup ID shortcuts section below for available shortcuts.
Possible values for TARGET_TYPE are:
data: lists just the data files;
standalone: lists the base backup files, including required WAL files;
wal: lists all the WAL files between the start of the base backup and the end of the log / the start of the following base backup (depending on whether the specified base backup is the most recent one available);
full: same as data + wal.
The default value is standalone.
Perform a rebuild of the WAL file metadata for SERVER_NAME (or every server, using the all shortcut) guessing it from the disk content. The metadata of the WAL archive is contained in the xlog.db file, and every Barman server has its own copy.
Recover a backup in a given directory (local or remote, depending on the --remote-ssh-command option settings). See the Backup ID shortcuts section below for available shortcuts.
Recover the specified timeline.
Recover to the specified time.
You can use any valid unambiguous representation (e.g: “YYYY-MM-DD HH:MM:SS.mmm”).
Recover to the specified transaction ID.
Recover to the named restore point previously created with the pg_create_restore_point(name) (for PostgreSQL 9.1 and above users).
Set target xid to be non inclusive.
Specify tablespace relocation rule.
This options activates remote recovery, by specifying the secure shell command to be launched on a remote host. This is the equivalent of the “ssh_command” server option in the configuration file for remote recovery. Example: ‘ssh postgres@db2’.
Number of retries of data copy during base backup after an error. Overrides value of the parameter basebackup_retry_times, if present in the configuration file.
Same as --retry-times 0
Number of seconds of wait after a failed copy, before retrying. Overrides value of the parameter basebackup_retry_sleep, if present in the configuration file.
Retrieve a WAL file from the xlog archive of a given server. By default, the requested WAL file, if found, is returned as uncompressed content to STDOUT. The following options allow users to change this behaviour:
destination directory where the get-wal will deposit the requested WAL
output will be compressed using gzip
output will be compressed using bzip2
peek from the WAL archive up to SIZE WAL files, starting from the requested one. ‘SIZE’ must be an integer >= 1. When invoked with this option, get-wal returns a list of zero to ‘SIZE’ WAL segment names, one per row.
Execute pg_switch_xlog() on the target server
Forces the switch by executing CHECKPOINT before pg_switch_xlog(). IMPORTANT: executing a CHECKPOINT might increase I/O load on a PostgreSQL server. Use this option with care.
Wait for one xlog file to be archived. If after a defined amount of time (default: 30 seconds) no xlog file is archived, Barman will teminate with failure exit code.
Specifies the amount of time in seconds (default: 30 seconds) the archiver will wait for a new xlog file to be archived before timing out.
Start the stream of transaction logs for a server. The process relies on pg_receivexlog to receive WAL files from the PostgreSQL servers through the streaming protocol.
stop the receive-wal process for the server
reset the status of receive-wal, restarting the streaming from the current WAL file of the server
create the physical replication slot configured with the slot_name configuration parameter
drop the physical replication slot configured with the slot_name configuration parameter