Das Produkt enthält ziemlich viele Features, allerdings, so kommt es mir zumindest vor, enthält jedes Feature mindestens 2 Fehler die zum Abbruch der Sicherung führen können. So stellt man bereits bei der Installation fest, das BE12 anscheinend NetBIOS over TCP/IP benötigt, was eigentlich in den meisten größeren Netzwerken nicht mehr verwendet wird. Zumindest meldet der Umgebungstest bereits eine Warnung, sollte NetBIOS over TCP/IP auf dem Server deaktiviert sein. Ebenfalls schon im Vorfeld meldet die Prüfung, das die Firewall des Servers doch bitte deaktiviert werden solle. Ist die Vorabprüfung überstanden, beginnt die eigentliche Installation. Setup fragt nach einem Account mit Administrativen Rechten auf dem Lokalem Server, unter dem die BE12 Dienste ausgeführt werden sollen. Eine Option zur Verwendung des Kontos „lokaler Dienst“ oder „Netzwerkdienst“ ist nicht vorgesehen. Erstellt man vorher einen dezidierten Backup-User, so muss dieser ebenfalls über Administratorrechte auf dem Server verfügen. Hat man zähneknirschend einen passenden Benutzer angegeben, fragt Setup im nächstem Schritt nach einem passendem Datenbankserver. Gibt man nun einen bestehenden SQL-Server (Microsoft SQL-Server 2005) im Netzwerk an, erscheint eine Meldung, das die Instanz des SQL-Servers unter dem Backup-Exec Benutzer ausgeführt werden muss um fortzufahren. Bestätigt man diese Meldung mit Ja, ändert Setup die Anmeldeinformationen des SQL-Server Dienstes auf den BE12 Benutzer OHNE vorher zu prüfen, ob nicht noch andere Datenbanken auf dem Server laufen. Dies hat zur folge, wenn der BE Benutzer nicht auch auf dem SQL-Server über Admin-Rechte verfügt, der Dienst aufgrund fehlender Berechtigungen im Datenbankordner nicht mehr startet. Entweder konfiguriert man nach der Installation den SQL-Server wieder „richtig“, oder man muss zähneknirschend eine lokale SQL-Instanz auf dem BackupExec Server installieren. Letzteres ist übrigens auch die Empfehlung des Herstellers. Hat man es bis hier her geschafft, fragt BE12 ob man S*mantec-Treiber für Alle Geräte, Geräte ohne Treiber oder gar keine Geräte verwenden möchte. Gibt man hier an, man möchte die Treiber nur für Geräte, die über noch keine Treiber verfügen, verwenden, kommt es mit Geräten, die die Windows-eigenen Treiber verwenden zu Problemen. So hat BE12 eine HP MSL6000 und das LTO-Laufwerk einzeln erkannt (beim versuch zu Sichern sollte man doch bitte ein Medium in das LTO Laufwerk einlegen, beim versuch auf der Library zu sichern, erscheint die Meldung „Es stehen keine nicht aktiven Geräte zur Verfügung“. Am besten gleich die Symantec-eigenen Treiber verwenden, und die Library sollte korrekt erkannt werden. Nach Abschluss der Installation startet das System neu und LiveUpdate versucht die aktuellen Updates herunterzuladen. Das herunterladen war auch nicht das Problem, die Installation scheiterte allerdings. Nach mehreren Neustarts und diversen Versuchen wurden die Updates manuell auf der Website heruntergeladen und installiert. LiveUpdate funktionierte auch nach einspielen der Updates nicht (scheiterte nach wie vor an der Installation).
Nach der Installation des Servers muss ein Anmeldekonto für Sicherungen an Remotesystemen festgelegt werden. Normaerweise sollten die Rechte eines „Sicherungs-Operators“ ja ausreichen um Daten von Servern sichern zu können. Anschließend sollten die Agents auf dem zu sichernden Systemen installiert werden. Der Assistent lief problemlos durch und installierte den Agent. Anschließend war der Server allerdings mit einem gelben Ausrufezeichen in der Auswahl zu sehen, und es konnten nur Freigaben gesichert werden. Nach einigen Recherchen in der Support-Datenbank, musste auf dem zu sicherndem Server in den Eigenschaften des Agents der Medienserver eingetragen werden. Eigentlich sollte das die Push-Installation ja erledigen, was aber auf unbekannten Gründen fehlschlug. Nun sollte eine Testsicherung des Servers durchgeführt werden. Bei dem Server handelte es sich um einen virtualisierten (ESX-Server) ActiveDirectory Domänencontroller (Windows Server 2003 R2 SP2) mit aktuellen Hotfixes (stand 04/2008). Die Auswahl ist sehr übersichtlich und einfach gehalten. Die Testsicherung sollte den SystemState und die lokalen Festplatten sowie einen DFS Replizierten Ordner sichern. Also, den vollständigen Server (der Server selbst war teil des Test-Netzes). Also, das Häkchen auf den vollständigen Server in der Quellauswahl gesetzt, unter Optionen noch den Typ kopieren ausgewählt und als Ziel die Library angegeben. Ausführung Sofort und los geht’s. Die Sicherung startete, die Library wurde korrekt angesprochen und ein neues Medium in den Default-Pool „unbegrenzt aufbewahren“ aufgenommen, formatiert und in das Laufwerk eingelegt. Anschließend startete der kopiervorgang der lokalen Festplatten. Als der kopiervorgang fertig war, und BE12 unter verwendung von Schattenkopien den Systemstatus sichern sollte, brach die Sicherung allerdings mit dem Fehler „Verbindung zu Quellhost verloren“ ab. Sicherung fehlgeschlagen. Der quellhost war nun auch nicht mehr in der Sicherungsauswahl zu sehen. Ein blick auf das Eventlog des Quellservers zeigte eine unerfreuliche Meldung von DrWatson, das der Agent mit einem internem Fehler abgestürzt sei.
Es wurden mehrere Versuche gestartet (auch auf anderen Servern), das Problem in den griff zu bekommen, doch leider half nichts. Auch nicht die erneute Installation des BE12 Servers oder des darunterliegenden Betriebssystems. Immer der gleiche Fehler. Im Moment sind wir im engen Kontakt mit dem Symantec Email-Support, bisher sollten wir aber nur protokolle sinnloser Sicherungen, Windows-Eventlogs und andere Daten übermitteln. Eine Problemlösung ist im Moment nicht in Sicht.
Was ich während der Problemlösung auch noch feststellen musste, hat man Backup2Disk Ordner angelegt, und der Speicherplatz auf der Festplatte ist erschöpft, bricht der Sicherungsjob nicht etwa ab, sondern verlangt das einlegen eines neuen Mediums. Bei einer B2D Sicherung könnte man doch mindestens verlangen, das man Limits für die maximale Größe des Ordners angeben kann, das ist aber leider nicht der Fall. BE sichert bis die Platte voll ist und wartet anschließend unendlich lang auf das einlegen eines neuen Datenträgers. Nicht ganz das was ich mir vorgestellt habe.
Mal sehen wie lange es Dauert bis die Sicherung funktioniert. Bis heute sind 8 knapp Wochen vergangen.
Fazit: Im Vergleich zu anderen Sicherungslösungen wie zb. Yosemite Backup oder des Windows-Internen NTBackup kommt mir die Lösung extrem instabil und unausgereift vor. Zusätzlich ist die Software sehr Aggressiv gegenüber anderen Programmen/Datenbanken und sollte immer auf einem Isoliertem Server ausgeführt werden. Was die Systemsicherheit angeht, werden durch das Vorraussetzen von NetBIOS und dem deaktivieren der Firewall massive Sicherheits und Datenschutz-Probleme geschaffen, die eine Software mir einer so langen Entwicklungsgeschichte eigentlich nicht mitbringen sollte. Die nicht funktionierenden LiveUpdates, eigene Treiber und die zusätzliche, lokale Datenbank erhöhen den Wartungsaufwand und das Ausfallrisiko des Medienservers und treiben die Anforderungen an Speicher und CPU unnötig in die höhe. Der etwas unfähige Support und die langen Wartezeiten bei Email-Anfragen ziehen die Problemlösung extrem in die länge.
