Bei uns werden, vor allem zu Testzwecken, manche VMs über eine sogenannte In-Guest Sicherung zusätzlich mit dem ISP B/A Client gesichert. Üblicherweise verwendet man für die Sicherung einer VMware-Umgebung Backup-Tools wie IBM Spectrum Protect Plus oder Veeam. In seltenen Fällen kann es aber durchaus Sinn machen, eine VM mit einem In-Guest Client zu sichern, da man dadurch mehr Möglichkeiten bei den Aufbewahrungszeiten, z.B. von einzelnen Dateien hat, oder wenn man VMs mit RAW-Devices sichern muss.
Das folgende Problem tritt sowohl mit dem IBM Spectrum Protect B/A Client (In-Guest), als auch mit IBM Spectrum Protect Plus auf.
Warum in RedHat Enterprise und Fedora Linux-VMs die Logdatei /var/log/lastlog groß wird
Bei einigen RedHat Enterprise und Fedora Linux-VMs kann es vorkommen, dass die Logdatei /var/log/lastlog extrem groß wird.
In unseren Fall war die Datei mit ca. 500GB scheinbar größer als das Filesystem selbst. 😊
Dies fiel uns auf, als bei sporadischen "Vollsicherungen" von verschiedenen RHEL-Systemen immer in etwa 500 GB gesichert wurden. Die Sicherungsergebnisse haben auf allen Systemen in etwas gleich ausgesehen:
In der ISP-Sicherungslogdatei dsmsched.log wurden wir schnell fündig:
Der Übeltäter hieß /var/log/lastlog.
Bei den folgenden neun inkrementellen Sicherungen wurde die Datei am 27., 28. und am 02.11.2021 gesichert.
Durch Recherchen wurde deutlich, warum diese Datei nicht täglich gesichert wird.
In der Datei /var/log/lastlog werden alle erfolgreichen Anmeldungen gespeichert. Sie ändert sich also nur, wenn sich jemand auf dem System angemeldet hat.
Und jetzt zum kuriosen Teil der Geschichte.
Die Datei ist in Wirklichkeit gar nicht so groß wie sie beim ls dargestellt wird. Dieses Geheimnis haben wir in diesem Artikel bereits verraten, und doch sieht es merkwürdig aus, wenn man die folgenden Befehle absetzt.
Laut Sicherung und dem ls Kommando hätte diese Datei eine Größe von 494,88 GB.
Wie passt eine 494,88 GB große Datei in ein Filesystem, welches nur 40GB groß ist?
Wenn man die Datei lastlog mit dem Befehl du -h überprüft, kommt man auf folgendes Ergebnis:
Tatsächlich ist die Datei nur 48K groß, es werden jedoch 494,88 GB gesichert!
Dies ließ sich auch im IBM Spectrum Protect mit einem QUERY OCCUPANCY oder AUDITOCCUP leicht nachprüfen. Denn alle betroffenen Systeme belegten viel zu viel Platz.
Die Lösung
Da diesen Fehler schon andere vor uns hatten, wurden wir schnell fündig. 😊
Die Lösung ist zunächst einfach: Man legt das korrupte Log mit folgendem Befehl einfach neu an bzw. leert es.
Wobei dieser Schritt allein das Problem nicht abschließend löst, da die Datei beim nächsten Login sofort wieder eine Größe von ca. 500 GB hat.
Und damit man in Zukunft mit diesem File keine Probleme mehr hat, könnte man die Datei mit einem Exclude-Statement einfach von der Sicherung ausschließen.
exclude /var/log/lastlog
Wer die Datei jedoch unbedingt sichern muss, könnte versuchen, mit Client Compression zu arbeiten.
Bei einem unserer Kunden hat es damit sehr gut funktioniert.
Auswirkungen auf das Backup
Nach dem Löschen der Daten aus dem Backup und einem anschließenden EXPIRE INVENTORY, konnten wir eine signifikante Verringerung im Backup-Volume feststellen.
Beim folgenden Beispiel konnten 2 TB eingespart werden:
Nach der Bereinigung
Je nach Lizenzmodell und Unternehmensgröße, könnte dieses Problem natürlich Auswirkungen auf die Lizenzkosten haben.
Die Sicherung wurde in diesem Beispiel mit dem IBM Spectrum Protect Backup/Archive Client der Version 8.1.12.000 durchgeführt.
Quelle
Zu diesem Problem existiert der folgende VMware Knowledge Base Artikel:
