Backup Client Usage¶
The command line client is called proxmox-backup-client.
Backup Repository Locations¶
The client uses the following notation to specify a datastore repository on the backup server.
The default value for
root@pam. If no server is specified,
the default is the local host (
You can specify a port if your backup server is only reachable on a different port (e.g. with NAT and port forwarding).
Note that if the server is an IPv6 address, you have to write it with square brackets (for example, [fe80::01]).
You can pass the repository with the
--repository command line option, or
by setting the
PBS_REPOSITORY environment variable.
Here some examples of valid repositories and the real values
The default backup repository.
When set, this value is used for the password required for the backup server. You can also set this to a API token secret.
When set, this value is used to access the secret encryption key (if protected by password).
PBS_FINGERPRINTWhen set, this value is used to verify the server
certificate (only used if the system CA certificates cannot validate the certificate).
Most commands producing output supports the
parameter. It accepts the following values:
Text format (default). Structured data is rendered as a table.
JSON (single line).
JSON (multiple lines, nicely formatted).
Also, the following environment variables can modify output behavior:
Defines the default output format.
If set (to any value), do not render table borders.
If set (to any value), do not render table headers.
text format is designed to be human readable, and
not meant to be parsed by automation tools. Please use the
format if you need to process the output.
This section explains how to create a backup from within the machine. This can be a physical host, a virtual machine, or a container. Such backups may contain file and image archives. There are no restrictions in this case.
If you want to backup virtual machines or containers on Proxmox VE, see Proxmox VE Integration.
For the following example you need to have a backup server set up, working
credentials and need to know the repository name.
In the following examples we use
# proxmox-backup-client backup root.pxar:/ --repository backup-server:store1 Starting backup: host/elsa/2019-12-03T09:35:01Z Client name: elsa skip mount point: "/boot/efi" skip mount point: "/dev" skip mount point: "/run" skip mount point: "/sys" Uploaded 12129 chunks in 87 seconds (564 MB/s). End Time: 2019-12-03T10:36:29+01:00
This will prompt you for a password and then uploads a file archive named
root.pxar containing all the files in the
Please note that the proxmox-backup-client does not
automatically include mount points. Instead, you will see a short
skip mount point notice for each of them. The idea is to
create a separate file archive for each mounted disk. You can
explicitly include them using the
--include-dev /boot/efi). You can use this option
multiple times for each mount point that should be included.
--repository option can get quite long and is used by all
commands. You can avoid having to enter this value by setting the
PBS_REPOSITORY. Note that if you would like this to remain set
over multiple sessions, you should instead add the below line to your
# export PBS_REPOSITORY=backup-server:store1
After this you can execute all commands without specifying the
One single backup is allowed to contain more than one archive. For example, if
you want to backup two disks mounted at
# proxmox-backup-client backup disk1.pxar:/mnt/disk1 disk2.pxar:/mnt/disk2
This creates a backup of both disks.
The backup command takes a list of backup specifications, which include the archive name on the server, the type of the archive, and the archive source at the client. The format is:
Common types are
.pxar for file archives, and
.img for block
device images. To create a backup of a block device run the following command:
# proxmox-backup-client backup mydata.img:/dev/mylvm/mydata
Excluding files/folders from a backup¶
Sometimes it is desired to exclude certain files or folders from a backup archive.
To tell the Proxmox Backup client when and how to ignore files and directories,
place a text file called
.pxarexclude in the filesystem hierarchy.
Whenever the backup client encounters such a file in a directory, it interprets
each line as glob match patterns for files and directories that are to be excluded
from the backup.
The file must contain a single glob pattern per line. Empty lines are ignored.
The same is true for lines starting with
#, which indicates a comment.
! at the beginning of a line reverses the glob match pattern from an exclusion
to an explicit inclusion. This makes it possible to exclude all entries in a
directory except for a few single files/subdirectories.
Lines ending in
/ match only on directories.
The directory containing the
.pxarexclude file is considered to be the root of
the given patterns. It is only possible to match files in this directory and its subdirectories.
\ is used to escape special glob characters.
? matches any single character.
* matches any character, including an empty string.
** is used to match subdirectories. It can be used to, for example, exclude
all files ending in
.tmp within the directory or subdirectories with the
[...] matches a single character from any of the provided characters within
[!...] does the complementary and matches any single character
not contained within the brackets. It is also possible to specify ranges with two
characters separated by
-. For example,
[a-z] matches any lowercase
alphabetic character and
[0-9] matches any one single digit.
The order of the glob match patterns defines whether a file is included or
excluded, that is to say later entries override previous ones.
This is also true for match patterns encountered deeper down the directory tree,
which can override a previous exclusion.
Be aware that excluded directories will not be read by the backup client.
.pxarexclude file in an excluded subdirectory will have no effect.
.pxarexclude files are treated as regular files and will be included in the
For example, consider the following directory structure:
# ls -aR folder folder/: . .. .pxarexclude subfolder0 subfolder1 folder/subfolder0: . .. file0 file1 file2 file3 .pxarexclude folder/subfolder1: . .. file0 file1 file2 file3
.pxarexclude files contain the following:
# cat folder/.pxarexclude /subfolder0/file1 /subfolder1/* !/subfolder1/file2
# cat folder/subfolder0/.pxarexclude file3
This would exclude
subfolder0 and all of
Restoring this backup will result in:
ls -aR restored restored/: . .. .pxarexclude subfolder0 subfolder1 restored/subfolder0: . .. file0 file2 .pxarexclude restored/subfolder1: . .. file2
Proxmox Backup supports client-side encryption with AES-256 in GCM mode. To set this up, you first need to create an encryption key:
# proxmox-backup-client key create my-backup.key Encryption Key Password: **************
The key is password protected by default. If you do not need this extra protection, you can also create it without a password:
# proxmox-backup-client key create /path/to/my-backup.key --kdf none
Having created this key, it is now possible to create an encrypted backup, by
--keyfile parameter, with the path to the key file.
# proxmox-backup-client backup etc.pxar:/etc --keyfile /path/to/my-backup.key Password: ********* Encryption Key Password: ************** ...
If you do not specify the name of the backup key, the key will be
created in the default location
will also search this location by default, in case the
parameter is not specified.
You can avoid entering the passwords by setting the environment
Using a master key to store and recover encryption keys¶
You can also use
proxmox-backup-client key to create an RSA public/private
key pair, which can be used to store an encrypted version of the symmetric
backup encryption key alongside each backup and recover it later.
To set up a master key:
Create an encryption key for the backup:
# proxmox-backup-client key create creating default key at: "~/.config/proxmox-backup/encryption-key.json" Encryption Key Password: ********** ...
The resulting file will be saved to
Create an RSA public/private key pair:
# proxmox-backup-client key create-master-key Master Key Password: ********* ...
This will create two files in your current directory,
Import the newly created
master-public.pempublic certificate, so that
proxmox-backup-clientcan find and use it upon backup.
# proxmox-backup-client key import-master-pubkey /path/to/master-public.pem Imported public master key to "~/.config/proxmox-backup/master-public.pem"
With all these files in place, run a backup job:
# proxmox-backup-client backup etc.pxar:/etc
The key will be stored in your backup, under the name
--keyfileparameter can be excluded, if the encryption key is in the default path. If you specified another path upon creation, you must pass the
To test that everything worked, you can restore the key from the backup:
# proxmox-backup-client restore /path/to/backup/ rsa-encrypted.key /path/to/target
You should not need an encryption key to extract this file. However, if a key exists at the default location (
~/.config/proxmox-backup/encryption-key.json) the program will prompt you for an encryption key password. Simply moving
encryption-key.jsonout of this directory will fix this issue.
Then, use the previously generated master key to decrypt the file:
# proxmox-backup-client key import-with-master-key /path/to/target --master-keyfile /path/to/master-private.pem --encrypted-keyfile /path/to/rsa-encrypted.key Master Key Password: ****** New Password: ****** Verify Password: ******
The target file will now contain the encryption key information in plain text. The success of this can be confirmed by passing the resulting
jsonfile, with the
--keyfileparameter, when decrypting files from the backup.
Without their key, backed up files will be inaccessible. Thus, you should keep keys ordered and in a place that is separate from the contents being backed up. It can happen, for example, that you back up an entire system, using a key on that system. If the system then becomes inaccessible for any reason and needs to be restored, this will not be possible as the encryption key will be lost along with the broken system.
It is recommended that you keep your master key safe, but easily accessible, in
order for quick disaster recovery. For this reason, the best place to store it
is in your password manager, where it is immediately recoverable. As a backup to
this, you should also save the key to a USB drive and store that in a secure
place. This way, it is detached from any system, but is still easy to recover
from, in case of emergency. Finally, in preparation for the worst case scenario,
you should also consider keeping a paper copy of your master key locked away in
a safe place. The
paperkey subcommand can be used to create a QR encoded
version of your master key. The following command sends the output of the
paperkey command to a text file, for easy printing.
proxmox-backup-client key paperkey --output-format text > qrkey.txt
The regular creation of backups is a necessary step to avoiding data loss. More importantly, however, is the restoration. It is good practice to perform periodic recovery tests to ensure that you can access the data in case of problems.
First, you need to find the snapshot which you want to restore. The snapshot list command provides a list of all the snapshots on the server:
# proxmox-backup-client snapshot list ┌────────────────────────────────┬─────────────┬────────────────────────────────────┐ │ snapshot │ size │ files │ ╞════════════════════════════════╪═════════════╪════════════════════════════════════╡ │ host/elsa/2019-12-03T09:30:15Z │ 51788646825 │ root.pxar catalog.pcat1 index.json │ ├────────────────────────────────┼─────────────┼────────────────────────────────────┤ │ host/elsa/2019-12-03T09:35:01Z │ 51790622048 │ root.pxar catalog.pcat1 index.json │ ├────────────────────────────────┼─────────────┼────────────────────────────────────┤ ...
You can inspect the catalog to find specific files.
# proxmox-backup-client catalog dump host/elsa/2019-12-03T09:35:01Z ... d "./root.pxar.didx/etc/cifs-utils" l "./root.pxar.didx/etc/cifs-utils/idmap-plugin" d "./root.pxar.didx/etc/console-setup" ...
The restore command lets you restore a single archive from the backup.
# proxmox-backup-client restore host/elsa/2019-12-03T09:35:01Z root.pxar /target/path/
To get the contents of any archive, you can restore the
index.json file in the
repository to the target path '-'. This will dump the contents to the standard output.
# proxmox-backup-client restore host/elsa/2019-12-03T09:35:01Z index.json -
If you only want to restore a few individual files, it is often easier to use the interactive recovery shell.
# proxmox-backup-client catalog shell host/elsa/2019-12-03T09:35:01Z root.pxar Starting interactive shell pxar:/ > ls bin boot dev etc home lib lib32 ...
The interactive recovery shell is a minimal command line interface that utilizes the metadata stored in the catalog to quickly list, navigate and search files in a file archive. To restore files, you can select them individually or match them with a glob pattern.
Using the catalog for navigation reduces the overhead considerably because only the catalog needs to be downloaded and, optionally, decrypted. The actual chunks are only accessed if the metadata in the catalog is not enough or for the actual restore.
Similar to common UNIX shells
ls are the commands used to change
working directory and list directory contents in the archive.
pwd shows the full path of the current working directory with respect to the
Being able to quickly search the contents of the archive is a commonly needed feature. That's where the catalog is most valuable. For example:
pxar:/ > find etc/**/*.txt --select "/etc/X11/rgb.txt" pxar:/ > list-selected etc/**/*.txt pxar:/ > restore-selected /target/path ...
This will find and print all files ending in
.txt located in
etc/ or a
subdirectory and add the corresponding pattern to the list for subsequent restores.
list-selected shows these patterns and
restore-selected finally restores
all files in the archive matching the patterns to
/target/path on the local
host. This will scan the whole archive.
restore command can be used to restore all the files contained within
the backup archive. This is most helpful when paired with the
<glob> option, as it allows you to restore all files matching a specific
pattern. For example, if you wanted to restore configuration files
/etc, you could do the following:
pxar:/ > restore target/ --pattern etc/**/*.conf ...
The above will scan through all the directories below
/etc and restore all
files ending in
Mounting of Archives via FUSE¶
The FUSE implementation for the pxar archive allows you to mount a file archive as a read-only filesystem to a mountpoint on your host.
# proxmox-backup-client mount host/backup-client/2020-01-29T11:29:22Z root.pxar /mnt/mountpoint # ls /mnt/mountpoint bin dev home lib32 libx32 media opt root sbin sys usr boot etc lib lib64 lost+found mnt proc run srv tmp var
This allows you to access the full contents of the archive in a seamless manner.
As the FUSE connection needs to fetch and decrypt chunks from the backup server's datastore, this can cause some additional network and CPU load on your host, depending on the operations you perform on the mounted filesystem.
To unmount the filesystem use the
umount command on the mountpoint:
# umount /mnt/mountpoint
Login and Logout¶
The client tool prompts you to enter the logon password as soon as you want to access the backup server. The server checks your credentials and responds with a ticket that is valid for two hours. The client tool automatically stores that ticket and uses it for further requests to this server.
You can also manually trigger this login/logout using the login and logout commands:
# proxmox-backup-client login Password: **********
To remove the ticket, issue a logout:
# proxmox-backup-client logout
Changing the Owner of a Backup Group¶
By default, the owner of a backup group is the user which was used to originally
create that backup group (or in the case of sync jobs,
means that if a user
mike@pbs created a backup, another user
can not be used to create backups in that same backup group. In case you want
to change the owner of a backup, you can do so with the below command, using a
user that has
Datastore.Modify privileges on the datastore.
# proxmox-backup-client change-owner vm/103 john@pbs
This can also be done from within the web interface, by navigating to the
Content section of the datastore that contains the backup group and
selecting the user icon under the Actions column. Common cases for this could
be to change the owner of a sync job from
root@pam, or to repurpose a
Pruning and Removing Backups¶
You can manually delete a backup snapshot using the
# proxmox-backup-client snapshot forget <snapshot>
This command removes all archives in this backup snapshot. They will be inaccessible and unrecoverable.
Although manual removal is sometimes required, the
command is normally used to systematically delete older backups. Prune lets
you specify which backup snapshots you want to keep. The
following retention options are available:
Keep the last
Keep backups for the last
<N>hours. If there is more than one backup for a single hour, only the latest is kept.
Keep backups for the last
<N>days. If there is more than one backup for a single day, only the latest is kept.
Keep backups for the last
<N>weeks. If there is more than one backup for a single week, only the latest is kept.
Weeks start on Monday and end on Sunday. The software uses the ISO week date system and handles weeks at the end of the year correctly.
Keep backups for the last
<N>months. If there is more than one backup for a single month, only the latest is kept.
Keep backups for the last
<N>years. If there is more than one backup for a single year, only the latest is kept.
The retention options are processed in the order given above. Each option only covers backups within its time period. The next option does not take care of already covered backups. It will only consider older backups.
Unfinished and incomplete backups will be removed by the prune command unless they are newer than the last successful backup. In this case, the last failed backup is retained.
# proxmox-backup-client prune <group> --keep-daily 7 --keep-weekly 4 --keep-monthly 3
You can use the
--dry-run option to test your settings. This only
shows the list of existing snapshots and what actions prune would take.
# proxmox-backup-client prune host/elsa --dry-run --keep-daily 1 --keep-weekly 3 ┌────────────────────────────────┬──────┐ │ snapshot │ keep │ ╞════════════════════════════════╪══════╡ │ host/elsa/2019-12-04T13:20:37Z │ 1 │ ├────────────────────────────────┼──────┤ │ host/elsa/2019-12-03T09:35:01Z │ 0 │ ├────────────────────────────────┼──────┤ │ host/elsa/2019-11-22T11:54:47Z │ 1 │ ├────────────────────────────────┼──────┤ │ host/elsa/2019-11-21T12:36:25Z │ 0 │ ├────────────────────────────────┼──────┤ │ host/elsa/2019-11-10T10:42:20Z │ 1 │ └────────────────────────────────┴──────┘
prune command nor the
forget command free space
in the chunk-store. The chunk-store still contains the data blocks. To free
space you need to perform Garbage Collection.
prune command removes only the backup index files, not the data
from the datastore. This task is left to the garbage collection
command. It is recommended to carry out garbage collection on a regular basis.
The garbage collection works in two phases. In the first phase, all data blocks that are still in use are marked. In the second phase, unused data blocks are removed.
This command needs to read all existing backup index files and touches the complete chunk-store. This can take a long time depending on the number of chunks and the speed of the underlying disks.
The garbage collection will only remove chunks that haven't been used
for at least one day (exactly 24h 5m). This grace period is necessary because
chunks in use are marked by touching the chunk which updates the
(access time) property. Filesystems are mounted with the
by default. This results in a better performance by only updating the
atime property if the last access has been at least 24 hours ago. The
downside is, that touching a chunk within these 24 hours will not always
Chunks in the grace period will be logged at the end of the garbage collection task as Pending removals.
# proxmox-backup-client garbage-collect starting garbage collection on store store2 Start GC phase1 (mark used chunks) Start GC phase2 (sweep unused chunks) percentage done: 1, chunk count: 219 percentage done: 2, chunk count: 453 ... percentage done: 99, chunk count: 21188 Removed bytes: 411368505 Removed chunks: 203 Original data bytes: 327160886391 Disk bytes: 52767414743 (16 %) Disk chunks: 21221 Average chunk size: 2486565 TASK OK
The backup client also comes with a benchmarking tool. This tool measures various metrics relating to compression and encryption speeds. If a Proxmox Backup repository (remote or local) is specified, the TLS upload speed will get measured too.
You can run a benchmark using the
benchmark subcommand of
The TLS speed test is only included if a backup server repository is specified.
# proxmox-backup-client benchmark Uploaded 1517 chunks in 5 seconds. Time per request: 3309 microseconds. TLS speed: 1267.41 MB/s SHA256 speed: 2066.73 MB/s Compression speed: 775.11 MB/s Decompress speed: 1233.35 MB/s AES256/GCM speed: 3688.27 MB/s Verify speed: 783.43 MB/s ┌───────────────────────────────────┬─────────────────────┐ │ Name │ Value │ ╞═══════════════════════════════════╪═════════════════════╡ │ TLS (maximal backup upload speed) │ 1267.41 MB/s (103%) │ ├───────────────────────────────────┼─────────────────────┤ │ SHA256 checksum computation speed │ 2066.73 MB/s (102%) │ ├───────────────────────────────────┼─────────────────────┤ │ ZStd level 1 compression speed │ 775.11 MB/s (103%) │ ├───────────────────────────────────┼─────────────────────┤ │ ZStd level 1 decompression speed │ 1233.35 MB/s (103%) │ ├───────────────────────────────────┼─────────────────────┤ │ Chunk verification speed │ 783.43 MB/s (103%) │ ├───────────────────────────────────┼─────────────────────┤ │ AES256 GCM encryption speed │ 3688.27 MB/s (101%) │ └───────────────────────────────────┴─────────────────────┘
The percentages given in the output table correspond to a comparison against a Ryzen 7 2700X.
You can also pass the
--output-format parameter to output stats in
rather than the default table format.