Wer kennt es nicht? Ein vollgelaufenes Dateisystem möchte man weder unter Linux noch Windows-Systemen haben. Das führt zu den interessantesten Phänomenen, z.B. dass gewisse Dienste nicht mehr starten oder funktionieren.
DISCLAIMER: Offiziell wird es mit der VIA/VSA 13.1 (Stand heute) nicht unterstützt, die Disk nachträglich zu vergrößern. Daher übernehmen wir keinerlei Verantwortung und empfehlen dieses Vorgehen nur für PoCs und Lab-Umgebungen.
Wenn man von seinem Veeam Server Mails wie diese erhält, ist es vermutlich schon zu spät und man muss handeln. Genau diesen Fall hatte ich diese Woche in einem Projekt, daher stammt auch der Screenshot.
Die offizielle Lösung ist in KB4777 beschrieben. Dabei wird das Logverzeichnis an einen anderen Ort verschoben. Diese Lösung gefällt mir jedoch nicht, da alle Konfigurationen, die vom Standard abweichen, früher oder später Probleme machen. Beispielsweise das automatische einsammeln der Logs über Veeam funktioniert nur wenn die logs in /var/log liegen.
Ziel dieses Beitrags ist es also, die VMDK der VM zu vergrößern und mit diesem gewonnenen Platz das bestehende /var/log Verzeichnis zu erweitern, ohne tiefer in die Log-Konfiguration eingreifen zu müssen.
Nun aber los – die Befehle wurden mit der Veeam Infrastructure Appliance in der Version 13.1 durchgeführt. Diese war als Single Disk Appliance deployed. Das ist seit 13.1 möglich und deshalb wichtig da, sich sonst ggf. die Disk- bzw. Partitionsnamen unterscheiden können.
Schritt 1:
Sofern es sich um eine VM handelt bitte zuerst die Disk vergrößern und anschließend direkt einen VM Snapshot erstellen.
Wie schon in meinem Artikel für das Vergrößern der Repository-Partition beschrieben, zunächst in die Host Console der VM bzw. des Servers einloggen. Unter „Remote Access Configuration“ –> „Enter shell“ die root shell öffnen. Sollte der Security Officer aktiviert sein, erfordert dies ggf. eine Bestätigung.
Schritt 2:
Die Disk sollte an der Stelle schon vergrößert worden sein, in meinem Beispiel habe ich die Disk von 200 GB auf 210 GB erweitert. Wie man sieht, ist mein sda allerdings immer noch 200 GB groß.
lsblk
Falls euch das englische Keyboard Layout stört, reicht ein einfaches „loadkeys de“
loadkeys de
echo 1 | sudo tee /sys/block/sda/device/rescanAnschließend sieht man die korrekte Größe
Schritt 3:
Nun muss die Partition vergrößert werden. Bitte hier nochmal doppel prüfen, ob die Richtige Partition gewählt wurde. Bei Parted kommt es oft zu Rückfragen wie „Partition is being used. Are you sure?“. Nach einer Disk-Vergrößerung kommt bei GPT oft auch der Hinweis, dass der Backup-Header nicht am Ende liegt („Fix/Ignore“). Diese Schritte können mit Yes bzw. Fix bestätigt werden.
parted /dev/sda resizepart 4 100%Schritt 4:
Anschließend mit pvresize die Größe des Physical Volumes anpassen sowie die Partitionstabelle neu einlesen.
partprobe /dev/sda
pvresize /dev/sda4
Schritt 5:
Mit vgs sieht man nun den freigewordenen Platz von 10 GB
[root@vprx-f9fc7618 /]# vgs
VG #PV #LV #SN Attr VSize VFree
systemvol 1 8 0 wz--n- <204.50g 10.00gSchritt 6:
Da die Appliance mit LVM arbeitet, habe ich jetzt die Wahl welchem Bereich ich den freien Speicherplatz zuweise. In unserem Beispiel war /var/log voll, deshalb vergeben wir hier den Platz.
lvextend -r -l +100%FREE /dev/mapper/systemvol-varlog
Fazit: /var/log wurde erfolgreich um 10GB erweitert. Auch wenn der Weg aktuell nicht supported ist – für mich ist es nach wie vor die beste Option da, der Aufwand sehr gering ist und man damit nah am Standard-Deployment der Appliance bleibt.