Backup Next Generation

Thomas Nau 09. Mai 2017

Backup Next Generation – Erkenntnisse aus einer Umstellung

Bacula ist sehr einfach und zentral konfigurierbar. © everythingpossible / Fotolia.com — © everythingpossible / Fotolia.com

Kooperationen im IT-Bereich der Hochschulen und Universitäten von Baden-Württemberg haben eine lange Tradition, so auch im Bereich der Datensicherung und Archivierung. Die Anfänge – stets stark gefördert und unterstützt durch das Ministerium für Wissenschaft, Forschung und Kunst Baden-Württemberg (MWK) [1] – reichen hierbei zwei Jahrzehnte zurück. Standen zu Beginn die gemeinsame Beschaffung, insbesondere der Software, sowie der enge Erfahrungsaustausch im Vordergrund, so entwickelte sich die Kooperation mit dem kontinuierlichen Ausbau des Landeshochschulnetzes BelWü [2] immer mehr zu einem verteilten Betriebsmodell. Die Verbindung der Hochschulstandorte mit Bandbreiten von 10Gbit/s – aktuell bis zu 100Gbit/s – schuf die Voraussetzung Hardware und betriebliches know-how auf wenige Standorten zu konsolidieren.

Dieser Artikel fasst die Geschichte der Bildung eines dieser Backup-Verbünde – bestehend aus den Universitäten Konstanz, Tübingen und Ulm – bei gleichzeitigem Wechsel der Basistechnologie zusammen. Die im Zuge der Umstellung aufgeworfenen und diskutierten Fragen möchte der Autor auch als Anregung für die eigene Infrastruktur der Leser verstanden wissen.

Historie

Der o.g. Einsatz einheitlicher Software – des Tivoli Storage Manager (TSM) – hat sich über einen Zeitraum von rund 15 Jahren auf Grund der sich daraus ergebenden Synergien weitgehend bewährt. So wurde eine sehr erfolgreiche Arbeitsgruppe ins Leben gerufen, die sich standortübergreifend mit Fragen zur Datensicherung und Archivierung beschäftigt und die notwendigen Entscheidungen technisch vorbereitet. Die Nutzung von Synergien dient auch zur Erhöhung der Betriebssicherheit, etwa durch Off-site-Spiegeln kritischer Daten.

Allerdings wurden 2013 auch zunehmend Unzulänglichkeiten sichtbar. Zum einen wurde an einigen Stellen immer mehr eine "das haben wir immer so gemacht"-Einstellung spürbar, zum anderen zeigte sich im Rahmen eines Lizenz-Audits deutlich die fehlende Planungssicherheit hinsichtlich der zukünftigen Kosten. Beides Probleme, die in den hoch-dynamischen Forschungs- und Lehrumgebungen der Hochschulen nicht hinnehmbar waren. Noch schwerwiegender war jedoch, dass mangelnde finanzielle Planungssicherheit ein generelles Problem auch vieler anderer alternativer Lösungen zu sein schien, so die Folgerung aus einer durchgeführten Marktevaluierung.

Sowohl die 5-Jahres-Lizenzierung auf Volumen- als auch auf Basis der Prozessorleistung sind für die oft dezentralen IT-Installationen der universitären Forschungsumgebungen denkbar ungeeignet um zukunftssichere Etatplanungen vornehmen zu können. Beispielsweise war die Tatsache, dass die in der Physik eingesetzten Compute-Systeme mit geringem Datenvolumen auf Grund ihrer Prozessorleistung mit einem Vielfachen der Kosten der zentralen SAP-Systeme zu Buche schlagen, intern nicht vermittelbar. Die für die Zukunft zu erwartende unkalkulierbare Kostenentwicklung war weder hinnehmbar noch zu stemmen.

Die Entscheidung

Neben dem genannten finanziellen Risiko führte vor allem auch der erhebliche personelle Aufwand für die notwendige "Buchführung" 2013 am Kommunikations- und Informations-Zentrum (kiz) [3] zu der Entscheidung, zeitnah neue Wege zu beschreiten. Nach einer gemeinsamen Entscheidung aller Partner sollte die Zusammenlegung der Einzelinstallationen der Universitäten Konstanz, Tübingen und Ulm zu einem neuen, vom kiz betriebenen Verbund, auf Basis einer alternativen Software-Lösung geschehen.

