avahi.service

title: avahi.service(5)

summary: avahi-daemon static service file

text:
# avahi.service(5)

## NAME
avahi.service - avahi-daemon static service file

## SYNOPSIS
/etc/avahi/services/*.service

## DESCRIPTION
/etc/avahi/services/*.service are XML fragments containing static DNS-SD service data. Every service file can contain multiple service definitions which share the same name. This is useful for publishing service data for services which implement multiple protocols. (i.e. a printer implementing _ipp._tcp and _printer._tcp)

## XML TAGS
<service-group> The document tag of avahi service files. Should contain one <name> and one or more <service> elements.

<name replace-wildcards="yes|no"> The service name. If replace-wildcards is "yes", any occurrence of the string "%h" will be replaced by the local host name. This can be used for service names like "Remote Terminal on %h". If replace-wildcards is not specified, defaults to "no".

<service protocol="ipv4|ipv6|any"> Contains the service information for exactly one service type. Should contain one <type> and one <port> element. Optionally it may contain one <domain-name>, one <host-name>, any number of <subtype> and any number of <txt-record> elements. The attribute protocol specifies the protocol to advertise the service on. If any is used (which is the default), the service will be advertised on both IPv4 and IPv6.

<type> Contains the DNS-SD service type for this service. e.g. "_http._tcp".

<subtype> Contains an additional DNS-SD service subtype for this service. e.g. "_anon._sub._ftp._tcp".

<domain-name> The domain name this service should be registered. If omitted defaults to the default domain of the avahi daemon. (probably .local)

<host-name> The host name of the host that provides this service. This should be a host that is resolvable by multicast or unicast DNS. Please note that you need to specify a fully-qualified domain name (FQDN) here, i.e. .local is not appended implicitly! The host name doesn't need to be part of the domain specified in <domain-name>. See avahi.hosts(5) for more information how to publish additional host name mappings.

<port> The IP port number the service listens on.

<txt-record value-format="text|binary-hex|binary-base64"> DNS-SD TXT record data. If value-format is "text", the value of the TXT record is taken verbatim. If value-format is "binary-hex" then the value of TXT record is decoded by taking pairs of characters after the "=" char and interpreting them as the textual representation of the two-digit hexadecimal number. Both uppercase and lowercase hexadecimal digits are allowed. The 0x or 0X prefix is not allowed. This requires the length of the value to be even. If value-format is "binary-base64" then the value of TXT record is decoded with a base64 decoder. The character set used is A-Za-z0-9+/. This requires the length of the value to be a multiple of 4, with "=" as padding at the end. If value-format is not specified, defaults to "text". Examples (all the values are decoded to the string "value" without quotes):

<txt-record>key=value</txt-record>

<txt-record value-format="text">key=value</txt-record>

<txt-record value-format="binary-hex">key=76616c7565</txt-record>

<txt-record value-format="binary-base64">key=dmFsdWU=</txt-record>

## AUTHORS
The Avahi Developers <avahi (at) lists (dot) freedesktop (dot) org>; Avahi is available from http://avahi.org/

## SEE ALSO
avahi-daemon(8), avahi.hosts(5)

## COMMENTS
This man page was written using xml2man(1) by Oliver Kurth.


avr-gdbinit

package: avr-gdb

title: avr-gdbinit(5)

summary: GDB initialization scripts

text:
# avr-gdbinit(5)

## NAME
gdbinit - GDB initialization scripts

## SYNOPSIS
~/.gdbinit

./.gdbinit

## DESCRIPTION
These files contain GDB commands to automatically execute during GDB startup. The lines of contents are canned sequences of commands, described in the GDB manual in node "Sequences" -- shell command "info -f gdb -n Sequences".

Please read more in the GDB manual in node "Startup" -- shell command "info -f gdb -n Startup".

(not enabled with "--with-system-gdbinit" during compilation)

System-wide initialization file. It is executed unless user specified GDB option "-nx" or "-n". See more in the GDB manual in node "System-wide configuration" -- shell command "info -f gdb -n 'System-wide configuration'".

~/.gdbinit

User initialization file. It is executed unless user specified GDB options "-nx", "-n" or "-nh".

./.gdbinit

Initialization file for current directory. It may need to be enabled with GDB security command "set auto-load local-gdbinit". See more in the GDB manual in node "Init File in the Current Directory" -- shell command "info -f gdb -n 'Init File in the Current Directory'".

## SEE ALSO
gdb(1), "info -f gdb -n Startup"

The full documentation for GDB is maintained as a Texinfo manual. If the "info" and "gdb" programs and GDB's Texinfo documentation are properly installed at your site, the command

```
        info gdb
```

should give you access to the complete manual.

Using GDB: A Guide to the GNU Source-Level Debugger, Richard M. Stallman and Roland H. Pesch, July 1991.

## COPYRIGHT
Copyright (c) 1988-2018 Free Software Foundation, Inc.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with the Invariant Sections being "Free Software" and "Free Software Needs Free Documentation", with the Front-Cover Texts being "A GNU Manual," and with the Back-Cover Texts as in (a) below.

(a) The FSF's Back-Cover Text is: "You are free to copy and modify this GNU Manual. Buying copies from GNU Press supports the FSF in developing GNU and promoting software freedom."


awesomerc

package: awesome

title: awesomerc(5)

text:
# awesomerc(5)

## NAME
awesomerc - Configuration file for the awesome window manager

## SYNOPSIS
awesome looks for a configuration file in this order:

•$XDG_CONFIG_HOME/awesome/rc.lua

•$HOME/.config/awesome/rc.lua

•$XDG_CONFIG_DIRS/awesome/rc.lua

## DESCRIPTION
The rc.lua file contains configuration information for awesome. It can be used to configure the behavior and look of awesome in a variety of ways. It can be assimilated as a Lua program/script run at startup by awesome. Therefore, it should use the awesome Lua API described in the API section. This file is read at startup.

## AWESOME LUA API
Documentation for the Lua API can be found in the luadoc directory.

## COLORS FORMAT
The color format in awesome is either a standard X color name (blue, darkblue, lightred, etc) or a hexadecimal formatted color (#rrggbb or #rrggbbaa). By using the hexadecimal format, you can also specify an alpha channel: that means that #00ff00 will draw pure green, but #00ff00aa will set the alpha channel to ‘aa’ and will blend the green with the color under it.

## TEXT FORMAT
You can use Pango markup in a text string. This allows formatting the text rendered inside widgets. Pango markup documentation can be found in the Pango documentation at <http://library.gnome.org/devel/pango/stable/PangoMarkupFormat.html>.

A Pango markup example: ....

## SEE ALSO
awesome(1) awesome-client(1)

## AUTHORS
Written by Julien Danjou <julien@danjou.info>.

## WWW
<https://awesomewm.org>


title: b4(5)

text:
# b4(5)

## NAME
B4 - Work with code submissions in a public-inbox archive

## SYNOPSIS
b4 {mbox,am,shazam,pr,diff,ty,kr,prep,send,trailers} [options]

## DESCRIPTION
This is a helper utility to work with patches and pull requests made available via a public-inbox archive like lore.kernel.org. It is written to make it easier to participate in a patch-based workflows, like those used in the Linux kernel development.

The name "b4" was chosen for ease of typing and because B-4 was the precursor to Lore and Data in the Star Trek universe.

Full documentation is available on https://b4.docs.kernel.org/.

## SUBCOMMANDS
Maintainer-oriented:

- mbox: Download a thread as an mbox file

- am: Create an mbox file that is ready to git-am

- shazam: Apply patch series to git repositories

- pr: Work with pull requests

- diff: Show range-diff style diffs between patch versions

- ty: Create templated replies for processed patches and pull requests

- kr: (EXPERIMENTAL) Operate on patatt-compatible keyrings

Contributor-oriented:

- prep: (EXPERIMENTAL) prepare your series for submission

- send: (EXPERIMENTAL) send your series for review on distribution lists

- trailers: (EXPERIMENTAL) retrieve and apply code-review trailers

## OPTIONS
-h, --help

show this help message and exit

-d, --debug

Add more debugging info to the output (default: False)

-q, --quiet

Output critical information only (default: False)

-n, --no-interactive

Do not ask any interactive questions (default: False)

--offline-mode

Do not perform any network queries (default: False)

--no-stdin

Disable TTY detection for stdin (default: False)

## SUBCOMMAND OPTIONS

### b4 mbox
This command allows retrieving entire threads from a remote public-inbox instance. The resulting mbox file can then be opened with most MUA clients for actions like replying to conversations or reviewing patch submissions.

usage:

b4 mbox [-h] [-p USEPROJECT] [-m LOCALMBOX] [-C] [-o OUTDIR] [-c] [-n WANTNAME] [-M] [-f] [msgid]

positional arguments:

msgid Message ID to process, or pipe a raw message

options:

-h, --help

show this help message and exit

-p USEPROJECT, --use-project USEPROJECT

Use a specific project instead of default (linux-mm, linux-hardening, etc)

-m LOCALMBOX, --use-local-mbox LOCALMBOX

Instead of grabbing a thread from lore, process this mbox file (or - for stdin)

--stdin-pipe-sep STDIN_PIPE_SEP

When accepting messages on stdin, split using this pipe separator string

-C, --no-cache

Do not use local cache

-o OUTDIR, --outdir OUTDIR

Output into this directory (or use - to output mailbox contents to stdout)

-c, --check-newer-revisions

Check if newer patch revisions exist

-n WANTNAME, --mbox-name WANTNAME

Filename to name the mbox destination

-M, --save-as-maildir

Save as maildir (avoids mbox format ambiguities)

-f, --filter-dupes

When adding messages to existing maildir, filter out duplicates

Example: b4 mbox 20200313231252.64999-1-keescook@chromium.org

### b4 am
This command allows retrieving threads from a public-inbox instance and preparing them for applying to a git repository using the "git am" command. It will automatically perform the following operations:

- pick the latest submitted version of the series (it can check for newer threads using -c as well)

- check DKIM signatures and patatt attestation on all patches and code review messages

- collate all submitted code-review trailers (Reviewed-by, Acked-by, etc) and put them into the commit message

- add your own Signed-off-by trailer (with -s)

- reroll series from partial updates (e.g. someone submits a v2 of a single patch instead of rerolling the entire series)

- guess where in the tree history the patches belong, if the exact commit-base is not specified (with -g)

- prepare the tree for a 3-way merge (with -3)

- cherry-pick a subset of patches from a large series (with -P)

usage:

b4 am [-h] [-p USEPROJECT] [-m LOCALMBOX] [-C] [-o OUTDIR] [-c] [-n WANTNAME] [-M] [-v WANTVER] [-t] [-S] [-T] [-s] [-l] [-P CHERRYPICK] [--cc-trailers] [--no-parent] [--allow-unicode-control-chars] [-Q] [-g] [-b GUESSBRANCH [GUESSBRANCH ...]] [--guess-lookback GUESSDAYS] [-3] [--no-cover] [--no-partial-reroll] [msgid]

positional arguments:

msgid Message ID to process, or pipe a raw message

options:

-h, --help

show this help message and exit

-p USEPROJECT, --use-project USEPROJECT

Use a specific project instead of default (linux-mm, linux-hardening, etc)

-m LOCALMBOX, --use-local-mbox LOCALMBOX

Instead of grabbing a thread from lore, process this mbox file (or - for stdin)

--stdin-pipe-sep STDIN_PIPE_SEP

When accepting messages on stdin, split using this pipe separator string

-C, --no-cache

Do not use local cache

-o OUTDIR, --outdir OUTDIR

Output into this directory (or use - to output mailbox contents to stdout)

-c, --check-newer-revisions

Check if newer patch revisions exist

-n WANTNAME, --mbox-name WANTNAME

Filename to name the mbox destination

-M, --save-as-maildir

Save as maildir (avoids mbox format ambiguities)

-v WANTVER, --use-version WANTVER

Get a specific version of the patch/series

-t, --apply-cover-trailers

Apply trailers sent to the cover letter to all patches

-S, --sloppy-trailers

Apply trailers without email address match checking

-T, --no-add-trailers

Do not add or sort any trailers

-s, --add-my-sob

Add your own signed-off-by to every patch

-l, --add-link

Add a Link: with message-id lookup URL to every patch

-P CHERRYPICK, --cherry-pick CHERRYPICK

Cherry-pick a subset of patches (e.g. "-P 1-2,4,6-", "-P _" to use just the msgid specified, or "-P globbing" to match on commit subject)

--cc-trailers

Copy all Cc'd addresses into Cc: trailers

--no-parent

Break thread at the msgid specified and ignore any parent messages

--allow-unicode-control-chars

Allow unicode control characters (very rarely legitimate)

-Q, --quilt-ready

Save patches in a quilt-ready folder

-g, --guess-base

Try to guess the base of the series (if not specified)

-b GUESSBRANCH [GUESSBRANCH ...], --guess-branch GUESSBRANCH [GUESSBRANCH ...]

When guessing base, restrict to this branch (use with -g)

--guess-lookback GUESSDAYS

When guessing base, go back this many days from the patch date (default: 2 weeks)

-3, --prep-3way

Prepare for a 3-way merge (tries to ensure that all index blobs exist by making a fake commit range)

--no-cover

Do not save the cover letter (on by default when using -o -)

--no-partial-reroll

Do not reroll partial series when detected

Example: b4 am 20200313231252.64999-1-keescook@chromium.org

### b4 shazam
This is very similar to b4 am, but will also apply patches directly to the current git tree using git am. Alternatively, when used with -H, it can fetch the patch series into FETCH_HEAD as if it were a pull request, so it can be reviewed and merged. In this case, the cover letter is used as a template for the merge commit.

If you want to automatically invoke git-merge, you can use -M instead of -H.

usage:

b4 shazam [-h] [-p USEPROJECT] [-m LOCALMBOX] [-C] [-v WANTVER] [-t] [-S] [-T] [-s] [-l] [-P CHERRYPICK] [--cc-trailers] [--no-parent] [--allow-unicode-control-chars] [-H | -M] [--guess-lookback GUESSDAYS] [msgid]

positional arguments:

msgid Message ID to process, or pipe a raw message

options:

-h, --help

show this help message and exit

-p USEPROJECT, --use-project USEPROJECT

Use a specific project instead of default (linux-mm, linux-hardening, etc)

-m LOCALMBOX, --use-local-mbox LOCALMBOX

Instead of grabbing a thread from lore, process this mbox file (or - for stdin)

--stdin-pipe-sep STDIN_PIPE_SEP

When accepting messages on stdin, split using this pipe separator string

-C, --no-cache

Do not use local cache

-v WANTVER, --use-version WANTVER

Get a specific version of the patch/series

-t, --apply-cover-trailers

Apply trailers sent to the cover letter to all patches

-S, --sloppy-trailers

Apply trailers without email address match checking

-T, --no-add-trailers

Do not add or sort any trailers

-s, --add-my-sob

Add your own signed-off-by to every patch

-l, --add-link

Add a Link: with message-id lookup URL to every patch

-P CHERRYPICK, --cherry-pick CHERRYPICK

Cherry-pick a subset of patches (e.g. "-P 1-2,4,6-", "-P _" to use just the msgid specified, or "-P globbing" to match on commit subject)

--cc-trailers

Copy all Cc'd addresses into Cc: trailers

--no-parent

Break thread at the msgid specified and ignore any parent messages

--allow-unicode-control-chars

Allow unicode control characters (very rarely legitimate)

-H, --make-fetch-head

Attempt to treat series as a pull request and fetch it into FETCH_HEAD

-M, --merge

Attempt to merge series as if it were a pull request (execs git-merge)

--guess-lookback GUESSDAYS

(use with -H or -M) When guessing base, go back this many days from the patch date (default: 3 weeks)

Example: b4 shazam -H 20200313231252.64999-1-keescook@chromium.org

### b4 pr
This command is for working with pull requests submitted using git-request-pull.

usage:

command.py pr [-h] [-g GITDIR] [-b BRANCH] [-c] [-e] [-o OUTMBOX] [msgid]

positional arguments:

msgid Message ID to process, or pipe a raw message

optional arguments:

-h, --help

show this help message and exit

-g GITDIR, --gitdir GITDIR

Operate on this git tree instead of current dir

-b BRANCH, --branch BRANCH

Check out FETCH_HEAD into this branch after fetching

-c, --check

Check if pull request has already been applied

-e, --explode

Convert a pull request into an mbox full of patches

-o OUTMBOX, --output-mbox OUTMBOX

Save exploded messages into this mailbox (default: msgid.mbx)

-l, --retrieve-links

Attempt to retrieve any Link: URLs (use with -e)

-f MAILFROM, --from-addr MAILFROM

Use this From: in exploded messages (use with -e)

Example: b4 pr 202003292120.2BDCB41@keescook

### b4 ty
usage:

b4 ty [-h] [-g GITDIR] [-o OUTDIR] [-l] [-t THANK_FOR [THANK_FOR ...]] [-d DISCARD [DISCARD ...]] [-a] [-b BRANCH] [--since SINCE] [-S] [--dry-run]

optional arguments:

-h, --help

show this help message and exit

-g GITDIR, --gitdir GITDIR

Operate on this git tree instead of current dir

-o OUTDIR, --outdir OUTDIR

Write thanks files into this dir (default=.)

-l, --list

List pull requests and patch series you have retrieved

-t THANK_FOR, --thank-for THANK_FOR

Generate thankyous for specific entries from -l (e.g.: 1,3-5,7-; or "all")

-d DISCARD, --discard DISCARD

Discard specific messages from -l (e.g.: 1,3-5,7-; or "all")

-a, --auto

Use the Auto-Thankanator gun to figure out what got applied/merged

-b BRANCH, --branch BRANCH

The branch to check against, instead of current

--since SINCE

The --since option to use when auto-matching patches (default=1.week)

-S, --send-email

Send email instead of writing out .thanks files

--dry-run

Print out emails instead of sending them

--pw-set-state PW_STATE

Set this patchwork state instead of default (use with -a, -t or -d)

NOTE:

To send mails directly using -S, you should have a configured [sendemail] section somewhere in your applicable git configuration files (global or in-tree).

Example: b4 ty -aS --dry-run

### b4 diff
usage:

b4 diff [-h] [-g GITDIR] [-p USEPROJECT] [-C] [-v WANTVERS [WANTVERS ...]] [-n] [-o OUTDIFF] [-c] [-m AMBOX AMBOX] [msgid]

positional arguments:

msgid Message ID to process, pipe a raw message, or use -m

optional arguments:

-h, --help

show this help message and exit

-g GITDIR, --gitdir GITDIR

Operate on this git tree instead of current dir

-p USEPROJECT, --use-project USEPROJECT

Use a specific project instead of guessing (linux-mm, linux-hardening, etc)

-C, --no-cache

Do not use local cache

-v WANTVERS [WANTVERS ...], --compare-versions WANTVERS [WANTVERS ...]

Compare specific versions instead of latest and one before that, e.g. -v 3 5

-n, --no-diff

Do not generate a diff, just show the command to do it

-o OUTDIFF, --output-diff OUTDIFF

Save diff into this file instead of outputting to stdout

-c, --color

Force color output even when writing to file

-m AMBOX AMBOX, --compare-am-mboxes AMBOX AMBOX

Compare two mbx files prepared with "b4 am"

Example: b4 diff 20200526205322.23465-1-mic@digikod.net

### b4 kr
usage:

b4 kr [-h] [-p USEPROJECT] [-m LOCALMBOX] [-C] [--show-keys] [msgid]

positional arguments:

msgid Message ID to process, or pipe a raw message

optional arguments:

-h, --help

show this help message and exit

-p USEPROJECT, --use-project USEPROJECT

Use a specific project instead of guessing (linux-mm, linux-hardening, etc)

-m LOCALMBOX, --use-local-mbox LOCALMBOX

Instead of grabbing a thread from lore, process this mbox file (or - for stdin)

--stdin-pipe-sep STDIN_PIPE_SEP

When accepting messages on stdin, split using this pipe separator string

-C, --no-cache

Do not use local cache

--show-keys

Show all developer keys from the thread

Example: b4 kr --show-keys 20210521184811.617875-1-konstantin@linuxfoundation.org

### b4 prep
usage:

b4 prep [-h] [-c | -p OUTPUT_DIR | --edit-cover | --show-revision | --force-revision N | --compare-to vN | --manual-reroll COVER_MSGID | --set-prefixes PREFIX [PREFIX ...] | --show-info ] [-n NEW_SERIES_NAME] [-f FORK_POINT] [-F MSGID] [-e ENROLL_BASE]

options:

-h, --help

show this help message and exit

-c, --auto-to-cc

Automatically populate cover letter trailers with To and Cc addresses

-p OUTPUT_DIR, --format-patch OUTPUT_DIR

Output prep-tracked commits as patches

--edit-cover

Edit the cover letter in your defined $EDITOR (or core.editor)

--show-revision

Show current series revision number

--force-revision N

Force revision to be this number instead

--compare-to vN

Display a range-diff to previously sent revision N

--manual-reroll COVER_MSGID

Mark current revision as sent and reroll (requires cover letter msgid)

--set-prefixes PREFIX [PREFIX ...]

Extra prefixes to add to [PATCH] (e.g.: RFC mydrv)

--show-info

Show current series info in a column-parseable format

Create new branch:

Create a new branch for working on patch series

-n NEW_SERIES_NAME, --new NEW_SERIES_NAME

Create a new branch for working on a patch series

-f FORK_POINT, --fork-point FORK_POINT

When creating a new branch, use this fork point instead of HEAD

-F MSGID, --from-thread MSGID

When creating a new branch, use this thread

Enroll existing branch:

Enroll existing branch for prep work

-e ENROLL_BASE, --enroll ENROLL_BASE

Enroll current branch, using the passed tag, branch, or commit as fork base

### b4 send
usage:

b4 send [-h] [-d] [-o OUTPUT_DIR] [--reflect] [--no-trailer-to-cc] [--hide-cover-to-cc] [--to TO [TO ...]] [--cc CC [CC ...]] [--not-me-too] [--resend RESEND] [--no-sign] [--web-auth-new] [--web-auth-verify VERIFY_TOKEN]

options:

-h, --help

show this help message and exit

-d, --dry-run

Do not send, just dump out raw smtp messages to the stdout

-o OUTPUT_DIR, --output-dir OUTPUT_DIR

Do not send, write raw messages to this directory (forces --dry-run)

--reflect

Send everything to yourself instead of the actual recipients

--no-trailer-to-cc

Do not add any addresses found in the cover or patch trailers to To: or Cc:

--hide-cover-to-cc

Hide To: and Cc: entries from the cover letter trailers (but still send to them)

--to TO [TO ...]

Addresses to add to the To: list

--cc CC [CC ...]

Addresses to add to the Cc: list

--not-me-too

Remove yourself from the To: or Cc: list

--resend RESEND

Resend a previously sent version of the series

--no-sign

Do not add the cryptographic attestation signature header

Web submission:

Authenticate with the web submission endpoint

--web-auth-new

Initiate a new web authentication request

--web-auth-verify VERIFY_TOKEN

Submit the token received via verification email

### b4 trailers
usage:

b4 trailers [-h] [-u] [-S] [-F MSGID] [--since SINCE]

options:

-h, --help

show this help message and exit

-u, --update

Update branch commits with latest received trailers

-S, --sloppy-trailers

Apply trailers without email address match checking

-F MSGID, --trailers-from MSGID

Look for trailers in the thread with this msgid instead of using the series change-id

--since SINCE

The --since option to use with -F when auto-matching patches (default=1.month)

-m LOCALMBOX, --use-local-mbox LOCALMBOX

Instead of grabbing a thread from lore, process this mbox file (or - for stdin)

--stdin-pipe-sep STDIN_PIPE_SEP

When accepting messages on stdin, split using this pipe separator string

-C, --no-cache

Do not use local cache

## CONFIGURATION
B4 configuration is handled via git-config(1), so you can store it in either the toplevel $HOME/.gitconfig file, or in a per-repository .git/config file if your workflow changes per project.

To see configuration options available, see online documentation at https://b4.docs.kernel.org/en/latest/config.html

## PROXYING REQUESTS
Commands making remote HTTP requests may be configured to use a proxy by setting the HTTPS_PROXY environment variable, as described in https://docs.python-requests.org/en/latest/user/advanced/#proxies.

## SUPPORT
Please email tools@linux.kernel.org with support requests, or browse the list archive at https://lore.kernel.org/tools.

## AUTHOR
mricon@kernel.org

License: GPLv2+

## COPYRIGHT
The Linux Foundation and contributors


backup.d

package: backupninja

title: backup.d(5)

text:
# backup.d(5)

## NAME
BACKUP.D - Action configuration files for backupninja(1).

## SYNOPSIS
/etc/backup.d/*

## DESCRIPTION
To preform the actual backup actions, backupninja processes each action configuration file in /etc/backup.d according to the file's suffix.

.sh

run this file as a shell script.

.rdiff

backup action for rdiff-backup.

.restic

backup action for restic.

.dup

backup action for duplicity.

.borg

backup action for borgbackup.

.maildir

backup action for slow, incremental rsyncs of tens of thousands of maildirs.

.mysql

backup action for safe MySQL dumps.

.pgsql

backup action for safe PostgreSQL dumps.

.sys

backup action for general system reports and hardware information.

.svn

backup action for safe backups of subversion repositories.

.trac

backup action for safe backups of trac repositories.

.makecd

backup action for burning backups to CD/DVD or creating ISOs.

These files must be owned by root and must not be world or group readable/writable. Support for additional configuration types can be added by dropping bash scripts with the name of the suffix into /usr/share/backupninja.

The configuration files are processed in alphabetical order. However, it is suggested that you name the config files in "sysvinit style."

For example:

10-local.pgsql.disabled

15-runthisfirst.sh

20-runthisnext.mysql

90-runthislast.rdiff

Typically, you will put a '.rdiff' config file last, so that any database dumps you make are included in the filesystem backup. Action configurations which end with .disabled are skipped.

Example templates for the action configuration files can be found in /usr/share/doc/backupninja/examples. You can also use ninjahelper(1), a console based "wizard" for creating backup actions.

## SCHEDULING
By default, each configuration file is processed everyday at 01:00 (1 AM). This can be changed by specifying the 'when' option in a backup action's config file or in the global configuration file. Special value 'manual' will disable scheduling for the backup action. It is possible to run the backup action manually by invoking ninjahelper(1) with --run command line argument.

For example:

when = sundays at 02:00

when = 30th at 22

when = 30 at 22:00

when = everyday at 01

when = Tuesday at 05:00

when = hourly

when = manual

These values for "when" are invalid:

when = everyday at 5:00

when = tuesday at 2am

when = tuesday at 2

when = tues at 02

A configuration file will be processed at the time(s) specified by the "when" option. If multiple "when" options are present, then they all apply. If two configurations files are scheduled to run in the same hour, then we fall back on the alphabetical ordering specified above. The "when" must occur before any sections in the action configuration file.

## FILE FORMAT
The file format of the action configuration files is "ini style." Sections are created by using square bracket. Long lines are connected with a backslash. For example:

\# this is a comment

[fishes]

fish = red

fish = blue

[fruit]

apple = yes

pear = no thanks \

i will not have a pear.

## SEE ALSO
backupninja(1), ninjahelper(1), backupninja.conf(5),

## AUTHOR
BACKUPNINJA was written by the riseup.net collective.


backupninja.conf

title: backupninja.conf(5)

text:
# backupninja.conf(5)

## NAME
BACKUPNINJA.CONF - Configuration file(s) for backupninja (1).

## SYNOPSIS
/etc/backupninja.conf

## DESCRIPTION
backupninja.conf is the general configuration file. In this file you can set the log level and change the default directory locations. You can force a different general configuration file with "backupninja -f /path/to/conf".

## OPTIONS
loglevel

How verbose to make the logs.

5 = Debugging messages

4 = Informational messages

3 = Warnings

2 = Errors

1 = Fatal errors

reportprom

Produce prometheus metrics of backup status. Requires `prometheus-node-exporter` to be installed.

reportemail

Send a summary of the backup status to this email address.

reportsuccess

If set to 'yes', a report email will be generated even if all modules reported success.

reportinfo

If set to 'yes', info messages from handlers will be sent into the email.

reportwarning

If set to 'yes', a report email will be generated even if there was no error.

reportspace

If set to 'yes', disk space usage will be included in the backup email report.

reporthost

Where to rsync the backupninja.log to be aggregated in a ninjareport.

reportuser

What user to connect to reporthost to sync the backupninja.log

reportdirectory

Where on the reporthost should the report go.

reportwrap

Number of columns the email report body should wrap to.

logfile

The path of the logfile.

configdirectory

The directory where all the backup action configuration files live.

admingroup

Administration user group that is allowed to read/write configuration files in configdirectory.

scriptdirectory

Where backupninja handler scripts are found.

usecolors

If set to 'yes', use colors in the log file and debug output.

when

When to process each configuration file. The value used here will be applied for each configuration file. It is possible to override this "when" in each configuration file, see also section "Scheduling" in backup.d(5). For example:

when = sundays at 02:00

when = 30th at 22

when = 30 at 22:00

when = everyday at 01 <-- the default

when = Tuesday at 05:00

These values for 'when' are equivalent:

when = tuesday at 05:30

when = TUESDAYS at 05

These values for 'when' are invalid:

when = tuesday at 2am

when = tuesday at 2

when = tues at 02

## DEFAULTS
loglevel = 4

reportemail = root

reportsuccess = yes

reportinfo = no

reportspace = no

reporthost =

reportuser = ninja

reportdirectory = /var/lib/backupninja/reports

reportwrap = 1000

logfile = /var/log/backupninja.log

configdirectory = /etc/backup.d

admingroup = root

scriptdirectory = /usr/share/backupninja

usecolors = yes

when = everyday at 01:00

## SEE ALSO
backupninja(1), ninjahelper(1), backup.d(5),

## AUTHOR
BACKUPNINJA was written by the riseup.net collective.


barman

package: barman

title: barman(5)

text:
# barman(5)

## NAME
barman - Backup and Recovery Manager for PostgreSQL

## DESCRIPTION
Barman is an administration tool for disaster recovery of PostgreSQL servers written in Python and maintained by EnterpriseDB. Barman can perform remote backups of multiple servers in business critical environments and helps DBAs during the recovery phase.

## CONFIGURATION FILE LOCATIONS
The system-level Barman configuration file is located at

```
/etc/barman.conf

```

or

```
/etc/barman/barman.conf

```

and is overridden on a per-user level by

```
$HOME/.barman.conf

```

## CONFIGURATION FILE SYNTAX
The Barman configuration file is a plain INI file. There is a general section called [barman] and a section [servername] for each server you want to backup. Rows starting with ; are comments.

## CONFIGURATION FILE DIRECTORY
Barman supports the inclusion of multiple configuration files, through the configuration_files_directory option. Included files must contain only server specifications, not global configurations. If the value of configuration_files_directory is a directory, Barman reads all files with .conf extension that exist in that folder. For example, if you set it to /etc/barman.d, you can specify your PostgreSQL servers placing each section in a separate .conf file inside the /etc/barman.d folder.

## OPTIONS
active

When set to true (default), the server is in full operational state. When set to false, the server can be used for diagnostics, but any operational command such as backup execution or WAL archiving is temporarily disabled. When adding a new server to Barman, we suggest setting active=false at first, making sure that barman check shows no problems, and only then activating the server. This will avoid spamming the Barman logs with errors during the initial setup.

Scope: Server/Model.

archiver

This option allows you to activate log file shipping through PostgreSQL's archive_command for a server. If set to true, Barman expects that continuous archiving for a server is in place and will activate checks as well as management (including compression) of WAL files that Postgres deposits in the incoming directory. Setting it to false (default), will disable standard continuous archiving for a server. Note: If neither archiver nor streaming_archiver are set, Barman will automatically set this option to true. This is in order to maintain parity with deprecated behaviour where archiver would be enabled by default. This behaviour will be removed from the next major Barman version.

Scope: Global/Server/Model.

archiver_batch_size

This option allows you to activate batch processing of WAL files for the archiver process, by setting it to a value > 0. Otherwise, the traditional unlimited processing of the WAL queue is enabled. When batch processing is activated, the archive-wal process would limit itself to maximum archiver_batch_size WAL segments per single run. Integer.

Scope: Global/Server/Model.

autogenerate_manifest

This option enables the auto-generation of backup manifest files for rsync based backups and strategies. The manifest file is a JSON file containing the list of files contained in the backup. It is generated at the end of the backup process and stored in the backup directory. The manifest file generated follows the format described in the postgesql documentation, and is compatible with the pg_verifybackup tool. The option is ignored if the backup method is not rsync.

Scope: Global/Server/Model.

aws_profile

The name of the AWS profile to use when authenticating with AWS (e.g. INI section in AWS credentials file).

Scope: Global/Server/Model.

aws_region

The name of the AWS region containing the EC2 VM and storage volumes defined by snapshot_instance and snapshot_disks.

Scope: Global/Server/Model.

azure_credential

The credential type (either azure-cli or managed-identity) to use when authenticating with Azure. If this is omitted then the default Azure authentication flow will be used.

Scope: Global/Server/Model.

azure_resource_group

The name of the Azure resource group to which the compute instance and disks defined by snapshot_instance and snapshot_disks belong. Required when the snapshot value is specified for backup_method and snapshot_provider is set to azure.

Scope: Global/Server/Model.

azure_subscription_id

The ID of the Azure subscription which owns the instance and storage volumes defined by snapshot_instance and snapshot_disks. Required when the snapshot value is specified for backup_method and snapshot_provider is set to azure.

Scope: Global/Server/Model.

backup_compression

The compression to be used during the backup process. Only supported when backup_method = postgres. Can either be unset or gzip,lz4, zstd or none. If unset then no compression will be used during the backup. Use of this option requires that the CLI application for the specified compression algorithm is available on the Barman server (at backup time) and the PostgreSQL server (at recovery time). Note that the lz4 and zstd algorithms require PostgreSQL 15 (beta) or later. Note that none compression will create an archive not compressed.

Scope: Global/Server/Model.

backup_compression_format

The format pg_basebackup should use when writing compressed backups to disk. Can be set to either plain or tar. If unset then a default of tar is assumed. The value plain can only be used if the server is running PostgreSQL 15 or later and if backup_compression_location is server. Only supported when backup_method = postgres.

Scope: Global/Server/Model.

backup_compression_level

An integer value representing the compression level to use when compressing backups. Allowed values depend on the compression algorithm specified by backup_compression. Only supported when backup_method = postgres.

Scope: Global/Server/Model.

backup_compression_location

The location (either client or server) where compression should be performed during the backup. The value server is only allowed if the server is running PostgreSQL 15 or later.

Scope: Global/Server/Model.

backup_compression_workers

The number of compression threads to be used during the backup process. Only supported when backup_compression = zstd is set. Default value is 0. In this case default compression behavior will be used.

Scope: Global/Server/Model.

backup_directory

Directory where backup data for a server will be placed.

Scope: Server.

backup_method

Configure the method barman used for backup execution. If set to rsync (default), barman will execute backup using the rsync command over SSH (requires ssh_command). If set to postgres barman will use the pg_basebackup command to execute the backup. If set to local-rsync, barman will assume to be running on the same server as the PostgreSQL instance and with the same user, then execute rsync for the file system copy. If set to snapshot, barman will use the API for the cloud provider defined in the snapshot_provider option to create snapshots of disks specified in the snapshot_disks option and save only the backup label and metadata to its own storage.

Scope: Global/Server/Model.

backup_options

This option allows you to control the way Barman interacts with PostgreSQL for backups. It is a comma-separated list of values that accepts the following options:

•

concurrent_backup (default): barman backup executes backup operations using concurrent backup which is the recommended backup approach for PostgreSQL versions >= 9.6 and uses the PostgreSQL API. concurrent_backup can also be used to perform a backup from a standby server.

•

exclusive_backup (PostgreSQL versions older than 15 only): barman backup executes backup operations using the deprecated exclusive backup approach (technically through pg_start_backup and pg_stop_backup)

•

external_configuration: if present, any warning regarding external configuration files is suppressed during the execution of a backup.

Note that exclusive_backup and concurrent_backup are mutually exclusive.

Scope: Global/Server/Model.

bandwidth_limit

This option allows you to specify a maximum transfer rate in kilobytes per second. A value of zero specifies no limit (default).

Scope: Global/Server/Model.

barman_home

Main data directory for Barman.

Scope: Global.

barman_lock_directory

Directory for locks. Default: %(barman_home)s.

Scope: Global.

basebackup_retry_sleep

Number of seconds of wait after a failed copy, before retrying Used during both backup and recovery operations. Positive integer, default 30.

Scope: Global/Server/Model.

basebackup_retry_times

Number of retries of base backup copy, after an error. Used during both backup and recovery operations. Positive integer, default 0.

Scope: Global/Server/Model.

basebackups_directory

Directory where base backups will be placed.

Scope: Server.

check_timeout

Maximum execution time, in seconds per server, for a barman check command. Set to 0 to disable the timeout. Positive integer, default 30.

Scope: Global/Server/Model.

cluster

Name of the Barman cluster associated with a Barman server or model. Used by Barman to group servers and configuration models that can be applied to them. Can be omitted for servers, in which case it defaults to the server name. Must be set for configuration models, so Barman knows the set of servers which can apply a given model.

Scope: Server/Model.

compression

Standard compression algorithm applied to WAL files. Possible values are: gzip (requires gzip to be installed on the system), bzip2 (requires bzip2), pigz (requires pigz), pygzip (Python's internal gzip compressor) and pybzip2 (Python's internal bzip2 compressor).

Scope: Global/Server/Model.

config_changes_queue

Barman uses a queue to apply configuration changes requested through barman config-update command. This allows it to serialize multiple requests of configuration changes, and also retry an operation which has been abruptly terminated. This configuration option allows you to specify where in the filesystem the queue should be written. By default Barman writes to a file named cfg_changes.queue under barman_home.

Scope: global.

conninfo

Connection string used by Barman to connect to the Postgres server. This is a libpq connection string, consult the PostgreSQL manual (https://www.postgresql.org/docs/current/static/libpq-connect.html#LIBPQ-CONNSTRING) for more information. Commonly used keys are: host, hostaddr, port, dbname, user, password.

Scope: Server/Model.

create_slot

When set to auto and slot_name is defined, Barman automatically attempts to create the replication slot if not present. When set to manual (default), the replication slot needs to be manually created.

Scope: Global/Server/Model.

custom_compression_filter

Customised compression algorithm applied to WAL files.

Scope: Global/Server/Model.

custom_compression_magic

Customised compression magic which is checked in the beginning of a WAL file to select the custom algorithm. If you are using a custom compression filter then setting this will prevent barman from applying the custom compression to WALs which have been pre-compressed with that compression. If you do not configure this then custom compression will still be applied but any pre-compressed WAL files will be compressed again during WAL archive.

Scope: Global/Server/Model.

custom_decompression_filter

Customised decompression algorithm applied to compressed WAL files; this must match the compression algorithm.

Scope: Global/Server/Model.

description

A human readable description of a server.

Scope: Server/Model.

errors_directory

Directory that contains WAL files that contain an error; usually this is related to a conflict with an existing WAL file (e.g. a WAL file that has been archived after a streamed one).

Scope: Server.

forward_config_path

Parameter which determines whether a passive node should forward its configuration file path to its primary node during cron or sync-info commands. Set to true if you are invoking barman with the -c/--config option and your configuration is in the same place on both the passive and primary barman servers. Defaults to false.

Scope: Global/Server/Model.

gcp_project

The ID of the GCP project which owns the instance and storage volumes defined by snapshot_instance and snapshot_disks. Required when the snapshot value is specified for backup_method and snapshot_provider is set to gcp.

Scope: Global/Server/Model.

gcp_zone

The name of the availability zone where the compute instance and disks to be backed up in a snapshot backup are located. Required when the snapshot value is specified for backup_method and snapshot_provider is set to gcp.

Scope: Server/Model.

immediate_checkpoint

This option allows you to control the way PostgreSQL handles checkpoint at the start of the backup. If set to false (default), the I/O workload for the checkpoint will be limited, according to the checkpoint_completion_target setting on the PostgreSQL server. If set to true, an immediate checkpoint will be requested, meaning that PostgreSQL will complete the checkpoint as soon as possible.

Scope: Global/Server/Model.

incoming_wals_directory

Directory where incoming WAL files are archived into. Requires archiver to be enabled.

Scope: Server.

last_backup_maximum_age

This option identifies a time frame that must contain the latest backup. If the latest backup is older than the time frame, barman check command will report an error to the user. If empty (default), latest backup is always considered valid. Syntax for this option is: "i (DAYS | WEEKS | MONTHS)" where i is an integer greater than zero, representing the number of days | weeks | months of the time frame.

Scope: Global/Server/Model.

last_backup_minimum_size

This option identifies lower limit to the acceptable size of the latest successful backup. If the latest backup is smaller than the specified size, barman check command will report an error to the user. If empty (default), latest backup is always considered valid. Syntax for this option is: "i (k|Ki|M|Mi|G|Gi|T|Ti)" where i is an integer greater than zero, with an optional SI or IEC suffix. k=kilo=1000, Ki=Kibi=1024 and so forth. Note that the suffix is case-sensitive.

Scope: Global/Server/Model.

last_wal_maximum_age

This option identifies a time frame that must contain the latest WAL file archived. If the latest WAL file is older than the time frame, barman check command will report an error to the user. If empty (default), the age of the WAL files is not checked. Syntax is the same as last_backup_maximum_age (above).

Scope: Global/Server/Model.

lock_directory_cleanup

enables automatic cleaning up of the barman_lock_directory from unused lock files.

Scope: Global.

log_file

Location of Barman's log file.

Scope: Global.

log_level

Level of logging (DEBUG, INFO, WARNING, ERROR, CRITICAL).

Scope: Global.

max_incoming_wals_queue

Maximum number of WAL files in the incoming queue (in both streaming and archiving pools) that are allowed before barman check returns an error (that does not block backups). Default: None (disabled).

Scope: Global/Server/Model.

minimum_redundancy

Minimum number of backups to be retained. Default 0.

Scope: Global/Server/Model.

model

By default any section configured in the Barman configuration files define the configuration for a Barman server. If you set model = true in a section, that turns that section into a configuration model for a given cluster. Cannot be set as false.

Scope: Model.

network_compression

This option allows you to enable data compression for network transfers. If set to false (default), no compression is used. If set to true, compression is enabled, reducing network usage.

Scope: Global/Server/Model.

parallel_jobs

This option controls how many parallel workers will copy files during a backup or recovery command. Default 1. For backup purposes, it works only when backup_method is rsync.

Scope: Global/Server/Model.

parallel_jobs_start_batch_period

The time period in seconds over which a single batch of jobs will be started. Default: 1 second.

Scope: Global/Server/Model.

parallel_jobs_start_batch_size

Maximum number of parallel jobs to start in a single batch. Default: 10 jobs.

Scope: Global/Server/Model.

path_prefix

One or more absolute paths, separated by colon, where Barman looks for executable files. The paths specified in path_prefix are tried before the ones specified in PATH environment variable.

Scope: Global/server/Model.

post_archive_retry_script

Hook script launched after a WAL file is archived by maintenance. Being this a retry hook script, Barman will retry the execution of the script until this either returns a SUCCESS (0), an ABORT_CONTINUE (62) or an ABORT_STOP (63) code. In a post archive scenario, ABORT_STOP has currently the same effects as ABORT_CONTINUE.

Scope: Global/Server.

post_archive_script

Hook script launched after a WAL file is archived by maintenance, after 'post_archive_retry_script'.

Scope: Global/Server.

post_backup_retry_script

Hook script launched after a base backup. Being this a retry hook script, Barman will retry the execution of the script until this either returns a SUCCESS (0), an ABORT_CONTINUE (62) or an ABORT_STOP (63) code. In a post backup scenario, ABORT_STOP has currently the same effects as ABORT_CONTINUE.

Scope: Global/Server.

post_backup_script

Hook script launched after a base backup, after 'post_backup_retry_script'.

Scope: Global/Server.

post_delete_retry_script

Hook script launched after the deletion of a backup. Being this a retry hook script, Barman will retry the execution of the script until this either returns a SUCCESS (0), an ABORT_CONTINUE (62) or an ABORT_STOP (63) code. In a post delete scenario, ABORT_STOP has currently the same effects as ABORT_CONTINUE.

Scope: Global/Server.

post_delete_script

Hook script launched after the deletion of a backup, after 'post_delete_retry_script'.

Scope: Global/Server.

post_recovery_retry_script

Hook script launched after a recovery. Being this a retry hook script, Barman will retry the execution of the script until this either returns a SUCCESS (0), an ABORT_CONTINUE (62) or an ABORT_STOP (63) code. In a post recovery scenario, ABORT_STOP has currently the same effects as ABORT_CONTINUE.

Scope: Global/Server.

post_recovery_script

Hook script launched after a recovery, after 'post_recovery_retry_script'.

Scope: Global/Server.

post_wal_delete_retry_script

Hook script launched after the deletion of a WAL file. Being this a retry hook script, Barman will retry the execution of the script until this either returns a SUCCESS (0), an ABORT_CONTINUE (62) or an ABORT_STOP (63) code. In a post delete scenario, ABORT_STOP has currently the same effects as ABORT_CONTINUE.

Scope: Global/Server.

post_wal_delete_script

Hook script launched after the deletion of a WAL file, after 'post_wal_delete_retry_script'.

Scope: Global/Server.

pre_archive_retry_script

Hook script launched before a WAL file is archived by maintenance, after 'pre_archive_script'. Being this a retry hook script, Barman will retry the execution of the script until this either returns a SUCCESS (0), an ABORT_CONTINUE (62) or an ABORT_STOP (63) code. Returning ABORT_STOP will propagate the failure at a higher level and interrupt the WAL archiving operation.

Scope: Global/Server.

pre_archive_script

Hook script launched before a WAL file is archived by maintenance.

Scope: Global/Server.

pre_backup_retry_script

Hook script launched before a base backup, after 'pre_backup_script'. Being this a retry hook script, Barman will retry the execution of the script until this either returns a SUCCESS (0), an ABORT_CONTINUE (62) or an ABORT_STOP (63) code. Returning ABORT_STOP will propagate the failure at a higher level and interrupt the backup operation.

Scope: Global/Server.

pre_backup_script

Hook script launched before a base backup.

Scope: Global/Server.

pre_delete_retry_script

Hook script launched before the deletion of a backup, after 'pre_delete_script'. Being this a retry hook script, Barman will retry the execution of the script until this either returns a SUCCESS (0), an ABORT_CONTINUE (62) or an ABORT_STOP (63) code. Returning ABORT_STOP will propagate the failure at a higher level and interrupt the backup deletion.

Scope: Global/Server.

pre_delete_script

Hook script launched before the deletion of a backup.

Scope: Global/Server.

pre_recovery_retry_script

Hook script launched before a recovery, after 'pre_recovery_script'. Being this a retry hook script, Barman will retry the execution of the script until this either returns a SUCCESS (0), an ABORT_CONTINUE (62) or an ABORT_STOP (63) code. Returning ABORT_STOP will propagate the failure at a higher level and interrupt the recover operation.

Scope: Global/Server.

pre_recovery_script

Hook script launched before a recovery.

Scope: Global/Server.

pre_wal_delete_retry_script

Hook script launched before the deletion of a WAL file, after 'pre_wal_delete_script'. Being this a retry hook script, Barman will retry the execution of the script until this either returns a SUCCESS (0), an ABORT_CONTINUE (62) or an ABORT_STOP (63) code. Returning ABORT_STOP will propagate the failure at a higher level and interrupt the WAL file deletion.

Scope: Global/Server.

pre_wal_delete_script

Hook script launched before the deletion of a WAL file.

Scope: Global/Server.

primary_checkpoint_timeout

This defines the amount of seconds that Barman will wait at the end of a backup if no new WAL files are produced, before forcing a checkpoint on the primary server.

If not set or set to 0, Barman will not force a checkpoint on the primary, and wait indefinitely for new WAL files to be produced.

The value of this option should be greater of the value of the archive_timeout set on the primary server.

This option works only if primary_conninfo option is set, and it is ignored otherwise.

Scope: Server/Model.

primary_conninfo

The connection string used by Barman to connect to the primary Postgres server during backup of a standby Postgres server. Barman will use this connection to carry out any required WAL switches on the primary during the backup of the standby. This allows backups to complete even when archive_mode = always is set on the standby and write traffic to the primary is not sufficient to trigger a natural WAL switch.

If primary_conninfo is set then it must be pointing to a primary Postgres instance and conninfo must be pointing to a standby Postgres instance. Furthermore both instances must share the same systemid. If these conditions are not met then barman check will fail.

The primary_conninfo value must be a libpq connection string; consult the PostgreSQL manual (https://www.postgresql.org/docs/current/static/libpq-connect.html#LIBPQ-CONNSTRING) for more information. Commonly used keys are: host, hostaddr, port, dbname, user, password.

Scope: Server/Model.

primary_ssh_command

Parameter that identifies a Barman server as passive. In a passive node, the source of a backup server is a Barman installation rather than a PostgreSQL server. If primary_ssh_command is specified, Barman uses it to establish a connection with the primary server. Empty by default, it can also be set globally.

Scope: Global/Server/Model.

recovery_options

Options for recovery operations. Currently only supports get-wal. get-wal activates generation of a basic restore_command in the resulting recovery configuration that uses the barman get-wal command to fetch WAL files directly from Barman's archive of WALs. Comma separated list of values, default empty.

Scope: Global/Server/Model.

recovery_staging_path

A path to a location on the recovery host (either the barman server or a remote host if --remote-ssh-command is also used) where files for a compressed backup will be staged before being uncompressed to the destination directory. Backups will be staged in their own directory within the staging path according to the following naming convention: "barman-staging-SERVER_NAME-BACKUP_ID". The staging directory within the staging path will be removed at the end of the recovery process. This option is required when recovering from compressed backups and has no effect otherwise.

Scope: Global/Server/Model.

retention_policy

Policy for retention of periodic backups and archive logs. If left empty, retention policies are not enforced. For redundancy based retention policy use "REDUNDANCY i" (where i is an integer > 0 and defines the number of backups to retain). For recovery window retention policy use "RECOVERY WINDOW OF i DAYS" or "RECOVERY WINDOW OF i WEEKS" or "RECOVERY WINDOW OF i MONTHS" where i is a positive integer representing, specifically, the number of days, weeks or months to retain your backups. For more detailed information, refer to the official documentation. Default value is empty.

Scope: Global/Server/Model.

retention_policy_mode

Currently only "auto" is implemented.

Scope: Global/Server/Model.

reuse_backup

This option controls incremental backup support. Possible values are:

•

off: disabled (default);

•

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). Requires operating system and file system support for hard links.

Scope: Global/Server/Model.

slot_name

Physical replication slot to be used by the receive-wal command when streaming_archiver is set to on. Default: None (disabled).

Scope: Global/Server/Model.

snapshot_disks

A comma-separated list of disks which should be included in a backup taken using cloud snapshots. Required when the snapshot value is specified for backup_method.

Scope: Server/Model.

snapshot_instance

The name of the VM or compute instance where the storage volumes are attached. Required when the snapshot value is specified for backup_method.

Scope: Server/Model.

snapshot_provider

The name of the cloud provider which should be used to create snapshots. Required when the snapshot value is specified for backup_method. Supported values: gcp.

Scope: Global/Server/Model.

ssh_command

Command used by Barman to login to the Postgres server via ssh.

Scope: Server/Model.

streaming_archiver

This option allows you to use the PostgreSQL's streaming protocol to receive transaction logs from a server. If set to on, Barman expects to find pg_receivewal (known as pg_receivexlog prior to PostgreSQL 10) in the PATH (see path_prefix option) and that streaming connection for the server is working. This activates connection checks as well as management (including compression) of WAL files. If set to off (default) barman will rely only on continuous archiving for a server WAL archive operations, eventually terminating any running pg_receivexlog for the server. Note: If neither streaming_archiver nor archiver are set, Barman will automatically set archiver to true. This is in order to maintain parity with deprecated behaviour where archiver would be enabled by default. This behaviour will be removed from the next major Barman version.

Scope: Global/Server/Model.

streaming_archiver_batch_size

This option allows you to activate batch processing of WAL files for the streaming_archiver process, by setting it to a value > 0. Otherwise, the traditional unlimited processing of the WAL queue is enabled. When batch processing is activated, the archive-wal process would limit itself to maximum streaming_archiver_batch_size WAL segments per single run. Integer.

Scope: Global/Server/Model.

streaming_archiver_name

Identifier to be used as application_name by the receive-wal command. Only available with pg_receivewal (or pg_receivexlog >= 9.3). By default it is set to barman_receive_wal.

Scope: Global/Server/Model.

streaming_backup_name

Identifier to be used as application_name by the pg_basebackup command. By default it is set to barman_streaming_backup.

Scope: Global/Server/Model.

streaming_conninfo

Connection string used by Barman to connect to the Postgres server via streaming replication protocol. By default it is set to conninfo.

Scope: Server/Model.

streaming_wals_directory

Directory where WAL files are streamed from the PostgreSQL server to Barman. Requires streaming_archiver to be enabled.

Scope: Server.

tablespace_bandwidth_limit

This option allows you to specify a maximum transfer rate in kilobytes per second, by specifying a comma separated list of tablespaces (pairs TBNAME:BWLIMIT). A value of zero specifies no limit (default).

Scope: Global/Server/Model.

wal_conninfo

A connection string which, if set, will be used by Barman to connect to the Postgres server when checking the status of the replication slot used for receiving WALs. If left unset then Barman will use the connection string defined by wal_streaming_conninfo. If wal_conninfo is set but wal_streaming_conninfo is unset then wal_conninfo will be ignored.

Scope: Server/Model.

wal_retention_policy

Policy for retention of archive logs (WAL files). Currently only "MAIN" is available.

Scope: Global/Server/Model.

wal_streaming_conninfo

A connection string which, if set, will be used by Barman to connect to the Postgres server when receiving WAL segments via the streaming replication protocol. If left unset then Barman will use the connection string defined by streaming_conninfo for receiving WAL segments.

Scope: Server/Model.

wals_directory

Directory which contains WAL files.

Scope: Server.

## HOOK SCRIPTS
The script definition is passed to a shell and can return any exit code.

The shell environment will contain the following variables:

BARMAN_CONFIGURATION

configuration file used by barman

BARMAN_ERROR

error message, if any (only for the 'post' phase)

BARMAN_PHASE

'pre' or 'post'

BARMAN_RETRY

1 if it is a retry script (from 1.5.0), 0 if not

BARMAN_SERVER

name of the server

Backup scripts specific variables:

BARMAN_BACKUP_DIR

backup destination directory

BARMAN_BACKUP_ID

ID of the backup

BARMAN_PREVIOUS_ID

ID of the previous backup (if present)

BARMAN_NEXT_ID

ID of the next backup (if present)

BARMAN_STATUS

status of the backup

BARMAN_VERSION

version of Barman

Archive scripts specific variables:

BARMAN_SEGMENT

name of the WAL file

BARMAN_FILE

full path of the WAL file

BARMAN_SIZE

size of the WAL file

BARMAN_TIMESTAMP

WAL file timestamp

BARMAN_COMPRESSION

type of compression used for the WAL file

Recovery scripts specific variables:

BARMAN_DESTINATION_DIRECTORY

the directory where the new instance is recovered

BARMAN_TABLESPACES

tablespace relocation map (JSON, if present)

BARMAN_REMOTE_COMMAND

secure shell command used by the recovery (if present)

BARMAN_RECOVER_OPTIONS

recovery additional options (JSON, if present)

Only in case of retry hook scripts, the exit code of the script is checked by Barman. Output of hook scripts is simply written in the log file.

## EXAMPLE
Here is an example of configuration file:

```
[barman]
; Main directory
barman_home = /var/lib/barman
; System user
barman_user = barman
; Log location
log_file = /var/log/barman/barman.log
; Default compression level
;compression = gzip
; Incremental backup
reuse_backup = link
; 'main' PostgreSQL Server configuration
[main]
; Human readable description
description =  "Main PostgreSQL Database"
; SSH options
ssh_command = ssh postgres@pg
; PostgreSQL connection string
conninfo = host=pg user=postgres
; PostgreSQL streaming connection string
streaming_conninfo = host=pg user=postgres
; Minimum number of required backups (redundancy)
minimum_redundancy = 1
; Retention policy (based on redundancy)
retention_policy = REDUNDANCY 2
```

## SEE ALSO
barman (1).

## AUTHORS
Barman maintainers (in alphabetical order):

•

Abhijit Menon-Sen

•

Jane Threefoot

•

Michael Wallace

Past contributors (in alphabetical order):

•

Anna Bellandi (QA/testing)

•

Britt Cole (documentation reviewer)

•

Carlo Ascani (developer)

•

Francesco Canovai (QA/testing)

•

Gabriele Bartolini (architect)

•

Gianni Ciolli (QA/testing)

•

Giulio Calacoci (developer)

•

Giuseppe Broccolo (developer)

•

Jonathan Battiato (QA/testing)

•

Leonardo Cecchi (developer)

•

Marco Nenciarini (project leader)

•

Niccolò Fei (QA/testing)

•

Rubens Souza (QA/testing)

•

Stefano Bianucci (developer)

## RESOURCES
•

Homepage: <https://www.pgbarman.org/>

•

Documentation: <https://docs.pgbarman.org/>

•

Professional support: <https://www.enterprisedb.com/>

## COPYING
Barman is the property of EnterpriseDB UK Limited and its code is distributed under GNU General Public License v3.

© Copyright EnterpriseDB UK Limited 2011-2023

## AUTHORS
EnterpriseDB <https://www.enterprisedb.com>.