Veeam Backup & Replication v11 is about to be launched on February 24th. Partners and service providers already have access to the RTM build.
One of my favourite features of version 11 are immutable backup files. You can read about it in my recent post “Hardening your Veeam Backup strategy with immutable repositories on Linux XFS“.
Some of you might already use Linux repository servers based on XFS with fast clone. Once you upgrade to Veeam Backup & Replication version 11 you may wish to activate immutable backups. I will explain in this blog post how you can use this new feature on existing XFS repository servers.
Activate immutability
To activate the immutability feature edit your existing backup repository servers and go to step “repository” (picture below). Starting with version 11 there’s a checkbox “make recent backups immutable for [x] days” where 7 is the minimum value to enter. Once you activate the checkbox you will most likely see a message “Unable to set the immutability option: cannot find the transport service on server <your repo server>. Configure the server anyway?“. Click on [Yes].
To make use of the immutability flag you’ll have to reconfigure the transport service on the Linux server.
Follow the Linux configuration wizard. Your Linux backup user and credentials should already exist.
Transport service will be installed on the repository sever.
Monitor all steps on the target system.
Review settings and click [Finish].
Transport service will restart.
Immutable flag not yet set
Activating the immutable checkbox and restarting the transport service isn’t enough to make your backups immutable. Let’s verify the settings on the repository.
veeam@repo01:/backup/Testjob$ lsattr
-------------------- ./TestjobD2020-05-08T204028_9814.vbk
-------------------- ./Testjob.vbm
As you can see in the output of the lsattr command, the flag is not yet set to existing backup files. We need to run a backup job first.
Run Backup
Most likely you will encounter an error like this. Don’t worry. That’s easy to explain.
Your backup account needs to take ownership of the backup folder. My backup user is “veeam” and belongs to group “veeam”. The folder where backups are located has the name “backup”. Your settings may be different from mine. Adjust your command accordingly.
sudo chown -R veeam:veeam /backup
Have another try and run the same backup job again. As you can see in the output below an incremental backup (.vib) has been added to our full backup (.vbk) from May 2020. BTW: This is a lab environment and you should consider scheduling more frequent backups in production. 😉
veeam@repo01:/backup/Testjob$ ls -la
total 9435784
drwxrwxr-x 2 veeam veeam 130 Feb 15 20:47 .
drwxr-xr-x 3 veeam veeam 21 May 8 2020 ..
-rw-r--r-- 1 root root 233 Feb 15 20:47 .veeam.1.lock
-rw-r--r-- 1 veeam veeam 24144 Feb 15 20:47 Testjob.vbm
-rw-r--r-- 1 veeam veeam 2482089984 May 8 2020 TestjobD2020-05-08T204028_9814.vbk
-rw-r--r-- 1 veeam veeam 7180124160 Feb 15 20:47 TestjobD2021-02-15T204500_E15A.vib
Besides the incremental backup file you can also spot a new .lock file. Let’s see if the immutable flag has been set.
veeam@repo01:/backup/Testjob$ lsattr
----i--------------- ./TestjobD2020-05-08T204028_9814.vbk
----i--------------- ./TestjobD2021-02-15T204500_E15A.vib
-------------------- ./Testjob.vbm
Great! It’s there. Both our full backup (.vbk) and the new increment (.vib) are protected by the immutable [i] flag.
We can get further information by looking into the .lock file.
Final test
To find out if it’s really working, we can try to delete the backup from disk.
As you can see, the deletion was not successful and the immutable flag has protected our backup files.
But what if..
You may ask now what might happen if an attacker gets hold of the root credentials. Well, a root user is able to do everything on a Linux system. But calm down. Fist of all the root user isn’t used outside the Linux host, nor is he allowed to connect remotely to the host. But if someone gets physical access to your repository server console and has root credentials, there’s something wrong with your security concept and you’re in deep trouble.