Eckpunkte für einen Neustart

Die entscheidenden Forderungen an die zukünftig zum Einsatz kommende Software lassen sich wie folgt zusammenfassen:

einfaches und langfristig planbares Lizenzmodell
- kein verstecktes Risiko
- keine versteckten Personalkosten zur Verwaltung von Lizenzen
tauglich für universitäre Größenordnungen und hochschulübergreifenden Einsatz
- Milliarden Dateien, Petabytes an Daten in allen möglichen internationalen Zeichensätzen
- tausende Rechner mit "exotischen Betriebssystemen" an mehreren Standorten im Land
dauerhafter (lesender) Zugriff auf Daten ohne Kosten
- offen gelegte und dokumentierte Formate, Schnittstellen, …
- keine Lizenzierung für lesenden Zugriff
Umsetzung der Migration an allen beteiligten Universitäten – Konstanz, Tübingen und Ulm – bis Ende 2016, dem Ablaufzeitpunkt der bestehenden Wartungsverträge für die damals eingesetzte Software
- (parallele) Nutzung vorhandener Hardware

Auf den ersten Blick scheinen diese Kriterien eine klare Präferenz für Open Source-Lösungen auszudrücken, jedoch sahen wir diese durchaus auch kritisch. Insbesondere die oft unverhältnismäßig schnellen Release-Zyklen – ggf. sogar mit API-Änderungen – sowie die Zukunftssicherheit kleinerer Projekte weckte Bedenken bzgl. der Tauglichkeit für einen Regionalverbund.

Eine weitere richtungweisende Entscheidung betraf den Leistungsumfang der neu zu etablierenden Lösung. Stabil und ausgereift für die Grundversorgung der Universitäten sollte höhere Priorität haben als die Abdeckung aller erdenklichen Sonderfälle. Wichtiges gemeinsames Verständnis war es daher auch, Probleme erst zu lösen, wenn sie wirklich auftreten und sie nicht schon im Vorfeld virtuell zu erschaffen. Diese Entscheidungen adressieren auch eines der typischen Probleme im IT-Umfeld – meist als "Nerd-Problem" bezeichnet – nämlich das Ungleichgewicht zwischen Aufwand für die Anwendungsoptimierung und daraus resultierendem Nutzen.

Eine vielversprechende Lösung

Nach einer ersten Marktevaluierung und Gesprächen mit Anbietern zeichnete sich schnell eine für uns ideale Lösung ab, nämlich das Beste aus Open und Closed Source zu kombinieren:

Eine frei für viele Plattformen verfügbare Open Source-Basis,
ergänzt um kommerziellen Support,
ggf. ergänzt um Closed Source-Entwicklungen zur Erweiterung des Funktionsumfangs
- akzeptabel, solange Datenformate usw. davon unberührt bleiben und
idealerweise ein Dienstleister, der
- groß genug ist, um eine breite Kundenbasis und die Diversität bei Hard- und Software bedienen zu können und
- klein genug ist, um engen Kundenkontakt zu pflegen und das Umfeld zu kennen und zu verstehen.

Das Erfolgsmodell "SOGo" auf dessen Basis das Kommunikations-, Informations-, Medienzentrum (KIM) [4] der Universität Konstanz Dienstleistungen für uns erbringt, diente hierbei als Vorlage.

Die Entscheidung, einen Proof of Concept für das Projekt auf Basis der Bacula Enterpise Edition (BEE) der Schweizer Firma Bacula Systems durchzuführen, fiel im Januar 2014. Empfehlungen von Kollegen an Universitäten im In- und Ausland waren hierbei ebenso entscheidend, wie die Verfügbarkeit für alle eingesetzten Plattformen und die Nutzbarkeit vorhandener Hardware. Dabei handelt es sich um SPARC-basierte Server und IBM 3592-E07-Laufwerke nebst zugehörigem Bandroboter. Die Kompatibilität zur quelloffenen Bacula-Community Edition und die Dokumentation der verwendeten PostgreSQL-Datenbankschemata garantierten dabei den Zugriff auf die Daten auch für den Fall, dass der subscription-basierte Lizenzvertrag in Zukunft nicht verlängert würde.

