Kategorien
Linux

Unifi Controller – Restore von einem anderen System bzw. Backup

Ein Backup zu haben tut gut, allerdings nur wenn man auch weiß wie man’s wieder einspielt! 🙂

Die Unifi Hilfe und auch das Forum bieten leider relativ wenig Informationen dazu wie man ein mit dem Controller erstelltes Backup (findet sich gewöhnlich unter /var/lib/unifi/backup bzw. /var/lib/unifi/backup/autobackup und hat die Endung .unf) wieder einspielt.

Nach einer frischen Installation der Controller Software kann man am Startbildschirm auswählen eine vorhandene Sicherung ein zu spielen, der upload vom lokalen PC hat bei mir aufgrund der Größe des Backups nicht funktioniert. Und es steht auch nicht immer das gesamte /var/lib/unifi Verzeichnis zur Verfügung – wer also nur die „unf“ Datei hat geht wie folgt vor:

Datei Backup Datei z.B. „autobackup_5.13.32_20200806_2200_1596319200003.unf“ manuell in das Verzeichnis /var/lib/unifi/backup/autobackup/ kopieren und eine passende „autobackup_meta.json“ Datei im selben Verzeichnis erstellen.

Diese hat folgenden Inhalt:

{„autobackup_5.13.32_20200806_2200_1596319200003.unf“:{„version“:“5.13.32″,“time“:1596319200003,“datetime“:“2020-08-01T22:00:00Z“,“format“:“bson“,“days“:90,“size“:6463895536}}

Anschließend erkennt der Unifi Controller das Backup und bietet es direkt für den Restore an!

Bei einer Datenmenge von 6,1 GB kann man sich dann auch auf einem flotten System schon mal eine längere Pause gönnen, besser mit Stunden rechnen…! 🙂

Damit kann man dann auch ein Backup eines Controllers der mit einer älteren Mongo-DB gelaufen ist, problemlos in ein aktuelles Ubuntu System mit Mongo-DB 3.6.9 einspielen.

Zur Installation des Unifi Controllers empfehle ich übrigens das Script von Glenn R.

Kategorien
Linux Sicherheit

Rsync Backup Script mit ZFS/EXT4 Unterstützung und Infomail für Remote und lokale Systeme

Seit Jahren nutze ich eine Rsync Lösung zum Sichern von Servern die in der Cloud liegen oder keinen direkten Zugriff auf meine Sicherungsserver haben. Bis vor kurzem habe ich damit generell alle Linux Systeme gesichert, bei jenen die direkten Zugriff auf ein NFS oder SMB Share haben bin ich inzwischen auf den Veeam Backup Agent Free umgesteigen. Der leistet hier gute Dienste.

Meine Cloud Server sichere ich allerdings mit einem Rsync Script auf meinen zentralen Backup Server, ich habe gerne alle meine wichtigen Daten bei mir in guten Händen und kümmere mich um mein 3-2-1 Backup lieber selbst als dass ich alles einem Hoster anvertraue! 🙂

Jetzt war es mal wieder an der Zeit etwas am Backup Script zu verändern und bei der Gelegenheit habe ich es gleich komplett umgeschrieben. Was mir bei anderen Lösungen die ich gefunden habe gefehlt hat ist das Auswerten der Rückgabewerte vom rsync Befehl und darauf basierend eine entsprechende Info über den Erfolg oder Misserfolg der Sicherung.

Ebenso hat kaum ein Script eine Unterstützung für Medien die mit ZFS formatiert wurden eingebaut, da ich die Kompression von ZFS nutzen wollte habe ich das für mein Script implementiert.

Die Lösung besteht im Grunde aus folgenden Dateien:

