Schlagwort-Archive: Symantec

Symantec Backup Exec: Bandstatus per PowerShell auslesen

Symantec Backup Exec ist eine in Windows-Umgebungen recht verbreitete Backup-Software. Seit einigen Versionen lassen sich große Teile auch über die “Microsoft-Bash” PowerShell steuern. Für meinen Zweck wollte ich eine Liste aller im angeschlossenen Bandwechseler eingelegten Bänder und deren Status, so kann ich feststellen welche entnommen werden sollen. Im ersten Schritt muss das PowerShell-Modul geladen werden:

Nun wird die Liste der Bännder im Wechsler ausgelesen – hier lässt sich feststellen welches Band in welchem Slot des Wechslers verfügbar ist:

Zuletzt werden die zugehörigen Banddaten wie z.B. die Dauer des Software-Schreibschutzes gelesen:

Die Daten werden in meinem Fall am Ende einer externen Schnittstelle übergeben, welche die Bandstati sortiert und entsprechende Warnmeldungen zur Entnahme generieren kann.

Backup Exec: Speicherplatzbedarf bändigen

Symantec Backup Exec kennt seine Backups – leider für einige Fälle zu gut. Standardmäßig wird für jede Sicherung eine Liste der gesicherten Daten, also z.B. die Liste aller Dateien, im Katalog auf der Festplatte des Backupservers abgelegt. Wird das Zielmedium später überschrieben werden auch die Daten gelöscht – wer jedoch Langzeitsicherungen erstellt oder Sicherungsdatenträger aussortiert wird auf Dauer mit einem nicht unerheblichen Platzverbrauch konfrontiert. Mehrere hundert Gigabyte sind so schnell zusammen, welche üblicherweise unter %ProgramFiles%\Symantec\Backup Exec\Catalogs\*SERVERNAME* landen. Doch sind diese Daten wirklich noch notwendig? Ist es nicht auch akzeptabel bei Rücksicherungen, welche älter als einige Monate sind, einige Minuten länger zu warten und bei Bedarf den Katalog neu vom Zieldatenträger zu laden? Um hier Ordnung zu schaffen gibt es gleich drei Lösungen

1. Katalog verschieben

Wer noch an anderer Stelle genügend Platz hat und die Kataloge weiterhin im Direktzugriff haben möchte kann den Katalogordner an ein anderes Ziel verschieben. Die nötigen Infos sind unter TECH74582 zu finden – zwar für deutlich ältere Versionen, die Option sollte sich jedoch auch weiterhin in den Menüs verstecken.

2. Kataloglebensdauer einstellen

In den Optionen gibt es die Möglichkeit Dateilisten nach einer gewissen Zeitspanne zu verwerfen. Der zugehörige Artikel findet sich unter TECH7297 – die Option ist wie auch zuvor in den Menüs weiterhin zu finden. Leider greift die Option nur für neu angelegte Kataloge, ältere müssen ggf. manuell entfernt werden.

3. Manuelles löschen

Auch manuell lässt sich der Ordner aufräumen. Hierzu müssen erst alle Dienste des Backup Exec-Systems gestoppt werden. Im Anschluss löscht man alle *.fh und *.xml-Dateien im Katalogverzeichnis, welche älter als das gewünschte Datum sind. Andere Dateien sollen laut Symantec-Forum nicht gelöscht werden – zwar denke ich nicht, dass diese Aussage für Einträge mit gleichen UUIDs korrekt ist, da die übrigbleibenden Dateien jedoch nur wenige KB groß sind habe ich dies nicht weiter geprüft. Da nun Datenbank und Ordner inkonsistent sind ist ein Reinigungslauf notwendig, hierzu startet man im BE-Verzeichnis den Befehl “CatRebuildIndex.exe -r” als Administrator. Dies kann einige Zeit in Anspruch nehmen.

Alles keine schönen Lösungen, aber irgendwann ist auch der größte Platz mal voll und Migrieren macht mit Windows keinen Spaß.

Symantec Backup Exec (RALUS) auf Arch Linux

Symantec hat für ihr Produkt “Backup Exec” auch einen Agenten im Angebot, welcher die Sicherung von Linux- und Unix-Systemen ermöglichen soll. Dieser so genannte “Remote Agent for Linux and Unix Servers” aka RALUS hat leider eine sehr eingeschränkte Kompatibilitätsliste. Zwar gibt es im Netz einige Anleitungen für Debian, für Arch wurde ich aber nicht fündig. Nach ein paar Versuchen war mir die Herkunft der Paketbeschreibung eines Repos für CENTOS auch klar:

It is a crappy tool and you should seriously consider not using it.

Nicht nur, dass die Installationsdaten lediglich versteckt als deb und rpm vorliegen: Teile der Config werden über ein Wirrwarr an Perl-Scripten generiert und bei der Nutzung mit Kerneln >=3 muss man am Kernel oder im Binärcode herumpatchen. Great!

Nungut, inzwischen läuft der Daemon, ein passender PKGBUILD für die mir vorliegende Version (14.0.1798-0, 64 Bit) ist auf Github zu finden. Mit drin ist der Binärpatch für Kompatibilität mit Kernel 3.x sowie etwas Rechtefoo. Da das Ganze mehr eine Vorlage als funktionsfähiges PKGBUILD darstellt wandert’s erst mal nicht ins AUR.