Ein sportlicher Zeitplan

Um zukünftig auch die Vorteile einer Zwei-Vendor-Strategie effizient nutzen zu können, müssen beide Anwendungen in vergleichbarem Umfang produktiv zum Einsatz kommen. Dies war für TSM bereits lange der Fall, jedoch hatte Bacula als "Neuling" hier noch einige Hürden zu nehmen. Wie so oft waren die höchsten davon nicht-technischer Natur.

Um diese Ziele zu erreichen musste Bacula also innerhalb kürzester Zeit und möglichst flächendeckend produktiv zum Einsatz kommen, was zwangsläufig einen engen Zeitplan nach sich zog.

Zeitraum	Meilenstein
April – Juni 2014	Proof of Concept (POC)
Juli – August 2014	Pilotbetrieb am kiz, Planung des Produktivbetriebes für Ulm
ab September 2014	Produktivbetrieb am kiz
bis Dezember 2014	Abschluss der Migration der vom kiz betreuten zentralen IT-Systeme der Universität Ulm
ab Dezember 2014	Start der Migration aller anderen Server in Ulm sowie der Systeme in Konstanz und Tübingen
bis Dezember 2015	Abschluss der Migration aller Systeme der Universität Ulm

Die Umsetzung

Wichtigster Schritt vor der technischen Konzeption und ihrer Evaluierung war die gemeinsame Festlegung auf den Service-Level, den wir als inner-universitärer Dienstleister zukünftig anbieten konnten und wollten. Dabei galt es nicht nur technische Randbedingungen und die teilweise erheblichen Designunterschiede zwischen alter und neuer Lösung zu berücksichtigen, sondern auch mit der ein oder anderen "Urban Legend" aufzuräumen. Wie nachfolgend beschrieben führte dies zu teilweise drastischen Änderungen.

Hardware

Wesentliches Entscheidungskriterium war, wie bereits erwähnt, die Verwendbarkeit vorhandener Hardware. Diese besteht aus einem Oracle SPARC-Server, auf dem der Bacula Director sowie die PostgreSQL-Datenbank läuft. Letztere stützt sich hierbei mit aktuell rund 3,5 Milliarden Einträgen vor allem auch auf leistungsstarke Enterprise SSDs.

Als Storage Daemon kommt ein x86-System zum Einsatz, an den 6 JBODs mit jeweils 60 x 4TB SAS2-Platten über mehrere Controller angebunden sind. ZFS als Filesystem sorgt dabei – wie auch beim Director – für die notwendige n+2 Redundanz und Performance. Aufgeteilt sind die JBODs in insgesamt 3 ZPools, einen für jede der drei Universitäten.

Abgerundet wird die Storage-Seite durch 8 fiber-channel-basierte IBM 3592-E07 Band-Laufwerke. Diese bieten pro Band eine unkomprimierte Kapazität von 4TB und Übertragungsraten von mehr als 250 MB/s. Integriert sind diese Laufwerke in einer Tape-Library mit mehr als 2.000 Stellplätzen.

Abb.1: Leistungsfähigkeit der Lösung. © Thomas Nau

Designunterschiede TSM vs. Bacula

Einige wesentliche Unterschiede im Design der Backup-Anwendungen hatten erheblichen Einfluss auf den zukünftigen Backup-Service der Universitäten. Während TSM einen "incremental forever"-Ansatz verfolgt und dabei im Wesentlichen versionsorientiert arbeitet – also z. B. immer die letzten drei Versionen einer Datei vorhält – verfolgt Bacula den klassischen zeitorientierten Ansatz. Es erzeugt also Inkrementelle, Differentielle und Voll-Sicherungen. Um die designbedingt auftretende Fragmentierung der Bänder in Grenzen zu halten, konsolidiert TSM die Daten auf den Medien durch Hintergrundprozesse.

