1BARMAN(5) Version 3.9.0 BARMAN(5)
2
3
4
6 barman - Backup and Recovery Manager for PostgreSQL
7
9 Barman is an administration tool for disaster recovery of PostgreSQL
10 servers written in Python and maintained by EnterpriseDB. Barman can
11 perform remote backups of multiple servers in business critical envi‐
12 ronments and helps DBAs during the recovery phase.
13
15 The system-level Barman configuration file is located at
16
17 /etc/barman.conf
18
19 or
20
21 /etc/barman/barman.conf
22
23 and is overridden on a per-user level by
24
25 $HOME/.barman.conf
26
28 The Barman configuration file is a plain INI file. There is a general
29 section called [barman] and a section [servername] for each server you
30 want to backup. Rows starting with ; are comments.
31
33 Barman supports the inclusion of multiple configuration files, through
34 the configuration_files_directory option. Included files must contain
35 only server specifications, not global configurations. If the value of
36 configuration_files_directory is a directory, Barman reads all files
37 with .conf extension that exist in that folder. For example, if you
38 set it to /etc/barman.d, you can specify your PostgreSQL servers plac‐
39 ing each section in a separate .conf file inside the /etc/barman.d
40 folder.
41
43 active When set to true (default), the server is in full operational
44 state. When set to false, the server can be used for diagnos‐
45 tics, but any operational command such as backup execution or
46 WAL archiving is temporarily disabled. When adding a new server
47 to Barman, we suggest setting active=false at first, making sure
48 that barman check shows no problems, and only then activating
49 the server. This will avoid spamming the Barman logs with er‐
50 rors during the initial setup.
51
52 archiver
53 This option allows you to activate log file shipping through
54 PostgreSQL's archive_command for a server. If set to true (de‐
55 fault), Barman expects that continuous archiving for a server is
56 in place and will activate checks as well as management (includ‐
57 ing compression) of WAL files that Postgres deposits in the in‐
58 coming directory. Setting it to false, will disable standard
59 continuous archiving for a server. Global/Server.
60
61 archiver_batch_size
62 This option allows you to activate batch processing of WAL files
63 for the archiver process, by setting it to a value > 0. Other‐
64 wise, the traditional unlimited processing of the WAL queue is
65 enabled. When batch processing is activated, the archive-wal
66 process would limit itself to maximum archiver_batch_size WAL
67 segments per single run. Integer. Global/Server.
68
69 autogenerate_manifest
70 This option enables the auto-generation of backup manifest files
71 for rsync based backups and strategies. The manifest file is a
72 JSON file containing the list of files contained in the backup.
73 It is generated at the end of the backup process and stored in
74 the backup directory. The manifest file generated follows the
75 format described in the postgesql documentation, and is compati‐
76 ble with the pg_verifybackup tool. The option is ignored if the
77 backup method is not rsync.
78
79 aws_profile
80 The name of the AWS profile to use when authenticating with AWS
81 (e.g. INI section in AWS credentials file). Global/Server.
82 aws_region
83 The name of the AWS region containing the EC2 VM and storage volumes
84 defined by snapshot_instance and snapshot_disks. Global/Server.
85
86 azure_credential
87 The credential type (either azure-cli or managed-identity) to
88 use when authenticating with Azure. If this is omitted then the
89 default Azure authentication flow will be used. Global/Server.
90
91 azure_resource_group
92 The name of the Azure resource group to which the compute in‐
93 stance and disks defined by snapshot_instance and snapshot_disks
94 belong. Global/Server. Required when the snapshot value is
95 specified for backup_method and snapshot_provider is set to
96 azure.
97
98 azure_subscription_id
99 The ID of the Azure subscription which owns the instance and
100 storage volumes defined by snapshot_instance and snapshot_disks.
101 Global/Server. Required when the snapshot value is specified
102 for backup_method and snapshot_provider is set to azure.
103
104 backup_compression
105 The compression to be used during the backup process. Only sup‐
106 ported when backup_method = postgres. Can either be unset or
107 gzip,lz4, zstd or none. If unset then no compression will be
108 used during the backup. Use of this option requires that the
109 CLI application for the specified compression algorithm is
110 available on the Barman server (at backup time) and the Post‐
111 greSQL server (at recovery time). Note that the lz4 and zstd
112 algorithms require PostgreSQL 15 (beta) or later. Global/Serv‐
113 er. Note that none compression will create an archive not com‐
114 pressed.
115
116 backup_compression_format
117 The format pg_basebackup should use when writing compressed
118 backups to disk. Can be set to either plain or tar. If unset
119 then a default of tar is assumed. The value plain can only be
120 used if the server is running PostgreSQL 15 or later and if
121 backup_compression_location is server. Only supported when
122 backup_method = postgres. Global/Server.
123
124 backup_compression_level
125 An integer value representing the compression level to use when
126 compressing backups. Allowed values depend on the compression
127 algorithm specified by backup_compression. Only supported when
128 backup_method = postgres. Global/Server.
129
130 backup_compression_location
131 The location (either client or server) where compression should
132 be performed during the backup. The value server is only al‐
133 lowed if the server is running PostgreSQL 15 or later. Glob‐
134 al/Server.
135
136 backup_compression_workers
137 The number of compression threads to be used during the backup
138 process. Only supported when backup_compression = zstd is set.
139 Default value is 0. In this case default compression behavior
140 will be used.
141
142 backup_directory
143 Directory where backup data for a server will be placed. Serv‐
144 er.
145
146 backup_method
147 Configure the method barman used for backup execution. If set
148 to rsync (default), barman will execute backup using the rsync
149 command over SSH (requires ssh_command). If set to postgres
150 barman will use the pg_basebackup command to execute the backup.
151 If set to local-rsync, barman will assume to be running on the
152 same server as the PostgreSQL instance and with the same user,
153 then execute rsync for the file system copy. If set to snap‐
154 shot, barman will use the API for the cloud provider defined in
155 the snapshot_provider option to create snapshots of disks speci‐
156 fied in the snapshot_disks option and save only the backup label
157 and metadata to its own storage. Global/Server.
158
159 backup_options
160 This option allows you to control the way Barman interacts with
161 PostgreSQL for backups. It is a comma-separated list of values
162 that accepts the following options:
163
164 • concurrent_backup (default): barman backup executes backup op‐
165 erations using concurrent backup which is the recommended
166 backup approach for PostgreSQL versions >= 9.6 and uses the
167 PostgreSQL API. concurrent_backup can also be used to perform
168 a backup from a standby server.
169
170 • exclusive_backup (PostgreSQL versions older than 15 only):
171 barman backup executes backup operations using the deprecated
172 exclusive backup approach (technically through pg_start_backup
173 and pg_stop_backup)
174
175 • external_configuration: if present, any warning regarding ex‐
176 ternal configuration files is suppressed during the execution
177 of a backup.
178
179 Note that exclusive_backup and concurrent_backup are mutually
180 exclusive. Global/Server.
181
182 bandwidth_limit
183 This option allows you to specify a maximum transfer rate in
184 kilobytes per second. A value of zero specifies no limit (de‐
185 fault). Global/Server.
186
187 barman_home
188 Main data directory for Barman. Global.
189
190 barman_lock_directory
191 Directory for locks. Default: %(barman_home)s. Global.
192
193 basebackup_retry_sleep
194 Number of seconds of wait after a failed copy, before retrying
195 Used during both backup and recovery operations. Positive inte‐
196 ger, default 30. Global/Server.
197
198 basebackup_retry_times
199 Number of retries of base backup copy, after an error. Used
200 during both backup and recovery operations. Positive integer,
201 default 0. Global/Server.
202
203 basebackups_directory
204 Directory where base backups will be placed. Server.
205
206 check_timeout
207 Maximum execution time, in seconds per server, for a barman
208 check command. Set to 0 to disable the timeout. Positive inte‐
209 ger, default 30. Global/Server.
210
211 compression
212 Standard compression algorithm applied to WAL files. Possible
213 values are: gzip (requires gzip to be installed on the system),
214 bzip2 (requires bzip2), pigz (requires pigz), pygzip (Python's
215 internal gzip compressor) and pybzip2 (Python's internal bzip2
216 compressor). Global/Server.
217
218 conninfo
219 Connection string used by Barman to connect to the Postgres
220 server. This is a libpq connection string, consult the Post‐
221 greSQL manual (https://www.postgresql.org/docs/current/stat‐
222 ic/libpq-connect.html#LIBPQ-CONNSTRING) for more information.
223 Commonly used keys are: host, hostaddr, port, dbname, user,
224 password. Server.
225
226 create_slot
227 When set to auto and slot_name is defined, Barman automatically
228 attempts to create the replication slot if not present. When
229 set to manual (default), the replication slot needs to be manu‐
230 ally created. Global/Server.
231
232 custom_compression_filter
233 Customised compression algorithm applied to WAL files. Glob‐
234 al/Server.
235
236 custom_compression_magic
237 Customised compression magic which is checked in the beginning
238 of a WAL file to select the custom algorithm. If you are using
239 a custom compression filter then setting this will prevent bar‐
240 man from applying the custom compression to WALs which have been
241 pre-compressed with that compression. If you do not configure
242 this then custom compression will still be applied but any
243 pre-compressed WAL files will be compressed again during WAL ar‐
244 chive. Global/Server.
245
246 custom_decompression_filter
247 Customised decompression algorithm applied to compressed WAL
248 files; this must match the compression algorithm. Global/Serv‐
249 er.
250
251 description
252 A human readable description of a server. Server.
253
254 errors_directory
255 Directory that contains WAL files that contain an error; usually
256 this is related to a conflict with an existing WAL file (e.g. a
257 WAL file that has been archived after a streamed one).
258
259 forward_config_path
260 Parameter which determines whether a passive node should forward
261 its configuration file path to its primary node during cron or
262 sync-info commands. Set to true if you are invoking barman with
263 the -c/--config option and your configuration is in the same
264 place on both the passive and primary barman servers. Defaults
265 to false.
266
267 gcp_project
268 The ID of the GCP project which owns the instance and storage
269 volumes defined by snapshot_instance and snapshot_disks. Glob‐
270 al/Server. Required when the snapshot value is specified for
271 backup_method and snapshot_provider is set to gcp.
272
273 gcp_zone
274 The name of the availability zone where the compute instance and
275 disks to be backed up in a snapshot backup are located. Server.
276 Required when the snapshot value is specified for backup_method
277 and snapshot_provider is set to gcp.
278
279 immediate_checkpoint
280 This option allows you to control the way PostgreSQL handles
281 checkpoint at the start of the backup. If set to false (de‐
282 fault), the I/O workload for the checkpoint will be limited, ac‐
283 cording to the checkpoint_completion_target setting on the Post‐
284 greSQL server. If set to true, an immediate checkpoint will be
285 requested, meaning that PostgreSQL will complete the checkpoint
286 as soon as possible. Global/Server.
287
288 incoming_wals_directory
289 Directory where incoming WAL files are archived into. Requires
290 archiver to be enabled. Server.
291
292 last_backup_maximum_age
293 This option identifies a time frame that must contain the latest
294 backup. If the latest backup is older than the time frame, bar‐
295 man check command will report an error to the user. If empty
296 (default), latest backup is always considered valid. Syntax for
297 this option is: "i (DAYS | WEEKS | MONTHS)" where i is an inte‐
298 ger greater than zero, representing the number of days | weeks |
299 months of the time frame. Global/Server.
300
301 last_backup_minimum_size
302 This option identifies lower limit to the acceptable size of the
303 latest successful backup. If the latest backup is smaller than
304 the specified size, barman check command will report an error to
305 the user. If empty (default), latest backup is always consid‐
306 ered valid. Syntax for this option is: "i
307 (k|Ki|M|Mi|G|Gi|T|Ti)" where i is an integer greater than zero,
308 with an optional SI or IEC suffix. k=kilo=1000, Ki=Kibi=1024
309 and so forth. Note that the suffix is case-sensitive. Glob‐
310 al/Server.
311
312 last_wal_maximum_age
313 This option identifies a time frame that must contain the latest
314 WAL file archived. If the latest WAL file is older than the
315 time frame, barman check command will report an error to the us‐
316 er. If empty (default), the age of the WAL files is not
317 checked. Syntax is the same as last_backup_maximum_age (above).
318 Global/Server. log_file
319 Location of Barman's log file. Global.
320
321 log_level
322 Level of logging (DEBUG, INFO, WARNING, ERROR, CRITICAL). Glob‐
323 al.
324
325 max_incoming_wals_queue
326 Maximum number of WAL files in the incoming queue (in both
327 streaming and archiving pools) that are allowed before barman
328 check returns an error (that does not block backups). Glob‐
329 al/Server. Default: None (disabled).
330
331 minimum_redundancy
332 Minimum number of backups to be retained. Default 0. Glob‐
333 al/Server.
334
335 network_compression
336 This option allows you to enable data compression for network
337 transfers. If set to false (default), no compression is used.
338 If set to true, compression is enabled, reducing network usage.
339 Global/Server.
340
341 parallel_jobs
342 This option controls how many parallel workers will copy files
343 during a backup or recovery command. Default 1. Global/Server.
344 For backup purposes, it works only when backup_method is rsync.
345
346 parallel_jobs_start_batch_period
347 The time period in seconds over which a single batch of jobs
348 will be started. Default: 1 second.
349
350 parallel_jobs_start_batch_size
351 Maximum number of parallel jobs to start in a single batch. De‐
352 fault: 10 jobs.
353
354 path_prefix
355 One or more absolute paths, separated by colon, where Barman
356 looks for executable files. The paths specified in path_prefix
357 are tried before the ones specified in PATH environment vari‐
358 able. Global/server.
359
360 post_archive_retry_script
361 Hook script launched after a WAL file is archived by mainte‐
362 nance. Being this a retry hook script, Barman will retry the
363 execution of the script until this either returns a SUCCESS (0),
364 an ABORT_CONTINUE (62) or an ABORT_STOP (63) code. In a post
365 archive scenario, ABORT_STOP has currently the same effects as
366 ABORT_CONTINUE. Global/Server.
367
368 post_archive_script
369 Hook script launched after a WAL file is archived by mainte‐
370 nance, after 'post_archive_retry_script'. Global/Server.
371
372 post_backup_retry_script
373 Hook script launched after a base backup. Being this a retry
374 hook script, Barman will retry the execution of the script until
375 this either returns a SUCCESS (0), an ABORT_CONTINUE (62) or an
376 ABORT_STOP (63) code. In a post backup scenario, ABORT_STOP has
377 currently the same effects as ABORT_CONTINUE. Global/Server.
378
379 post_backup_script
380 Hook script launched after a base backup, after 'post_back‐
381 up_retry_script'. Global/Server.
382
383 post_delete_retry_script
384 Hook script launched after the deletion of a backup. Being this
385 a retry hook script, Barman will retry the execution of the
386 script until this either returns a SUCCESS (0), an ABORT_CONTIN‐
387 UE (62) or an ABORT_STOP (63) code. In a post delete scenario,
388 ABORT_STOP has currently the same effects as ABORT_CONTINUE.
389 Global/Server.
390
391 post_delete_script
392 Hook script launched after the deletion of a backup, after
393 'post_delete_retry_script'. Global/Server.
394
395 post_recovery_retry_script
396 Hook script launched after a recovery. Being this a retry hook
397 script, Barman will retry the execution of the script until this
398 either returns a SUCCESS (0), an ABORT_CONTINUE (62) or an
399 ABORT_STOP (63) code. In a post recovery scenario, ABORT_STOP
400 has currently the same effects as ABORT_CONTINUE. Global/Serv‐
401 er.
402
403 post_recovery_script
404 Hook script launched after a recovery, after 'post_recov‐
405 ery_retry_script'. Global/Server.
406
407 post_wal_delete_retry_script
408 Hook script launched after the deletion of a WAL file. Being
409 this a retry hook script, Barman will retry the execution of the
410 script until this either returns a SUCCESS (0), an ABORT_CONTIN‐
411 UE (62) or an ABORT_STOP (63) code. In a post delete scenario,
412 ABORT_STOP has currently the same effects as ABORT_CONTINUE.
413 Global/Server.
414
415 post_wal_delete_script
416 Hook script launched after the deletion of a WAL file, after
417 'post_wal_delete_retry_script'. Global/Server.
418
419 pre_archive_retry_script
420 Hook script launched before a WAL file is archived by mainte‐
421 nance, after 'pre_archive_script'. Being this a retry hook
422 script, Barman will retry the execution of the script until this
423 either returns a SUCCESS (0), an ABORT_CONTINUE (62) or an
424 ABORT_STOP (63) code. Returning ABORT_STOP will propagate the
425 failure at a higher level and interrupt the WAL archiving opera‐
426 tion. Global/Server.
427
428 pre_archive_script
429 Hook script launched before a WAL file is archived by mainte‐
430 nance. Global/Server.
431
432 pre_backup_retry_script
433 Hook script launched before a base backup, after 'pre_back‐
434 up_script'. Being this a retry hook script, Barman will retry
435 the execution of the script until this either returns a SUCCESS
436 (0), an ABORT_CONTINUE (62) or an ABORT_STOP (63) code. Return‐
437 ing ABORT_STOP will propagate the failure at a higher level and
438 interrupt the backup operation. Global/Server.
439
440 pre_backup_script
441 Hook script launched before a base backup. Global/Server.
442
443 pre_delete_retry_script
444 Hook script launched before the deletion of a backup, after
445 'pre_delete_script'. Being this a retry hook script, Barman
446 will retry the execution of the script until this either returns
447 a SUCCESS (0), an ABORT_CONTINUE (62) or an ABORT_STOP (63)
448 code. Returning ABORT_STOP will propagate the failure at a
449 higher level and interrupt the backup deletion. Global/Server.
450
451 pre_delete_script
452 Hook script launched before the deletion of a backup. Glob‐
453 al/Server.
454
455 pre_recovery_retry_script
456 Hook script launched before a recovery, after 'pre_recov‐
457 ery_script'. Being this a retry hook script, Barman will retry
458 the execution of the script until this either returns a SUCCESS
459 (0), an ABORT_CONTINUE (62) or an ABORT_STOP (63) code. Return‐
460 ing ABORT_STOP will propagate the failure at a higher level and
461 interrupt the recover operation. Global/Server.
462
463 pre_recovery_script
464 Hook script launched before a recovery. Global/Server.
465
466 pre_wal_delete_retry_script
467 Hook script launched before the deletion of a WAL file, after
468 'pre_wal_delete_script'. Being this a retry hook script, Barman
469 will retry the execution of the script until this either returns
470 a SUCCESS (0), an ABORT_CONTINUE (62) or an ABORT_STOP (63)
471 code. Returning ABORT_STOP will propagate the failure at a
472 higher level and interrupt the WAL file deletion. Global/Serv‐
473 er.
474
475 pre_wal_delete_script
476 Hook script launched before the deletion of a WAL file. Glob‐
477 al/Server.
478
479 primary_checkpoint_timeout
480 This defines the amount of seconds that Barman will wait at the
481 end of a backup if no new WAL files are produced, before forcing
482 a checkpoint on the primary server.
483
484 If not set or set to 0, Barman will not force a checkpoint on
485 the primary, and wait indefinitely for new WAL files to be pro‐
486 duced.
487
488 The value of this option should be greater of the value of the
489 archive_timeout set on the primary server.
490
491 This option works only if primary_conninfo option is set, and it
492 is ignored otherwise.
493
494 primary_conninfo
495 The connection string used by Barman to connect to the primary
496 Postgres server during backup of a standby Postgres server.
497 Barman will use this connection to carry out any required WAL
498 switches on the primary during the backup of the standby. This
499 allows backups to complete even when archive_mode = always is
500 set on the standby and write traffic to the primary is not suf‐
501 ficient to trigger a natural WAL switch.
502
503 If primary_conninfo is set then it must be pointing to a primary
504 Postgres instance and conninfo must be pointing to a standby
505 Postgres instance. Furthermore both instances must share the
506 same systemid. If these conditions are not met then bar‐
507 man check will fail.
508
509 The primary_conninfo value must be a libpq connection string;
510 consult the PostgreSQL manual (https://www.post‐
511 gresql.org/docs/current/static/libpq-connect.html#LIBPQ-
512 CONNSTRING) for more information. Commonly used keys are: host,
513 hostaddr, port, dbname, user, password. Server.
514
515 primary_ssh_command
516 Parameter that identifies a Barman server as passive. In a pas‐
517 sive node, the source of a backup server is a Barman installa‐
518 tion rather than a PostgreSQL server. If primary_ssh_command is
519 specified, Barman uses it to establish a connection with the
520 primary server. Empty by default, it can also be set globally.
521
522 recovery_options
523 Options for recovery operations. Currently only supports
524 get-wal. get-wal activates generation of a basic restore_com‐
525 mand in the resulting recovery configuration that uses the bar‐
526 man get-wal command to fetch WAL files directly from Barman's
527 archive of WALs. Comma separated list of values, default empty.
528 Global/Server.
529
530 recovery_staging_path
531 A path to a location on the recovery host (either the barman
532 server or a remote host if --remote-ssh-command is also used)
533 where files for a compressed backup will be staged before being
534 uncompressed to the destination directory. Backups will be
535 staged in their own directory within the staging path according
536 to the following naming convention: "barman-staging-SERV‐
537 ER_NAME-BACKUP_ID". The staging directory within the staging
538 path will be removed at the end of the recovery process. This
539 option is required when recovering from compressed backups and
540 has no effect otherwise. Global/Server.
541
542 retention_policy
543 Policy for retention of periodic backups and archive logs. If
544 left empty, retention policies are not enforced. For redundancy
545 based retention policy use "REDUNDANCY i" (where i is an integer
546 > 0 and defines the number of backups to retain). For recovery
547 window retention policy use "RECOVERY WINDOW OF i DAYS" or "RE‐
548 COVERY WINDOW OF i WEEKS" or "RECOVERY WINDOW OF i MONTHS" where
549 i is a positive integer representing, specifically, the number
550 of days, weeks or months to retain your backups. For more de‐
551 tailed information, refer to the official documentation. De‐
552 fault value is empty. Global/Server.
553
554 retention_policy_mode
555 Currently only "auto" is implemented. Global/Server.
556
557 reuse_backup
558 This option controls incremental backup support. Global/Server.
559 Possible values are:
560
561 • off: disabled (default);
562
563 • copy: reuse the last available backup for a server and create
564 a copy of the unchanged files (reduce backup time);
565
566 • link: reuse the last available backup for a server and create
567 a hard link of the unchanged files (reduce backup time and
568 space). Requires operating system and file system support for
569 hard links.
570
571 slot_name
572 Physical replication slot to be used by the receive-wal command
573 when streaming_archiver is set to on. Default: None (disabled).
574 Global/Server.
575
576 snapshot_disks
577 A comma-separated list of disks which should be included in a
578 backup taken using cloud snapshots. Server. Required when the
579 snapshot value is specified for backup_method.
580
581 snapshot_instance
582 The name of the VM or compute instance where the storage volumes
583 are attached. Server. Required when the snapshot value is
584 specified for backup_method.
585
586 snapshot_provider
587 The name of the cloud provider which should be used to create
588 snapshots. Global/Server. Required when the snapshot value is
589 specified for backup_method. Supported values: gcp.
590
591 ssh_command
592 Command used by Barman to login to the Postgres server via ssh.
593 Server.
594
595 streaming_archiver
596 This option allows you to use the PostgreSQL's streaming proto‐
597 col to receive transaction logs from a server. If set to on,
598 Barman expects to find pg_receivewal (known as pg_receivexlog
599 prior to PostgreSQL 10) in the PATH (see path_prefix option) and
600 that streaming connection for the server is working. This acti‐
601 vates connection checks as well as management (including com‐
602 pression) of WAL files. If set to off (default) barman will re‐
603 ly only on continuous archiving for a server WAL archive opera‐
604 tions, eventually terminating any running pg_receivexlog for the
605 server. Global/Server.
606
607 streaming_archiver_batch_size
608 This option allows you to activate batch processing of WAL files
609 for the streaming_archiver process, by setting it to a value >
610 0. Otherwise, the traditional unlimited processing of the WAL
611 queue is enabled. When batch processing is activated, the ar‐
612 chive-wal process would limit itself to maximum stream‐
613 ing_archiver_batch_size WAL segments per single run. Integer.
614 Global/Server.
615
616 streaming_archiver_name
617 Identifier to be used as application_name by the receive-wal
618 command. Only available with pg_receivewal (or pg_receivexlog
619 >= 9.3). By default it is set to barman_receive_wal. Glob‐
620 al/Server.
621
622 streaming_backup_name
623 Identifier to be used as application_name by the pg_basebackup
624 command. By default it is set to barman_streaming_backup.
625 Global/Server.
626
627 streaming_conninfo
628 Connection string used by Barman to connect to the Postgres
629 server via streaming replication protocol. By default it is set
630 to conninfo. Server.
631
632 streaming_wals_directory
633 Directory where WAL files are streamed from the PostgreSQL serv‐
634 er to Barman. Requires streaming_archiver to be enabled. Serv‐
635 er.
636
637 tablespace_bandwidth_limit
638 This option allows you to specify a maximum transfer rate in
639 kilobytes per second, by specifying a comma separated list of
640 tablespaces (pairs TBNAME:BWLIMIT). A value of zero specifies
641 no limit (default). Global/Server.
642
643 wal_retention_policy
644 Policy for retention of archive logs (WAL files). Currently on‐
645 ly "MAIN" is available. Global/Server.
646
647 wals_directory
648 Directory which contains WAL files. Server.
649
651 The script definition is passed to a shell and can return any exit
652 code.
653
654 The shell environment will contain the following variables:
655
656 BARMAN_CONFIGURATION
657 configuration file used by barman
658
659 BARMAN_ERROR
660 error message, if any (only for the 'post' phase)
661
662 BARMAN_PHASE
663 'pre' or 'post'
664
665 BARMAN_RETRY
666 1 if it is a retry script (from 1.5.0), 0 if not
667
668 BARMAN_SERVER
669 name of the server
670
671 Backup scripts specific variables:
672
673 BARMAN_BACKUP_DIR
674 backup destination directory
675
676 BARMAN_BACKUP_ID
677 ID of the backup
678
679 BARMAN_PREVIOUS_ID
680 ID of the previous backup (if present)
681
682 BARMAN_NEXT_ID
683 ID of the next backup (if present)
684
685 BARMAN_STATUS
686 status of the backup
687
688 BARMAN_VERSION
689 version of Barman
690
691 Archive scripts specific variables:
692
693 BARMAN_SEGMENT
694 name of the WAL file
695
696 BARMAN_FILE
697 full path of the WAL file
698
699 BARMAN_SIZE
700 size of the WAL file
701
702 BARMAN_TIMESTAMP
703 WAL file timestamp
704
705 BARMAN_COMPRESSION
706 type of compression used for the WAL file
707
708 Recovery scripts specific variables:
709
710 BARMAN_DESTINATION_DIRECTORY
711 the directory where the new instance is recovered
712
713 BARMAN_TABLESPACES
714 tablespace relocation map (JSON, if present)
715
716 BARMAN_REMOTE_COMMAND
717 secure shell command used by the recovery (if present)
718
719 BARMAN_RECOVER_OPTIONS
720 recovery additional options (JSON, if present)
721
722 Only in case of retry hook scripts, the exit code of the script is
723 checked by Barman. Output of hook scripts is simply written in the log
724 file.
725
727 Here is an example of configuration file:
728
729 [barman]
730 ; Main directory
731 barman_home = /var/lib/barman
732
733 ; System user
734 barman_user = barman
735
736 ; Log location
737 log_file = /var/log/barman/barman.log
738
739 ; Default compression level
740 ;compression = gzip
741
742 ; Incremental backup
743 reuse_backup = link
744
745 ; 'main' PostgreSQL Server configuration
746 [main]
747 ; Human readable description
748 description = "Main PostgreSQL Database"
749
750 ; SSH options
751 ssh_command = ssh postgres@pg
752
753 ; PostgreSQL connection string
754 conninfo = host=pg user=postgres
755
756 ; PostgreSQL streaming connection string
757 streaming_conninfo = host=pg user=postgres
758
759 ; Minimum number of required backups (redundancy)
760 minimum_redundancy = 1
761
762 ; Retention policy (based on redundancy)
763 retention_policy = REDUNDANCY 2
764
766 barman (1).
767
769 Barman maintainers (in alphabetical order):
770
771 • Abhijit Menon-Sen
772
773 • Jane Threefoot
774
775 • Michael Wallace
776
777 Past contributors (in alphabetical order):
778
779 • Anna Bellandi (QA/testing)
780
781 • Britt Cole (documentation reviewer)
782
783 • Carlo Ascani (developer)
784
785 • Francesco Canovai (QA/testing)
786
787 • Gabriele Bartolini (architect)
788
789 • Gianni Ciolli (QA/testing)
790
791 • Giulio Calacoci (developer)
792
793 • Giuseppe Broccolo (developer)
794
795 • Jonathan Battiato (QA/testing)
796
797 • Leonardo Cecchi (developer)
798
799 • Marco Nenciarini (project leader)
800
801 • Niccolò Fei (QA/testing)
802
803 • Rubens Souza (QA/testing)
804
805 • Stefano Bianucci (developer)
806
808 • Homepage: <https://www.pgbarman.org/>
809
810 • Documentation: <https://docs.pgbarman.org/>
811
812 • Professional support: <https://www.enterprisedb.com/>
813
815 Barman is the property of EnterpriseDB UK Limited and its code is dis‐
816 tributed under GNU General Public License v3.
817
818 © Copyright EnterpriseDB UK Limited 2011-2023
819
821 EnterpriseDB <https://www.enterprisedb.com>.
822
823
824
825Barman User manuals October 3, 2023 BARMAN(5)