Proxmox Backup client on CentOS 8/Rocky Linux 8
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.
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
- Download the package to your home directory:
- Install it via
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:
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@[email protected]:backup'
This simply tells the backup client to backup the entire root partition to my backup server @
pvebackup.root.dom into the
This is all well - but backups should be automated, and this means crontab.
So create a file inside
And paste in the following contents if you want to use my exact settings:
#!/bin/sh export MAILTO='[email protected]' export PBS_PASSWORD='cc535e84-b425-4bb4-8575-d8cb886d0e2f' /usr/local/sbin/proxmox-backup-client backup root.pxar:/ \ --repository 'backup@[email protected]: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="[email protected]" # 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
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
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.