Auf der anderen Seite ist Bacula in der Lage, virtuelle Voll-Backups ohne Zutun des Klienten zu erstellen. Dabei werden alle notwendigen Daten, basierend auf den Informationen der zu Grunde liegenden Datenbank, gelesen und als neues Backup geschrieben. Dies gewährleistet einen stets sehr hohe Ausnutzung der Bandkapazitäten.

Der zweite wesentliche Unterschied zeigt sich im Zusammenspiel einzelner Komponenten. Bacula setzt hier viel stärker auf einen verteilten Ansatz mit dedizierten Aufgaben unter Kontrolle einer zentralen Instanz, dem Bacula-Director. Zusätzlich wird zumindest ein Datenbankserver – oft wie in unserem Fall PostgreSQL – sowie ein oder mehrere Bacula-Storage-Daemons benötigt. Je nach Größe der Installation können diese Komponenten auch in Form virtueller Maschinen oder gemeinsam auf einem physikalischen Server laufen. Selbst unterschiedliche Betriebssysteme als Basis können parallel zum Einsatz kommen. Derartige Wahlfreiheit findet man bei TSM unserer Erfahrung nach nicht.

Auf der anderen Seite nehmen TSM-Klienten Verbindung mit dem lokal konfigurierten Server auf, wohingegen bei Bacula jegliche Aktion durch den Director ausgelöst wird. Eine Tatsache, die im Zusammenspiel mit NAT aber auch DHCP zu einigen Kopfschmerzen geführt hat. Die in der Zwischenzeit verfügbaren Versionen 8.6 Bacula Enterprise Edition bzw. 7.6 Bacula Community Edition adressieren das Problem jedoch.

Als weiterer Unterschied soll nicht ungenannt bleiben, dass Bacula sehr einfach und zentral über Textdateien konfigurierbar ist. Dies schließt auch die pro System zu sichernden Bereiche bzw. deren Ausnahmen mit ein. Eine Client-seitige Konfiguration ist auf Wunsch ebenfalls möglich. Nennenswerte Ausnahme der zentralen Konfiguration sind die Zertifikate, auf deren Basis ein Klient Daten transparent für den Director verschlüsseln kann.

Nachfolgend sind einige Vor- und Nachteile aus unserer damaligen Sicht hinsichtlich der Sicherungsstrategien zusammengefasst.

TSM Pro

In der Regel relativ konstante und damit berechenbare Sicherungszeiten.
Durch den incremental-forever-Ansatz und das kontinuierliche Update der zu Grunde liegenden Datenbank stellt die Fortsetzung abgebrochener Jobs kein Problem dar.
Arbeitet sehr gut mit Systemen zusammen, die hinter NAT-Routern stehen oder die dynamische IP-Adressen verwenden.

TSM Contra

Dateien, die sich häufig ändern, benötigen besondere Konfiguration sofern längerfristige Sicherungen benötigt werden.
Fehlender Plattform-Support für Systeme wie etwa FreeNAS bzw. fehlende 64-Bit-Versionen.
Fragmentierung der Bandmedien und damit höhere Kosten sowie ggf. längere Restore-Zeiten.
Vendor-lock-in

Bacula Pro

Client-Software via Community Edition auch für "exotische" Systeme verfügbar.
Sehr einfache Installation insbesondere für Klienten.
Verteilung der gesicherten Daten auf Platten oder Bänder einfach steuerbar, was schnelle Restore-Zeiten gewährleistet, da Vollbackups immer "am Stück" abgelegt werden.
Nutzbarkeit der freier Datenbanken, etwa PostgreSQL, und des lokal vorhandenen Know-hows.

Bacula Contra

Systeme mit dynamischen IP-Adressen benötigen komplexe lokale Konfiguration.
Regelmäßige Vollbackups beschränken die sinnvoll zu sichernde Datenmenge.
Abgebrochene Jobs bedürfen ggf. manueller Eingriffe.

Welche Lösung nun letztendlich für ein bestimmtes Umfeld die geeignetere ist, kann nur entschieden werden, wenn fundiertes Wissen über die anfallenden Daten, etwa der Änderungsrate usw., vorhanden ist.