Die Datei backup.config beinhaltet die allgemeine Konfiguration, wer soll das Infomail erhalten, Absenderadresse, Backupmedium, Dateisystemtyp,…
Welche Systeme gesichert werden sollen, wohin die Sicherung geht, wie lange die Sicherung vorgehalten wird, welche Dateien nicht gesichert werden und über welchen Port die SSH Verbindung zum System aufgebaut wird – das steht in der Datei backup-source.config.
Das Template File rsync_mail_template.html dient als Vorlage für das Infomail und das eigentliche Backup Script ist die Datei backup-rsync-remote.sh.

Mein exclude-File schaut wie folgt aus:

/proc
/dev
/media
/lost+found
/mnt
/sys
/var/cache
/var/games
/srv/backup
/var/lib/lxcfs/

Die brauche ich zum Rücksichern nicht wirklich und machen beim Sichern mehr Probleme als ein Backup der Dateien lösen kann. /srv/backup ist der Pfad in dem ich mein Sicherungsmedium einhänge, darum schließe ich das ebenfalls aus.

Ich kopiere die vier Dateien immer nach /usr/local/sbin/ und mache mit „chmod +x backup-rsync-remote.sh“ das Backup Script ausführbar. Nach ein paar Anpassungen des Backup Scripts kann es dann schon losgehen.

Wer z.B. einen Cloud Server einfach nur in ein lokales Verzeichnis auf seinem Backup Server sichern möchte (also kein externes Medium im Spiel), der fügt folgende Zeile in backup-source.config ein:

cloudserver1.example.domain|/srv/backup.cloud|30|/usr/local/sbin/excludeliste-rsync|22

Es wird also mit dem fqdn (full qualified domain namen) des Servers gestartet, anschließend folgt das Verzeichnis in dem die Sicherung abgelegt wird, die 30 sind die Anzahl an Sicherungen die vorgehalten werden, dann noch ein exclude-File mit Verzeichnissen die nicht gesichert werden sollen und am Schluss der SSH Port unter dem der Server ohne Passwort Abfrage erreichbar ist. 

Die Sicherung eines Cloud Server kann jetzt bereits gestartet werden, sofern die backup.config mit passenden Werten versehen wurde bekommt man nach der ersten erfolgreichen Sicherung ein entsprechendes Mail angeliefert.

Soll die Sicherung auf ein externes Medium erfolgen muss man noch ein paar Vorarbeiten leisten:

Will man mit ZFS arbeiten reicht es aus eine externe Festplatte ans System zu stecken, den Device Namen zu ermitteln (z.B. /dev/sdd) und anschließen die Platte mit dem Befehl „backup-rsync-remote.sh –init-zfs“ zu initialisieren. Anschließen kann direkt darauf gesichert werden. Vorausgesetzt wird dass das Paket „zfsutils-linux“ installiert ist!

Bei ext4 weise ich via Udev Regel meinen Sicherungsplatten einen eindeutigen Device Namen zu, damit ich im Backup Script nur /dev/backup_disk als Verweis zum Sicherungsmedium eingeben muss.

Eine solche Regel sieht wie folgt aus und steckt in der Datei „/etc/udev/rules/10-local.rules“:

KERNEL==“sd?1″,SUBSYSTEM==“block“,DRIVER==““,ATTR{partition}==“1″,ATTR{start}==“2048″,ATTR{size}==“7814035086″,

SYMLINK=“backup_disk“

Die passenden Werte für meine Sicherungsplatten bekomme ich vom Befehl:

udevadm info -a -p $(udevadm info -q path -n /dev/sdf1)

Wobei /dev/sdf1 entsprechend durch den Devicenamen eurer Sicherungsplatte zu ersetzen ist – am einfachsten findet man der heraus indem man die Sicherungsplatte ansteckt und sich mit „dmesg|tail“ die letzten Kernel Meldungen anzeigen lässt. 

Hat man die Udev Regel entsprechend erstellt/angepasst muss man den udev Dienst neu starten und triggern, das passiert mit folgender Befehlsabfolge:

systemctl restart udev
udevadm trigger

Anschließend sollte /dev/backup_disk existieren. Jetzt muss man die Platte nur noch für die Sicherung initialisieren:

