Veeam backup & Replication v11 steht kurz vor der Veröffentlichung. Diese ist für Mittwoch den 24.2.2021 geplant. Partner und Service Provider hatten einige Tage Vorsprung und Zugriff auf den sogenannten RTM Build (ready to manufactoring).
Eine der (wie ich meine) spannensten neuen Funktionen in Version 11 ist die Einführung der sogenannten Immutable Backups. Ich hatte bereits in meinem Beitrag “Strategien zum Schutz von Veeam Backups durch unveränderliche Repository Server mit Linux XFS” berichtet.
Einige von Euch setzen möglicherweise schon Linux Repository Server mit dem XFS Dateisystem und Fastclone produktiv ein und möchten diese nun im die Funktion Immutable-Backups erweitern. Ich werde in diesem Beitrag erklären, wie sich dies mit wenigen Schritten bewerkstelligen lässt.
Schutz aktivieren
Um die Funktion zum Schutz der Backupdaten auf bestehenden XFS Repositories zu aktivieren, müssen wir diese im Veeam Backup Client v11 bearbeiten (Bild unten). Ab Version 11 ist im Abschnitt Repository eine neue Checkbox zu sehen (“make recent backups immutable for [x] days”). Dabei ist 7 Tage der kleinstmögliche Zeitraum für den Schutz. Sobald man die Checkbox aktiviert wird sehr wahrscheinlich eine Benachrichtigung wie unten dargestellt erscheinen. “Unable to set the immutability option: cannot find the transport service on server <your repo server>. Configure the server anyway?“. Wir bestätigen diese mit [Yes].
Wir müssen zur Aktivierung des Immutable Flags den Veeam Transport Service auf dem Ziel neu konfigurieren.
Folgt den Anweisungen des Assistenten. Die SSH Zugangsdaten zum Repository sollten bereits in der Datenbank des Veeam Servers gespeichert sein. [Dies ist ein nicht-privilegiertes Konto auf dem Linux System.]
Der Transport Service wird auf dem Zielsystem neu konfiguriert.
Wir können den Fortschritt der Installation im Log verfolgen.
Kontrolle der Einstellungen und Abschluss der Aktion mit Klick auf [Finish].
Der Transport Service muss neu gestartet werden. Daher ist es wichtig, dass aktuell keine Backup Jobs auf das Repository zugreifen.
Wo ist das Flag?
Mit Auswahl der Checkbox und Rekonfiguratition des Transport Dienstes sind wir noch nicht ganz am Ziel. Schauen wir uns dazu die Backup Daten auf dem Repository Server an.
veeam@repo01:/backup/Testjob$ lsattr
-------------------- ./TestjobD2020-05-08T204028_9814.vbk
-------------------- ./Testjob.vbm
Wie man oben in der Ausgabe des lsattr Kommados sehen kann, ist das Flag [i] noch nicht gesetzt. Dazu müssen wir zunächst einen neuen Joblauf starten. Ein Inkrement reicht hierfür vollkommen aus.
Job starten
Mit großer Wahrscheinlichkeit werdet Ihr auf die Fehlermeldung wie im Bild unten stoßen. Das ist recht einfach zu erklären und stellt kein großes Problem dar.
Das Konto zur Übertragung der Backups muss Eigentümer des Backup Verzeichnisses werden. In meinem Fall heisst der Benutzer “veeam” und gehört zur Gruppe “veeam”. Der Backupordner heisst “backup”. Eure Einstellungen werden andre sein, daher müsst Ihr das unten dargestellte Kommando entsprechend anpassen.
sudo chown -R veeam:veeam /backup
Jetzt können wir einen zweiten Versuch starten und den Job nochmals laufen lassen. Wie man in der Ausgabe unten erkennen kann, wurde ein inkrementelles Backup (.vib) zu unserem Vollbackup (.vbk) vom Mai 2020 hinzugefügt. [Anm.: das ist eine Lab Umgebung. In Produktion wären regelmäßigere Backups ratsam] 😉
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
Neben der neuen Datei des inkrementellen Backups können wir jetzt auch eine verdeckte .lock Datei sehen. Sehen wir mal nach, ob das Immutable Flag gesetzt wurde.
veeam@repo01:/backup/Testjob$ lsattr
----i--------------- ./TestjobD2020-05-08T204028_9814.vbk
----i--------------- ./TestjobD2021-02-15T204500_E15A.vib
-------------------- ./Testjob.vbm
Ausgezeichnet! Beide Dateien (.vbk und .vib) sind nun über das Immutable Flag [i] geschützt. Wir erhalten weitere Informationen, wenn wir uns den Inhalt der .lock Datei ansehen.
Finaler Test
Zur Prüfung ob der Schutz auch wirklich greift, werden wir versuchen die Backups vom Repository zu löschen.
Man erkennt im Log, dass der Löschversuch gescheitert ist.
Aber was wäre wenn…
Es ist natürlich legitim, den Schutz zu hinterfragen. Was wäre wenn ein Angreifer die Logindaten für das root Konto in seinen Besitz bekäme? Ein root User darf per Definition alles auf einem Linux System (dafür gibt es den root User). Aber kein Grund zur Besorgnis. Erstens wird das root Konto nicht außerhalb des Repository Servers verwendet und zweitens darf root auch keine Fernverbindung zum System herstellen (z.B. SSH). Wenn also tatsächlich jemand die Zugangsdaten für das root Konto in seinen Besitz bringt UND physischen Zugang zur Serverkonsole erlangt, dann war schon zuvor etwas am eigenen Sicherheitskonzept grundlegend falsch und man steckt tief in der Klemme.