Mythen

Das für Entscheidungen notwendige Wissen über die anfallenden Daten bringt uns zu...

Mythos #1:
"Nutzer kennen ihre Daten, die sich daraus ergebenden Anforderungen und folgen einem Datenmanagement-Konzept."
Den lokalen Systemverwaltern ist hier kein Vorwurf zu machen, da letztendlich wie bei jedem lange gewachsenen System davon auszugehen ist, dass Wissen über die Jahre verloren geht. Auch fehlen client-seitig oft auch entsprechende Tools, so dass wir als Betreiber der zentralen Backup-Infrastruktur hier gefordert waren.

Mythos #2:
"Die Netzwerk-Bandbreite ist der begrenzende Faktor: Clients brauchen 10GE!"
Auch diese Aussage ist im Allgemeinen als Legende zu bezeichnen. Zwar zeigte sich, dass einige Systeme nur mit 100Mbit/s angebunden sind oder WiFi nutzen, jedoch ist in allen uns bekannten Fällen das lokale Filesystem der begrenzende Faktor. Fakt ist, dass selbst bei Anbindung mit 1GE oder mehr die allermeisten Systeme deutlich unter den theoretisch erreichbaren Bandbreiten bleiben. Zusätzlich erfordert die im WAN-Bereich auftretende Latenz meist eine Anpassung der TCP Window-Size und des Window-Scaling.

Einzig für die Vollsicherungen fällt im Falle geringer Netzwerkbandbreiten zusätzliche Zeit an. Wir lösen das Problem auf mehreren Ebenen. Bacula unterstützt die Komprimierung der Daten vor der Übertragung. Abhängig von der Art der anfallenden Daten lassen sich diese so um einen Faktor 1,5 - 2,5 komprimieren.

Der weitaus bessere Ansatz sind jedoch virtuelle Voll-Backups, bei denen lediglich und ohne Zutun des Klienten Daten zwischen den Medien des Bacula Storage-Daemons kopiert werden. Beim Einsatz von Bandlaufwerken erreichen wir so durchschnittlich Datenraten von 250-300 MB/s oder, im Falle von disk-to-disk, sogar bis zu 700 MB/s. Hervorzuheben ist, dass diese Datenraten auch mit mehreren Jobs parallel noch für jeden einzelnen als Durchschnitt über die gesamte Laufzeit erreicht werden.

Mythos #3:
"Archiv ist doch nur Backup mit langen Lagerzeiten."
Dass zu einem Archiv neben Metadaten, die eine spätere Auffindbarkeit und Nutzung auch nach Jahrzehnten gewährleisten, noch einiges anderes gehört, wird einem spätestens klar, wenn man sich diesbezüglich mit Bibliothekaren unterhält.

Doch auch kurzfristig gedacht gibt es einen entscheidenden Unterschied zwischen Backup und Archiv: archivierte Daten werden vom lokalen System gelöscht. Dieser Umstand hat natürlich in jedem Backup-System zur Folge, dass auch hier die Daten nach kurzer Zeit, oft wenigen Wochen, verschwinden.

Diese von Nutzern oft als "lokale Archivdaten" bezeichneten Verzeichnisse sind also genau betrachtet nichts anderes als "kalte Daten", die über lange Zeiträume, oft Jahre, nicht geschrieben und meist auch nicht gelesen wurden. Im Gegensatz zu TSMs "incremental forever"-Ansatz, bei dem diese Art Daten lediglich einmal gesichert werden, müssen sie im Falle von Bacula bei jedem Voll-Backup hinsichtlich der Menge berücksichtigt werden. Dies gilt auch für virtuelle Voll-Backups.

Lösbar ist das Problem über unterschiedliche Job-Parameter, sofern diese Art Daten client-seitig erkennbar sind, etwa durch geeignete Wahl einer Verzeichnisstruktur wie /archiv/2016/, /archive/2017/, …
Hier schließt sich jedoch der Kreis zu Mythos #1.