backup-rsync-remote.sh –init-ext4

Zugegeben etwas mehr Aufwand als mit ZFS! 🙂
Jede Sicherungsplatte muss einmal initialisiert werden und bekommt dabei eine eindeutige ID zugewiesen (steht in der Datei HDID auf der Platte).

Die einzelnen Sicherungen landen dann jeweils im Verzeichnis „daily.X“ beginnend mit 0 für die aktuelle Sicherung, der Rest dürfte fast selbsterklärend sein. Wer mit „du -sch pfad-zum-sicherungsverzeichnis/*“ die Größen der Verzeichnisse prüft, der sieht wie viel sich nach jeder Sicherung verändert hat. Gesichert wird mit hard-links – in jedem daily.X Verzeichnis stecken also alle Daten vom Zeitpunkt der Sicherung drinnen.

Ich hoffe dem einen oder anderen hilft die Anleitung und mein Script dabei seine Daten zu sichern, ich würde mich über Feedback freuen und falls noch Fragen auftauchen ergänze ich den Blog-Beitrag sehr gerne und helfe weiter.

Das Script wird auch immer wieder erweitert und verbessert, wer also auf dem Laufenden bleiben möchte meldet sich am besten rechts oben mit seiner E-Mail Adresse unter „EMAIL SUBSCRIPTION“ an.

Kategorien
Allgemein

Veeam – Failed to get stat on Errno: 2. Unable to get device for path:

Nachdem entfernen eines Laufwerks kann Veeam die Sicherung eines Linux Systems nicht mehr durchführen und „failed“ mit der Fehlermeldung:

14:45:40 [error] Can’t get info for file [/srv/syslog.backup]
14:45:40 [error] Failed to retrieve mount point for [/srv/syslog.backup]

Soweit auch klar, das Verzeichnis gibt es nicht mehr! Allerdings scheitere ich auch daran die zu sichernden Dateien via Veeam Client entsprechend anzupassen.

Die Lösung ist wie immer pragmatisch, einfach mit sqlite3 CLI die Veeam Datenbank öffnen und entsprechend das Verzeichnis in der Datenbank suchen und entfernen.

sqlite3 /var/lib/veeam/veeam_db.sqlite

sqlite> select * from JobFilters;

{d6a30132-26d4-41ee-aa1c-dd7242d82e24}|{7487c858-4c06-421f-b284-aa90a1ce3608}|1|5|/var|
{df8a1212-ce58-4e28-a866-c5ccaa23ec6c}|{7487c858-4c06-421f-b284-aa90a1ce3608}|2|5|/srv/syslog.backup|

delete from JobFilters where id=“{df8a1212-ce58-4e28-a866-c5ccaa23ec6c}“;

Und schon funktioniert das Backup wieder wie gewohnt. Da ich auf den Support Seiten von Veeam keine passende Lösung gefunden habe wird’s hier veröffentlicht. Ein entsprechendes Ticket dazu wurde eröffnet.

Kategorien
Allgemein

Vergessenen Veeam Restore Point aushängen (Linux/cli)

Gelegentlich passiert es dass man nach dem Rücksichern von Dateien vergisst den Restore Point wieder auszuhängen. Ein klassischer „umount“ führt hier nicht zum Ziel weil veeam selbst noch auf dem Mount drauf hängt und diesen blockiert.

Es muss also via veeam der umount erfolgen – das klappt wie folgt:

#!/bin/bash

if [ -x „/usr/bin/veeamconfig“ ]; then
TIME=$(date „+%H%M“)
if [ $TIME -gt 1900 ]; then
VEEAMSESSION=$(/usr/bin/veeamconfig session list|grep „Mount“|grep „Running“|awk ‚{print $3}’|tr -d „{}“)
if [ „$VEEAMSESSION“ ]; then
/usr/bin/veeamconfig session stop –id $VEEAMSESSION
fi
fi
fi

Dieses kleine Script läuft bei mir stündlich ab, wird aber erst nach 19:00 Uhr aktiv und hängt verbliebene Mount-Sessions wieder aus.

Kategorien
Linux

Veeam meldet dass BTRFS nicht unterstützt wird, obwohl keines auf der Platte ist!

Auf einem frisch installiertem Linux System hat mir heute beim Einrichten von Veeam ein früher auf der Platte installiertes BTRFS einen Strich durch die Rechnung gemacht!

Veeam Meldet beim Einrichten eines Backup im „Entire Machine“ Modus dass es kein BTRFS unterstützt. Schön und gut, aber auf meine System gibt es nur ext2, swap und ext4 Partitionen…

Das Übel liegt in Master Boot Record – hier hat BTRFS früher mal etwas hinterlegt was veeam beim Einrichten der Sicherung abfrägt und somit durchaus korrekt zum Schluss kommt dass hier ein BTRFS im Einsatz ist (bzw. war).

Die Idee den MBR von Grub neu schreiben zu lassen ist wohl die naheliegendste – allerdings scheitert man hier mit folgender Meldung:

Installing for i386-pc platform.
grub-install: warning: Attempting to install GRUB to a disk with multiple partition labels. This is not supported yet..
grub-install: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged..
grub-install: error: will not proceed with blocklists.

Abhilfe schafft man hier indem man den MBR erst mal mit Nullen überschreibt und anschließend Grub wieder einen bauen lässt.

dd if=/dev/zero of=/dev/sda seek=1 count=2047
grub-install /dev/sda

Damit wurde der MBR auf meiner Platte /dev/sda erst mit Nullen überschrieben und dann von Grub neu erstellt.

Anschließend klappt es auch mit veeam! 🙂

Kategorien
Linux

Veeam Recovery mit Ubuntu Live System

Mit dem von Veeam erstellen Custom Recovery ISO Image hatte ich Probleme beim Rücksichern eines älteren HP Servers – die Broadcom Netzwerkkarten wurden nicht erkannt und ohne Netzwerk schaut’s mau aus mit der Rücksicherung!

Als einfach Lösung bietet sich ein klassisches Live System an, in meinem Fall habe ich einfach ein Ubuntu 14.04 Live System vom USB Stick gestartet und dort in der Konsole folgende Befehle ausgeführt:

echo ‚deb [arch=amd64] http://repository.veeam.com/backup/linux/agent/dpkg/debian/public stable veeam‘ > /etc/apt/sources.list.d/veeam.list
apt-get update
apt-get install veeam -y –allow-unauthenticated
echo -e ‚\n[recoveryui]\nenableOnLiveSystem= true‘ >> /etc/veeam/veeam.ini
service veeamservice restart
echo -e ‚ACTION==“add|change“, SUBSYSTEM==“block“, ENV{UDISKS_IGNORE}=“1″‚ > /etc/udev/rules.d/10-myudisks2.rules
veeamconfig recoveryui

Mit dem letzte Befehl startet die Kommandozeilen GUI über die ich dann meine Samba Freigabe mit der Sicherung gemountet habe, von dort lässt sich dann das letzte Backup ohne Probleme wiederherstellen!

Kategorien
Linux

Veeam Agent for Linux – mit E-Mail Bericht versehen

Der Windows Agent von Veeam liefert nach dem Backup einen recht netten Bericht mit dem Status der gerade durchgeführten Sicherung:

Selbige Funktion fehlt dem Linux Agent leider, dem kann man zwar durch manuelles Aufrufen der Console ähnliche Daten entlocken – wirklich praktisch ist das allerdings nicht…

Als alter Bash Liebhaber findet sich aber fast immer für jedes Problem eine Lösung, ich habe ein kleines Bash Script gebaut welches die Werte vom letzten Veeam Backup Job ausliest und mittels Template File aufbereitet und per Mail versendet.

Das Ergebnis sieht dann wie folgt aus:

Die Unterschiede sind relativ gering, mit den Daten kann man aber auf jeden Fall was anfangen!

Hier gibt es das kleine Script zum Herunterladen:

http://www.grufo.com/veeam_mail.sh.txt

und das dafür nötige Template File:

http://www.grufo.com/veeam_mail_template.html

Seit Version 0.5 ist auch diese Config Datei nötig:

http://www.grufo.com/veeam_mail.config

Ich habe die beiden Datein auf meinem Linux System unter /usr/local/sbin/ abgelegt, der Pfad zur Template Datei ist entpsrechend im Script anzupassen – ebenso wie Absender und Empfänger Mail Adresse und der Name des Backup Jobs.

Man kann das Script als Post-Job Script beim Veeam Job mit angeben, sollte der letzte Job noch nicht fertig sein beendet sich das Script ohne weitere Meldungen.

Fehler werden auch entsprechend farblich gekennzeichnet und mit den Error Meldungen aus dem Logfile versehen:

Mir fehlt im Moment noch eine „Warning“ Mail vom Windows Agent damit ich die auch noch entsprechend anpassen kann, dürfte aber nur eine Frage der Zeit sein.

Ich hoffe ich kann mit dem kleinen Script auch anderen Veeam Nutzern eine Freude bereiten – positives Feedback ist willkommen! 😉

27.09.2017 – Update:

Ein paar kosmetische Änderungen habe ich noch vorgenommen, die Details kommen jetzt mit Zeilenschaltungen daher und nicht mehr in einer Wurst, die Agent Version vom Linux wird mit angegeben und Warnings erscheinen in orange.

2018.01.30 – Update Version 0.4: Nachdem das Script als Post-Script nicht funktionierte (siehe Kommentare) habe ich es ein wenig modifiziert, es forkt sich jetzt selbst und läuft verzögert im Postscript durch. Voraussetzung dass es überhaupt läuft es ein dummy-Pre-Script, ohne dieses kommt es vor dass veeam kein Post Script startet – ein Bug der wohl mit der nächsten Version behoben sein wird. Danke an Jens, Jan und Peter für’s Testen und Bugfixen! 😉

2019.04.25 – Update Version 0.5: Ich habe die Bugfixes der letzten Monate und ein paar Anregungen einfließen lassen und mich entschlossen die Version 0.5 frei zu geben. Die wichtigsten Änderungen in Kürze – Auslagerung der Config-Variablen in eine eigene Datei (veeam_mail.config), damit Updates einfach installiert werden können ohne Anpassung irgendwelcher Werte. Anzeige des Pfades auf welchem die Sicherung zuletzt gesichert wurde. Und eine Funktion die (falls aktiviert – SKIPUPGRADECHECK in der Config Datei) prüft ob eine neue Programmversion existiert und gegebenenfalls im Mail eine Info mit ausgibt.

http://www.grufo.com/veeam_mail.sh.txt
http://www.grufo.com/veeam_mail_template.html
http://www.grufo.com/veeam_mail.config

Für die nächste Version hätte ich dann geplant dass ich die Mails am Mailserver per Script auswerte und die Daten in einer Datenbank sammle. Diese sollen dann via PHP Script grafisch aufbereitet werden so dass man auf einer Übersichtsseite sofort alle Sicherungen im Blick hat.

Wie immer freue ich mich auf euer Feedback! 🙂

2019.05.07 Update Version 0.5.3: Damit es nicht langweilig wird habe ich das Tool noch ein wenig erweitert – jetzt erscheinen auch lokal gemountete Laufwerke und es wird versucht den benutzten und zur Verfügung stehenden Platz auch mit ins Mail zu packen. Download – siehe oben.

2019.07.23 Update Version 0.5.5: Zwei neue Config Parameter habe ich in der Datei veeam_mail.config hinzugefügt, sie dienen dazu zuverlässige den freien Platz bei CIFS gemounteten Backup Laufwerken zu ermitteln. SMBUSER und SMBPWD, die Datei sollte anschließend mit passenden Rechten versehen werden (chmod 600 veeam_mail.config) weil das Kennwort darin im Klartext angegeben werden muss. Sicher nicht die perfekte Lösung, aber sie funktioniert und jemand der so weit ins System eingedrungen ist dass er hier lesen kann dürfte sowieso schon genügend Schaden anrichten können. Wer eine andere einfach umzusetzende Idee hat – nur her damit!

2020.02.04 Update Version 0.5.9: Neue Config Option „DEBUG=1“ welche beim Aufruf von „veeam_mail.sh –bg“ direkt ein paar Debug Ausgaben liefert. Version 0.5.6 bis 0.5.8 haben ein paar kleine Fehler bei der Darstellung behoben.

2020.02.07 Update Version 0.5.10: Ich habe das Script umbenannt und auf Github angesiedelt, davon verspreche ich mir eine bessere Dokumentation bei Updates und Fehlern. Zu finden auf Github unter https://github.com/grufocom/vee-mail

Kategorien
Linux

Veeam Backup Agent for Linux Free Edition

Vor ein paar Wochen habe ich bereits die Beta Version von Veeam Agent for Linux getestet und war recht angetan von der einfachen Backup Lösung.

Inzwischen gibt es Veeam Agent for Linux in einer Free Edition. Aus meiner Sicht ideal für kleine Firmen oder im privaten Einsatz – blockbasierte Sicherung auf externe Platten oder ein Netzwerk-Share.

https://www.veeam.com/linux-backup-free.html

Mit der blockbasierten Sicherung und dem integrierten Snapshot Treiber hat man eine zuverlässige und sehr schnelle Sicherungslösung. Bedienbar via CLI oder GUI.
Die Sicherungen lassen sich auch jederzeit im System mounten und einzelne Dateien rücksichern. Dank Recovery Boot Medium ist nach einem Totalausfall das System schnell wieder am Start.

Auf jeden Fall einen Versuch wert! Für Windows gibt es die Free Edition ja schon etwas länger…

Mit dem zum Download angebotenen Paket wird im System eigentlich nur das Repository von Veeam eingetragen, die eigentliche Installation erfolgt im Anschluß daran durch „apt-get install veeam“.

Der Eintrag für’s Repo sieht wie folgt aus:

deb [arch=amd64] http://repository.veeam.com/backup/linux/agent/dpkg/debian/x86_64 noname veeam

Nach der Installation kann man durch einfaches Aufrufen von „veeam“ den Client in der Konsole starten. Konfiguration und Backup dass es einfacher fast nicht mehr möglich ist…

Sollte man auf jeden Fall mal ausprobiert haben!

Kategorien
Linux

rsync-Backup – jene Daten finden die gesichert wurden

Wer mit rsync und hardlinks Sicherungen erstellt hat eventuell das Problem dass er wissen möchte welche Daten sich zwischen zwei Sicherungen verändert haben, nicht jedes rsync-Backup Script protokolliert das bzw. verliert man bei 30 oder mehr Backups schon mal den Überblick.

Bei meiner Sicherung werden die einzelnen Sicherungen in Verzeichnissen mit der Bezeichnung daily.0 bis daily.30 gespeichert. In jedem Verzeichnis findet sich der Stand vom entsprechenden Tag von der letzten Sicherung die x-Tage zurückgerechnet.

Möchte man also wissen welche Datei gesichert wurde muss man jene finden die nur einen Hardlink besitzt, alle anderen wurden von einem der Vortage übernommen!

Hier hilft uns folgender Befehl:

find daily.2 -type f -links 1

Das „-links 1“ findet nur jene Dateien die einen einzigen Hardlink besitzen – ein Hardlink ist bei dieser Form der Sicherung das Minimum weil daily.0 und daily.1 ident sind und somit immer mindestens ein Link zum vorherigen Verzeichnis besteht.