Proxmox Backup client on CentOS 8/Rocky Linux 8

Wed, Apr 20, 2022 4-minute read

Proxmox Backup Client

Having recently installed Proxmox VE in my lab and also Proxmox Backup Server then I want to use it to backup as many machines as possible.

This is easy for virtual machines running inside Proxmox VE, since its already integrated.

But I also have physical machines running Rocky Linux & Centos 8, so this is a simple cook book to get it running on those two linux variants, since Proxmox does not provide pre-built packages.

Installation

I have found a github repository where a guy is building the packages for Centos7 & 8. This makes it faily simple, since you do not have to build the client from source.

It is on Proxmox’s roadmap to support backup clients for other platforms than debian, but they haven’t gotten around to it yet.

Step by step guide

  1. Download the package to your home directory:wget https://github.com/sg4r/proxmox-backup-client/releases/download/v2.1.2/proxmox-backup-2.1.2-1.x86_64.el8.rpm
  2. Install it via dnf by executing sudo dnf -y install ./proxmox-backup-2.1.2-1.x86_64.el8.rpm

Then if you want to run a single backup you can simply do:

sudo -E /usr/local/sbin/proxmox-backup-client backup root.pxar:/ --repository '<username>!<tokenname>@<pbs_server>:<datastorename>'

In the example above I have

<username>      - which should be the username you created in the pbs server for the backup purpose
<tokenname>     - is the name of the token you created inside pbs for the given user
<pbs_server>    - is the actual hostname/ip of the pbs server
<datastorename> - is the name of the datastore to put the backup in.

When you use the client in the above way, i.e. with a token, then it will ask for the token at the command line, or you can also just have it as a variable:

export PBS_PASSWORD='cc535e84-b425-4bb4-8575-d8cb886d0e2f'

If the variable PBS_PASSWORD is available the backup client will use that for either a password or token - depending on whether or not you authenticate with a token or a password.

I suggest you create a token and use that istead of spreading passwords in configuration files.

So a real life example using a token for one of my servers would be:

export PBS_PASSWORD='cc535e84-b425-4bb4-8575-d8cb886d0e2f'

/usr/local/sbin/proxmox-backup-client backup root.pxar:/ \ 
  --repository 'backup@pbs!backup@pvebackup.root.dom:backup'

This simply tells the backup client to backup the entire root partition to my backup server @ pvebackup.root.dom into the backup datastore.

Automated backups

This is all well - but backups should be automated, and this means crontab.

So create a file inside /etc/cron.daily called backup

And paste in the following contents if you want to use my exact settings:

#!/bin/sh
export MAILTO='bjornsmith@gmail.com'
export PBS_PASSWORD='cc535e84-b425-4bb4-8575-d8cb886d0e2f'

/usr/local/sbin/proxmox-backup-client backup root.pxar:/ \ 
  --repository 'backup@pbs!backup@pvebackup.root.dom:backup'

Then make the file executable with:sudo chmod a+x /etc/cron.daily/backup

If you have many machines and you don’t want them all to run their backup at the exact same time then edit the file /etc/anacrontab and change the START_HOURS_RANGE so each machine have a different starting time.

# /etc/anacrontab: configuration file for anacron

# See anacron(8) and anacrontab(5) for details.

SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO="bjornsmith@gmail.com"
# the maximal random delay added to the base delay of the jobs
RANDOM_DELAY=45
# the jobs will be started during the following hours only
START_HOURS_RANGE=7-22

#period in days   delay in minutes   job-identifier   command
1       5       cron.daily              nice run-parts /etc/cron.daily
7       25      cron.weekly             nice run-parts /etc/cron.weekly
@monthly 45     cron.monthly            nice run-parts /etc/cron.monthly

The above example is from one of my machines and the machines all have a different START_HOURS_RANGE so my backup server will not be overloaded with backups from many servers at the same time.

I.e. my kubernetes cluster of 5 machines is running with

node1 uses START_HOURS_RANGE=3-22, node2 uses START_HOURS_RANGE=4-22, node3 uses START_HOURS_RANGE=5-22, node4 uses START_HOURS_RANGE=6-22, node5 uses START_HOURS_RANGE=7-22

This ensures that each machine have at least 15 minutes to complete their backup before another machine can start and normally a whole hour at least.

How you arrange your starting time of your daily crontab is obviously up to you, but I suggest spreading the load out a bit, so the backup server is not overwhelmed with backups from many sources at the same time.