Anbieter zum Thema
Agents unter Kontrolle
Aber vor der Sicherung entfernter Systeme steht zunächst die Installation der entsprechenden Agents auf den Zielrechnern. ABR 11 liefert dazu alle Werkzeuge, die für das Roll-Out auf Windows Systeme notwendig sind.
Im entsprechenden Menüpunkt kann man die Auswahl der gewünschten Server und Workstations über die Netzwerkumgebung, eine Liste mit Hostnamen, IP-Adressen oder das Active Directory vornehmen. Vor dem Start des Roll-Out testet der Wizard die Verbindung zu den Rechnern und fragt auch die möglicherweise notwendigen Zugangsdaten an.
Das funktioniert sowohl bei einer Authentisierung über das Active Directory als auch bei einer rein Windows-netzwerkbasierten Auswahl. Insgesamt dauert das Kopieren und Installieren auf dem entfernten System etwa drei bis fünf Minuten. Ein Neustart ist nicht notwendig, man erkennt als Nutzer das Vorhandensein des Agents eigentlich nur am neuen Menüeintrag mit der Deinstallationsroutine im Startmenü.
Moderate Serverbelastung durch das Backup
Während eines laufenden Backups zeigten sich die zusätzlichen Belastungen erfreulich moderat. Selbst ein betagter Testrechner mit AMD Sempron 2500 Prozessor und 512 MByteRAM unter Windows XP musste nur mit einer zusätzlichen Belastung zwischen 5 und 15 Prozent klarkommen.
Bei den Testservern mit aktueller Hardware bewegten sich die Belastungen immer unter 10 Prozent. Selbst die Aktivierung von Verschlüsselung und Kompression führte auf Core2 Duo und Quad Core Prozessoren zu keinen übermäßigen Lastspitzen, im Schnitt nahmen Backupaufträge dann 30 Prozent CPU-Zeit in Anspruch.
Wie bei den meisten Imaging-Lösungen hängt auch hier die Leistung von der Hardware ab. Schnelle Festplatten und Gigabit-Ethernet sorgten für rasante Image-Sicherungen und Restore-Vorgänge. Bei älterer oder nicht optimierter Hardware fielen die Leistungswerte dagegen ab.
Flottes Netzwerk ein Muss
Im Test fiel auf, dass die Netzwerkanbindung mehr Einfluss auf den Sicherungsvorgang hatte, als die Transferleistungen der Festplatten. Das sollte beim Einsatz als Sicherungstool für Server wenig Einfluss haben, dort ist längst Gigabit-Ethernet, wenn nicht sogar 10 GbE, Standard.
Allerdings muss auch der Switch in der Lage sein, mit den übertragenen Datenmengen mitzuhalten. Unsere Empfehlung ist, statt viele Storage–Nodes als Zusatzdienst auf Servern zu definieren, lieber wenige, aber dafür dedizierte Server als Storage-Nodes zu nutzen und diese auch in den entsprechenden Netzwerksegmenten der Zielsysteme zu platzieren.
Die Sicherungen selbst erfolgten in unserer Testumgebung problemlos, sowohl von den Windows-Servern und Workstations unter allen genutzten Betriebssystemen als auch bei Fedora. Der Vorteil, der durch die zentrale Veraltung entsteht, zeigte sich auch schon bei unserem, relativ überschaubaren, Testnetz.
Die zentrale Konsole verschafft den Überblick
Mit verschiedenen geplanten und laufenden Aufträgen zur gleichen Zeit ist es ohne gemeinsamen Sammelpunkt für Meldungen schwierig, den Überblick zu behalten. Diese Aufgabe übernahm das Dashboard in der zentralen Konsole ganz ohne Schwierigkeiten.
Auch die Verwaltung der zahlreichen Backup-Pläne, Richtlinien und Gruppen, wurde durch die Konsole deutlich erleichtert. Im Test gab es auch keine Probleme mit Abbrüchen bei der Sicherung und Wiederherstellung, von denen teilweise in der Knowledgebase berichtet wird.
Die Jobs wurden zuverlässig gestartet, ausgeführt und dokumentiert. Nachdem wir uns mit dem Konzept der Depots angefreundet hatten, war es auch kein Problem, die Images wiederzufinden.
Den dritten und letzten Teil über Virtualisierung und Wiederherstellung lesen Sie morgen.
(ID:2053137)