This post is in a way part of Encrypting Proxmox Backups, reading that first may help here.

Proxmox Backup Client#

The Proxmox Backup Client is built into Proxmox Virtual Environment (PVE) and Proxmox Backup Server (PBS) by default, however it is avaliable via it’s own repo for use on systems not running within Proxmox.

This makes things super useful if you want all your backups avaliable in one location. Currently the tool only avaliable through APT-based repository, so for Debian based people go follow the instructions provided by Proxmox for getting the Backup Client Only Repo setup and installed.

In my case I have a separate ‘NAS’ system that uses Debian and so I back this up into my PBS.

Automating the Backups#

The advantage of PVE is that scheduling backups is rather easy. However the backup client is designed as a CLI tool so there will be some manual work to do here.

The backup tool requires a few things to correctly backup, firstly it needs your PBS Server, Datastore, Backup User, its password or API key, a repository target and then what you want to backup.

We can handle all of this via Environment variables that we shall load into a shell script.

#!/bin/bash

export PBS_PASSWORD='{API Key}'
export PBS_USER_STRING='user@pbs!API_Key_Name'
export PBS_SERVER='PBS FQDN or IP'
export PBS_DATASTORE='Datastore Name'
export PBS_REPOSITORY="${PBS_USER_STRING}@${PBS_SERVER}:${PBS_DATASTORE}"
export PBS_HOSTNAME="$(hostname -s)"

proxmox-backup-client backup root.pxar:/ -ns backup --change-detection-mode=metadata

So some explanation will be needed. Instead of the password for a user within PBS, this targets a users API key. This is much safer as it gives access to the machine without giving the password away. Plus as part of making backups immutable, the key should be VERY limited in what it can do.

If you don’t know how to do API keys, view the Proxmox Backup Server Documentation for a breakdown.

In short the only permissions it needs is the ‘DatastoreBackup’, this will provide the functions for creating a backup, as well as reading and verifying them.

The PBS_USER_STRING will now be set as the PBS user, the realm and API key name

For example, my user is the hostname of the machine (Asuna), the realm will be the PBS machine and the API key is called ‘backup’; your PBS_USER_STRING will look like:

asuna@pbs!backup

Set PBS_SERVER and PBS_DATASTORE as needed for your setup. If your PBS install uses a different port to default, append this to the end of the ‘PBS_SERVER_STRING’ with a :(port_number)

If your PBS is using IPv6 and not on DNS, then you will need to enclose the IP in square brackets.

There is no need to change the PBS_REPOSITORY or PBS_HOSTNAME. They build based upon previously entered information and just so the hostname gets passed along to PBS.

The only thing left is to modify the -ns value. If you utilise them, then change as needed. If not, remove it.

Targetting Specific Locations#

In my case, I don’t case about the OS, so making a backup from / is overkill. It also makes recovery of certain items slower, as you have to probe the entire image. In my case for my NAS this would make a single image in excess of several Terabytes.

If you want to target a path and give it a unique name add it in to the final line (before the -ns flag) as follows:

(name of backup location).pxar:(path on machine)

As an example, I have a ZFS dataset mounted at /mnt/Stor0/Dataset1. To backup just that up I would add:

dataset1.pxar:/mnt/Stor0/Dataset1/

You can specify as many of these as you need. Within the script.

Different Detection Modes#

There are 3 modes that changes can be detected within the backup tool. They can again be referenced in the technical overview.

In short, the mode presented here utilises metadata and it looks for changes based upon metadata changes. It aims to re-use data from the previous backups within PBS and will save on data unnecessarily transiting your network, which is useful if the PBS target is remote.

As this mode relies on previous backup integrity, I would not advise using this mode when PBS is not using a ZFS backed storage target. In that case it would be safer to do the use the data mode instead. This will utilise far more disk space though in backup (or at least did in my environment).

Encrypting the Backup#

Yes, you can apply the same backup methods for PVE to a standalone machine with Proxmox Backup Client.

However, it is a little more manual but as you have the tools installed it is as simple as doing:

proxmox-backup-client key create

This will ask you to password protect the key.

If you’re automating the backup though… you can’t have this as it will prompt for the password when backing up. If you will only do backups manually, then this is fine.

To do this automagically though, you will need to create the key without the password

proxmox-backup-client key create --kdf none

By default this will place the key into the .config/proxmox-backup/ path within the user you commited the command under.

Just like in the other Encrypting Proxmox Backups you can utilise a Key pair for encryption key backup and recovery.

If you need to create one, utilise the command:

proxmox-backup-client key create-master-key

If you already have one, just copy the public key to the machine.

From there import the key with:

proxmox-backup-client key import-master-pubkey /path/to/public_key

Running a backup now will include the encryption key within the backup (rsa-encrypted.key) protected by your key pair.

Recovering the Encryption Key#

I advise you do this after your first backup to ensure that the key can be recovered it needed. Move the existing encrpytion-key.json out of .config/proxmox-backup/ before doing this just incase something goes wrong and over writes it with garbage.

(Remember you will need to set your environment variables BEFORE doing this)

proxmox-backup-client restore /path/to/backup/ rsa-encrypted.key /path/to/target

From there, get the Private key on to the machine and then enter the following

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

If this worked, you should hopefully find that the .config/proxmox-backup/encryption-key.json file has re-appeared, do a diff and check that this file matches the one you moved earlier.

Automating#

Once you’re happy that you can backup and recover keys, simply target the above shell script with something like Cron and schedule your backups. As data infrequently changes on my NAS, I have settled for once a week, although

Next Steps#

Do some backups! Read the sister article if you haven’t already.

Consider making your backups immutable.