Mythos #4:
"Es existiert ein Plan für den Fall der Fälle."
Als "Fall der Fälle" definieren wir den lokalen Verlust aller oder eines Großteils der Daten eines Klienten, was in vielen Fällen zur Arbeitsunfähigkeit einzelner Personen oder ganzer Institute oder Bereiche der Universitäten führen kann.

Um für derartige Fälle gewappnet zu sein, bedarf es unserer Erfahrung nach nicht nur eines Planes, sondern auch regelmäßiger Tests und Anpassungen. Als besonders kritisch stufen wir hierbei ein:

das Schlüsselmanagement im Falle verschlüsselter Daten,
die Priorisierung der Daten für die Wiederherstellung und
die Zeiten, die für die Wiederherstellung benötigt werden.

Die beide letztgenannten Punkte entscheiden letztendlich darüber, wie lange die Arbeitsfähigkeit zumindest eingeschränkt ist.

Konsequenzen für die zukünftigen Leistungsmerkmale

Die Erkenntnis, dass an vielen Stellen falsche Annahmen, die o. g. Mythen, getroffen wurden, ist ein Schlüssel zur Verbesserung der Backup-Dienstleistung aber auch der Datenverfügbarkeit im Allgemeinen. Sowohl die Beseitigung der erkannten Schwachstellen als auch die notwendige Anpassung an das "Betriebsmodell" von Bacula hatten direkte Auswirkungen auf die Leistungsmerkmale des zukünftigen Service.

Wo herkömmliches Backup keinen Sinn macht
Ein Beispiel hinsichtlich Mythos #4 möge das verdeutlichen: Die initiale Sicherung eines Mail-Systems mit rund 80.000.000 Dateien dauerte, parallel zum Produktivbetrieb, mehr als drei Wochen. Der Schluss liegt nahe, dass eine vollständige Wiederherstellung zumindest mehrere Tage in Anspruch nehmen würde und in dieser Zeit keine produktive Nutzung des Mail-Systems möglich wäre. Da dies nicht tragbar ist, scheiden herkömmliche Sicherungskonzepte in solchen Fällen als nicht sinnvoll aus.

Eine mögliche Lösung, wie sie am kiz der Universität Ulm praktiziert wird, sei kurz mit den relevanten Vorteilen skizziert:

Wahl von ZFS als Filesystem, mit dem je 24-stündliche und 90-tägliche Snapshots vorgehalten werden
- Feinere zeitliche Granularität (eine Stunde) nach der Daten im Falle einer versehentlichen Löschung wieder herstellbar sind.
Cyrus IMAP-Server feature "delayed expunge"
- Mails werden für 48 Stunden nur als gelöscht markiert und sind für den E-Mail-Client nicht mehr sichtbar. Im Filesystem werden sie erst im Anschluss gelöscht und sind damit in den ZFS-Snapshots enthalten.
Asynchrone IMAP-Replikation
- In unserem Fall repliziert der IMAP-Server asynchron alle Änderungen am Mail-Store auf ein System an einem anderen Standort. Typische Verzögerungen liegen hierbei im Sekundenbereich. Dies vervollständigt den Schutz gegen Totalausfall eines Systems bzw. des primären Standortes.

Ähnliche Überlegungen sind für alle kritischen Systeme hinsichtlich der notwendigen Granularität und insbesondere auch der vertretbaren restore-Zeiten durchzuführen. Daten-Replikation kann hierbei auf Grund der zusätzlichen Kosten und Komplexität sicherlich nicht als Standardlösung angesehen werden.

Als Daumenregel hat sich für uns eine Begrenzung auf Systeme mit maximal 15TB an Daten bzw. 25 Millionen Dateien herauskristallisiert. Dies stellt sicher, dass virtuelle Voll-Backups in knapp 18 Stunden beendet sind und garantiert damit auch tägliche Wartungsfenster. Darüber hinaus sind nach unseren Erfahrungen die Daten von Systemen dieser Größenordnung in maximal 3-5 Tagen vollständig wieder herstellbar. Es ist jedoch ratsam, dies zumindest in Teilen zu testen.

