If you are using tablespaces, you may be wondering if and how Barman manages them. Barman fully supports tablespaces, including their relocation at recovery time, through the --tablespace runtime option. For information on the syntax of the relocation rules, type any of the following commands:
- barman help recover
- man barman
In this recipe, we have seen only one use case, which covers remote recovery. As mentioned before, however, Barman also allows DBAs to recover instances of PostgreSQL on the same server as Barman.
This is called local recovery. For local recovery, you will need to have installed the binaries and libraries of the same version of PostgreSQL on the Barman server as the backup file you want to restore.
You can dedicate a directory in Barman for local recovery, to be used as the destination directory for your recover commands.
A typical use case for local recovery is to restore the situation of a PostgreSQL server at a specific point in time, usually before an unintentional action such as the DROP of a table.
Barman supports PITR, as explained in the Recovery to a point in time recipe, through three options that define the recovery target:
- --target-time TARGET_TIME: The target is a timestamp
- --target-xid TARGET_XID: The target is a transaction ID
- --target-name TARGET_NAME: The target is a named restore point, previously created with the pg_create_restore_point(name) function
When executed with one of these options, Barman will generate the recovery.conf file for you. Advanced users might want to activate the hot standby facility and take advantage of the recovery_target_action option (by default set to pause, and effective only if hot_standby is enabled in the postgresql.conf file).
This will allow you to check whether the database is in the desired state or not. If not, you can stop the server, change the recovery target time, and start it again. Repeat this operation until you reach your goal, keeping in mind that PostgreSQL can only roll forward WAL files (they are called REDO operations for a reason).
You can then follow the instructions outlined in the Recovery of a dropped/damaged table recipe to restore the objects in the primary database.
At the end of any recovery operation, remember to stop the running of local servers and remove recovered instances (even though this is not mandatory, as Barman uses rsync and will be able to perform an incremental copy of the files where applicable).
Another interesting feature of Barman is the get-wal command, which transforms Barman in an infinite basin of WAL files. Instead of copying WAL files before the actual start of the server, you can let PostgreSQL pull the required WAL files on demand at recovery time, via restore_command. For further information, look at the barman-cli package, specifically the barman-wal-restore script at https://github.com/2ndquadrant-it/barman-cli
As a final note for this recipe, another important use case for Barman is to regularly create copies of the server to be used for business intelligence purposes or even staging/development. These environments do not normally require a strict up-to-date situation and are very often happy to work on a snapshot of the previous day. A typical workflow for this use case can be like this:
- Stop the PostgreSQL server on the BI/staging server.
- Issue a full remote recovery operation of the desired backup from Barman to the BI server (rsync will use the existing data directory for incremental copy).
- Start the PostgreSQL server on the BI/staging server.
This recipe has covered only a few aspects of the recovery process in Barman. For further and more detailed information, refer to:
- The official documentation for Barman, publicly available at http://docs.pgbarman.org/
- The mailing list for community support at http://www.pgbarman.org/support/
- The Barman section of our blog at https://blog.2ndquadrant.com/tag/barman.