Optimierung der Konfiguration
Auch die Backup-Konfiguration lässt sich hinsichtlich der aufgezeigten Probleme optimieren. Mehrfach wurden bereits virtuelle Voll-Backups erwähnt. Diese sind um einen Faktor 7-10 schneller und belasten die Klienten nicht für mehrere Tage. In der aktuellen Konfiguration kommen diese für alle Systeme zum Einsatz deren Vollsicherung über 500 GB umfasst oder länger als ca. 8 Stunden benötigt.

Alle anfallenden Daten, egal ob vom Klienten oder via virtuellem Backup erzeugt, werden zuerst auf den Plattensystemen abgelegt. Voll-Backups, die älter als einen Monat oder größer als 32 GB sind, werden im Anschluss zeitnah "am Stück" auf Band migriert. Im Gegensatz dazu verbleiben alle inkrementellen und differentiellen Backups für ihre gesamte Lebensdauer auf den Platten. Dieses Vorgehen trägt der Tatsache Rechnung, dass eher selten alte Daten aus der Sicherung benötigt werden und stellt bestmögliche Restore-Zeiten sicher, da "heiße Daten" auf den Platten gespeichert sind. Im Fall der Fälle können die dann benötigten Vollbackups, da keine Fragmentierung vorhanden ist, mit maximaler Geschwindigkeit von den Bändern gelesen werden.

Derzeit garantieren wir für den Normalbetrieb Aufbewahrungszeiten von 3 Monaten sowie einen tagesgenauen Full-Restore für 2 Wochen. Im günstigsten Fall sind diese sogar 5 Monate und 6 Wochen.

Fazit

Nach nunmehr 30 Monaten Produktivbetrieb durch das kiz der Universität Ulm hat sich, durch den Beitritt einiger Hochschulen und Servicezentren, die Zahl der Institutionen im Backup-Verbund auf 6 erhöht. Die Zahl der Klienten hat sich in den vergangenen 12 Monaten auf heute rund 1.000 verdoppelt. Die täglichen Sicherungen decken dabei Rechner mit unterschiedlichsten Betriebssystemen wie Windows, MacOS, allerlei Linux-Varianten, aber auch FreeBSD und Solaris ab. Dazu gesellen sich noch spezielle Sicherungsmodelle für Microsoft-Exchange und VMware-Server.

Sich auf Änderungen einzulassen und andere von den Vorteilen zu überzeugen, ist ein Schlüssel zum Erfolg.

Trotz all dieser Fakten, die für eine erfolgreiche Umstellung sprechen, muss sich der Bereich der Datensicherung und des Datenmanagements noch weiter entwickeln. Dazu gehören beispielsweise auch folgende Punkte:

Einführung einer echten Archiv-Lösung zur Datenspeicherung.
Backup-Schemata und Storage-Lösungen, die dem Wunsch nach Off-site-Spiegeln für Desaster-Recovey oder auch Systemen mit mehr als 20 TB besser gerecht werden.
Schaffung einfacher Zugriffsmöglichkeiten auf Statistiken, … für lokale System-Administratoren.

Die bewusste Entscheidung für eine "weitestgehende Open Source-Lösung" hat sich, trotz aller notwendiger technischer und organisatorischer Umstellungen, als "das Beste aus beiden Welten" eindeutig bewährt. Einige der größten Vorteile ergaben sich vor allem durch das bewusste und gezielte Hinterfragen und Aufbrechen etablierter Strukturen bzw. Vorgehensweisen. Sich dann bewusst auf Änderungen einzulassen und andere von den sich so ergebenden Vorteilen zu überzeugen, war und ist einer der Schlüssel zum Erfolg.

Das sehr positive Nutzerfeedback und vor allem auch das große Interesse, das viele andere Bildungseinrichtungen an unserem Weg gezeigt haben, bestärkt uns in der Meinung, die richtige Entscheidung getroffen zu haben.

Abschließend bleibt zu erwähnen, dass eine sorgfältig abgewogene Vielfalt von Lösungen, etwa im Sinne einer Zwei-Vendor-Strategie, technische und auch wirtschaftliche Vorteile bietet.

Quellen