Der Backupdienst des URZ

Der seit 1993 durch das URZ angebotene Backupdienst  wurde im Jahr 1999 auf eine neue technologische Basis gestellt, eine Beschreibung der eingesetzten Software AMANDA erfolgte in einem früheren Beitrag ( http://archiv.tu-chemnitz.de/pub/1999/0039/data/amanda.html ).
Der erste dieser Technologie entsprechende Backupserver wurde im Sommer 1999 in Betrieb genommen, zwei weitere folgten. Diese Technologie und vor allem die damit gewonnenen Erfahrungen sollen im Mittelpunkt dieses Artikels stehen.

Aktueller Stand

• Es wird der Inhalt von Platten gesichert, die eine Gesamtkapazität von 768 GB umfassen.
• Diese Gesamtkapazität wird von 53 Fileservern  verschiedener Fakultäten und Institute bereitgestellt,  organisiert in 169 Filesystemen.

Die genannten Zahlen sollen nun etwas unterlegt werden.
Für den Dienst werden im URZ drei Backupserver betrieben, auf deren Speichermedien die Datensicherungen abgelegt werden. Diese Backupserver haben aktuell 53 Fileserver als Klienten, von denen Daten zu sichern sind. Dies bedeutet, dass regelmäßig eine größere Datenmenge von jedem in den Backupdienst einbezogenen Fileserver über das Campusnetz zu den Backupservern transportiert und dort gespeichert werden muss. (Bemerkung: Es macht durchaus Sinn, die Daten an einen anderen Ort zu transportieren, statt am bzw. neben dem Fileserver zu sichern. Es sei nur an - leider schon aufgetretene - Ereignisse erinnert, wie Diebstahl, Vandalismus, Brand, etc. Ein weiterer Grund ist die Verfügbarmachung von Backuptechnik für mehr als einen Fileserver.)
Bedingt durch die eingesetzte Technologie (siehe nächster Punkt) beläuft sich die zu sichernde Datenmenge auf 60 bis 120 GByte pro Tag, also 20 bis 40 GByte pro Backupserver. Da die Daten vor der Speicherung am Backupserver komprimiert werden,  sind täglich im Durchschnitt 15 bis 20 GByte an jedem Server abzulegen.
Das nachfolgende Diagramm zeigt über den Verlauf von drei Wochen sowohl die täglich am Backupserver agadir gesicherten Datenmengen (obere/rote Linie) als auch die an diesem gespeicherten (komprimierten) Datenvolumina (untere/violette Linie):
 
 

Über welche speziellen Ressourcen müssen nun die Backupserver verfügen?  Dies muss zum einen eine ausreichende Speicherkapazität für die Datensicherungskopien sein, zum anderen eine möglichst gute Netzanbindung, um die Datenübertragung in angemessener Zeit zu absolvieren.
Neben dem mittlerweile standardmäßigen FastEthernet-Anschluss (100 MBit/s) für jeden unserer drei Backupserver, stehen in der Summe 1365 GByte Backupspeicherkapazität zur Verfügung.

Der generellen Forderung nach einem guten Preis-Leistungs-Verhältnis sowie stabilen Speichermedien wurde durch folgende Lösungen nachgekommen:

• Einsatz von PC-Technik mit dem Betriebssystem Linux
• Backupspeicherkapazität in Form von IDE-Plattentechnik
• Einsatz der freien Backupsoftware AMANDA

Technologie

Backupgrundlagen

Der Begriff Backup steht für das Erzeugen einer Kopie von Daten, auf die im Bedarfsfall zurückgegriffen werden kann. Der Bedarfsfall ist eingetreten, wenn eine Rekonstruktion von Daten notwendig ist.
Das Anfertigen eines Backups ist primär uneffektiv, im Bedarfsfall - der jedoch relativ selten auftritt - zahlt sich dies jedoch durch einen  geringen Wiederherstellungsaufwand aus.
Eine Datenkopie sollte möglichst zeitnah zur Erstellung/Modifizierung von Daten erfolgen, jedoch den produktiven Betrieb  nicht beeinflussen.
Um den Ressourcenverbrauch durch Backup niedrig zu halten, sind nur "wichtige" Daten zu sichern und diese wiederum nur in einer Kopie. Was "wichtig" ist und was nicht, kann nur der Erzeuger bzw. der Benutzer von Daten festlegen, "unwichtige" Daten sind von der Datensicherung auszuschließen (exclude).  Die  Forderung nach nur einer Kopie wird mittels sogenanntem incremental Backup realisiert. (incremental - es werden alle die Daten gesichert, die seit der letzten Sicherung erzeugt/modifiziert wurden)
Zum Zwecke der Rekonstruktion einer kompletten Platte ist dann ggf. der Zugriff auf viele incremental Backups notwendig.
Die erstmalige Sicherung einer Platte umfasst alle Daten und wird als full dump bezeichnet.
Die Rekonstruktion einer Datenmenge sollte möglichst schnell vonstatten gehen. Um dies zu erreichen, werden von Zeit zu Zeit full dumps angefertigt. Somit beziehen sich incremental Backups immer auf einen konkreten full dump und repräsentieren gemeinsam mit diesem full dump die komplette Sicherung eines Filesystems zum jeweiligen Zeitpunkt.

Klient und Server

Zwischen einem Rechner (Fileserver) von dem Daten zu sichern sind und einem Rechner, auf dem die Sicherungskopien aufbewahrt werden sollen, muss eine zeitweilige Beziehung aufgebaut werden. Der Rechner für die Aufbewahrung der Sicherungskopien liefert die benötigte Speicherkapazität und wird als Backupserver bezeichnet, der Rechner mit den Originaldaten ist im Sinne des Backups "Kunde" des Backupservers, wird als Backupklient bezeichnet.

Basissoftware

Als Backupsoftware wird AMANDA eingesetzt. Es wird unterschieden zwischen der Software auf dem Backupserver und der Software, die am Backupklienten verfügbar sein muss.
Die Funktionalität am Backupklienten umfasst im wesentlichen drei Dinge:

1. Informationen über zu sicherndes Datenvolumen bereitstellen
2. Aufbereitung der zu sichernden Daten und Senden an den Backupserver
3. bei Bedarf zu rekonstruierende Daten vom Backupserver anfordern

1. Übernahme, Bearbeitung und Speicherung der vom Backupklienten gesendeten Daten
2. Bereitstellung der für eine Rekonstruktion benötigten Datenkopien (auf Anforderung)
3. Verwaltung aller Sicherungskopien

vereinfachte Darstellung der Sicherung eines einzelnen Filesystems eines Backupklienten:

Wie dem Bild zu entnehmen ist, untergliedert sich der Backupvorgang in mehrere Phasen:

1. Vorbereitung
2. Planung
3. Datensicherung

Die parallele Sicherung mehrerer Filesysteme von verschiedenen Backupklienten auf einen Backupserver erfordert entsprechende Ressourcen, Engpässe am Backupserver können sein: Netzinterface, CPU, Speicherkapazität. Somit kommt der in AMANDA integrierten Planungsphase für eine optimale Parallelisierung eine große Bedeutung zu. Für die Planung werden die von den Klienten eingesammelten Metadaten genutzt, wie das aktuell zu sichernde Datenvolumen.

Die nachfolgende Tabelle stellt einen Schnappschuss während aktivem Backups an einem Backupserver dar, die u.a. auch die Planungsmöglichkeiten von AMANDA illustriert. Interessante Fakten sind z.B.  die 65 zu sichernden Filesysteme ("partition"), von all diesen wurden Metadaten geliefert ("estimated"). 50 Filesysteme wurden bereits erfolgreich gesichert ("dumped"), 13 Filesysteme warten auf die Sicherung ("wait for dumping"). Nur zwei Filesysteme sind in Arbeit ("dumping"), da wegen fehlender Bandbreite ("no bandwidth") keine weiteren "dumpers" die auf Bearbeitung wartenden Filesysteme parallel sichern können.
 
 

Struktur eines Backupservers

Das folgende Bild zeigt die Backupserverstruktur in der traditionellen AMANDA-Technologie. Datensicherungen werden im Cache zwischengespeichert und anschließend auf Tapes geschrieben:

Von uns wurde dieser Ansatz etwas verändert, wir verzichten auf den Einsatz von Tapes, was zu einer vereinfachten Backupserverstruktur führt. Die Sicherungskopien verbleiben im Cache:

Derzeit setzen wir für den Cache sowohl lokale Plattenkapazität als auch über NFS montierte Plattenkapazität, von sog. Medienservern, ein. Dies führt zu folgender Struktur:

Kapazitätserweiterung

Wann ist die Erweiterung eines Backupsystems notwendig?

Werden weitere Fileserver in den Backupdienst integriert - kommen also neue Backupklienten hinzu - so muss auf der Backupserverseite die den zu sichernden Filesystemen entsprechende Backupspeicherapazität vorhanden sein oder geschaffen werden.
Mehr Backupspeicherkapazität wird auch benötigt, wenn an einem Backupklienten weitere Filesysteme mittels weiterer Platten hinzugefügt werden oder, was im letzten Jahr besonders häufig auftrat, veraltete Plattentechnik durch neue  hochkapazitive ersetzt wird.
Dieser Trend zum Einsatz größerer Plattenkapazitäten dürfte auch in den nächsten Jahren anhalten, wie die jetzt schon angebotenen Platten mit 50 GByte, aktuell gar 80 GByte beweisen.

Die künftig benötigte Backupspeicherkapazität kann auf unterschiedlichem Wege geschaffen werden:

1. Hinzufügen weiterer Medien für Backupspeicherplatz
2. Ersatz kleinerer Backupspeichermedien durch größere
3. Hinzufügen weiterer Backupserver

Backup und Netz

Die Gründe für die Nutzung des Campusnetzes für Backupzwecke wurden schon genannt, der dadurch entstehende Ressourcenbedarf soll in diesem Artikel jedoch nicht vernachlässigt werden.

Die Technologie des Backupdienstes basiert wesentlich auf der Existenz eines leistungsfähigen Netzes. Jede zu sichernde Datenmenge muss vor der Bearbeitung/Speicherung am Backupserver zu diesem übertragen werden und belastet somit das verfügbare Netz. Da die verfügbare Netzbandbreite nicht ausschließlich dem Backupdienst zur Verfügung steht, sondern auch von anderen Diensten, Applikationen (in Konkurrenz) benötigt wird, müssen die Backupaktivitäten in die Nachtstunden konzentriert werden.
Diese zeitliche Konzentration erfordert eine Parallelisierung der einzelnen Datensicherungen. Dies geschieht sowohl durch Nutzung mehrerer Backupserver als auch die Verwendung eines Backupspeichermediums, das von verschiedenen Prozessen zur gleichen Zeit beschrieben werden kann. Somit wird die verfügbare Netzbandbreite zu einem potentiellen Engpass. Die für eine Datensicherung nutzbare Bandbreite ergibt sich aus dem "dünnsten" Teil der zu nutzenden Netzkomponenten.  Dies sind die Kapazität des Netzinterfaces am Backupklienten, die des Netzinterfaces am Backupserver sowie die "dazwischen" liegenden weiteren Netzkomponenten.

Die aktuelle technische Realisierung des Campusnetzes mittels switch-Technologie ermöglicht hohe Bandbreiten zwischen Backupklient und Backupserver, unabhängig von der Lokalisierung in einem physischen Subnetz bzw. der Lokalisierung zum Backbone. Der Backbone auf Gigabit-Level verlagert die Engpässe in Bezug auf Bandbreite an das Netz-Interface der am Backup beteiligten Rechner (Backupklient, Backupserver) sowie deren Anschluss an den jeweiligen Switchmodul.
Jeder Backupserver ist mit einer FastEthernet-Karte (100MBit/s) angeschlossen,  allen gemeinsam ist der unmittelbare Anschluss an ein Gigabit-Interface.
Sollte der FastEthernet-Anschluss eines Backupservers zum Engpass werden,  kann die Bandbreite mittels weiterem Netzinterface vergrößert werden, die Backupsoftware AMANDA unterstützt dies.
In obiger Darstellung dürfte der Engpass bei denjenigen Backupklienten liegen, die nur mittels 10-MBit-Interface ausgestattet sind (hier taucht ein weiteres Problem auf: inwieweit solche Rechner ihrer Funktionalität als Fileserver gerecht werden).
 
 

Erfahrungen

Die drei Backupserver stellen aktuell eine nutzbare Backupspeicherkapazität von  1365 GByte bereit.
Dieser Speicherkapazität stehen auf der Seite der Backupklienten die schon genannten 768 GByte zu sichernder Fileserverkapazität gegenüber. Dies scheint, oberflächlich betrachtet, ein günstiges Verhältnis zu sein - ist es jedoch nicht.  Zum Problem wird die Backupspeicherkapazität jedoch, wenn mehrere Generationen (entspricht  quasi jeweils einem Schnappschuss des zu sichernden Filesystems) von Sicherungskopien angefertigt/aufbewahrt werden müssen. Es ist notwendig, drei Generationen aufzubewahren, wobei zu beachten ist, dass die älteste Sicherung erst gelöscht wird, wenn eine neue Sicherung erfolgreich erzeugt worden ist.
Weiterhin müssen die drei Generationen mehr als drei Arbeitstage überdecken, sinnvollerweise mindestens drei Wochen. Die Begründung ist, dass es durchaus Situationen gibt, in denen erst nach einem längeren Zeitraum die Notwendigkeit einer Datenwiederherstellung erkannt wird (Manipulation, Datenverfälschungen, ...) Um die  zu sichernde Datenmenge zu reduzieren, wird auf den täglichen full dump verzichtet und die Aktualität der Sicherungen mittels incremental Backups realisiert. Ein sogenannter Backupzyklus besteht somit aus einem full dump sowie darauf aufbauenden incremental Backups. Zur Zeit wird im Rahmen des Backupdienstes mit einem Backupzyklus von 7 Tagen gearbeitet, dieser Wert ist veränderbar auch in Bezug auf Sonderfälle.
Ein solcher Backupzyklus entspricht einer Generation.

Praktische Erfahrungen gehen von einem Füllstand je zu sicherndem Filesystem von durchschnittlich ca. 70% aus. Die tägliche Änderungsrate kann mit ca. 15% angegeben werden. Dies ergibt für die zu sichernde Fileserverkapazität ein je Backupzyklus zu sicherndes Datenvolumen von ca. 1228 GByte. Eine durchschnittliche Kompressionsrate auf 60% ergibt immer noch ein an den Backupservern zu speicherndes Volumen von ca. 737 GByte.  Dies der aktuellen Backupspeicherkapazität gegenübergestellt  zeigt, dass keine drei Generationen über 21 Tage aktuell speicherbar sind. Dieses Problem kann derzeit nur gelöst werden, indem die Aufbwahrungszeit auf 13 Tage gesenkt wurde.
Dabei sind in der Realität auftretende größere Schwankungen nicht eingerechnet. Während unter dem Durchschnitt liegende Sicherungskopien keine Probleme bereiten, erfordern "Spitzen" derzeit erheblichen Mehraufwand bei der Administration des Backupdienstes.

Medienserver

Die virtuelle Erweiterung das AMANDA-Caches mittels Medienserver ist eine preiswerte Investition, die sich auch als praktikabel erwiesen hat. Allerdings ist zusätzlicher Aufwand notwendig in folgenden Bereichen:

• Die Medienserverkapazitäten werden mittels expliziter Kopieroperationen aus dem Cache zu den Medienservern genutzt. Dies sind im Vergleich mit der Basis-Technologie (Speichern einer Datensicherung im Cache) zusätzliche Datentransfers, vergleichbar mit dem traditionellen AMANDA-Sicherungs-Transfer auf Tapes. Der hierbei zusätzlich anfallende Aufwand (CPU des Cacheservers, Netzlast Cacheserver - Medienserver)  findet jedoch zu Zeiten statt, wenn kein Backup läuft bzw. die Backuptechnik, bis auf eventuelle restore's, ungenutzt ist.
• Die Nutzung der Medienserverkapazitäten mittels NFS-Protokoll erzeugt auf den Medienservern (NFS-Server) extreme Lastverhältnisse.
• Es ist ein extra scheduling für die Verwaltung/Belegung der Medienserver notwendig.
• Die Plattenkapazität der Medienserver steht in Form einzelner Filesysteme zur Verfügung, somit ist die maximale Größe einer Sicherungskopie durch die jeweils verfügbare Plattenkapazität begrenzt (z.Z. 25 GByte bzw. 35 GByte). Diese Kapazität steht allerdings nur bei einem noch leeren Medienserverfilesystem zur Verfügung, im Normalfall ist der noch verfügbare Platz wesentlich geringer.
  Die Begrenzung der maximalen Filegröße auf 2 GByte gilt auch für Sicherungskopien. AMANDA bietet die Möglichkeit, größere Files in sog. chunks zu zerlegen. Somit ist mit erhöhtem Verwaltungsaufwand auch dieses Problem lösbar.
• Statt einem Rechner (Backupserver) mit genügend großem Cache, besteht aktuell jeder Backupserver aus drei Rechnern (ein Cacheserver, zwei Medienserver).

Wie schon erwähnt, sollen die "belastenden" Backupaktivitäten in den Nachtstunden anfallen. Ab 19 Uhr  stehen somit ca. 12 Stunden zur Verfügung.  Unter "belastenden" Backupaktivitäten sind die Phasen des Backups zu verstehen, die durch ihren Ressourcenverbrauch andere Applikationen beeinflussen können. Das sind die CPU-Last am Backupklienten sowie die während der Übertragung erzeugte Netzlast.  Die Gesamtlaufzeit der täglichen Datensicherung hängt somit wesentlich von der zu übertragenden Datenmenge ab. Die seitens AMANDA mögliche Parallelisierung wird in Bezug auf die Backupklienten maximal ausgenutzt. Mehrere je Backupklient zu sichernde Filesysteme werden jedoch sequentiell bearbeitet, um die Last am Backupklienten in "erträglichen" Grenzen zu halten. Wesentlichen Einfluss auf die Gesamtlaufzeit hat die Planungsphase von AMANDA, während der alle Backupklienten die zu sichernden Datenmengen melden und am Backupserver die optimale Datensicherungsstrategie festgelegt wird. Erst nach Beendigung der Planungsphase (die Metadaten aller Backupklienten müssen verfügbar sein) beginnt der eigentliche Backupvorgang, das Kopieren der Sicherungskopien. In diesen Kopiervorgang eingeschlossen ist die Kompression der Daten, die in den meisten Fällen am Backupserver realisiert wird.
 

Backupklienten

Ein Backupklient hat wesentlichen Einfluss auf die Geschwindigkeit des gesamten Backups. Ein leistungsfähiger Backupklient kann in Bezug auf Backup effektiver genutzt werden, wenn die Komprimierung der zu sichernden Daten gleich auf diesem geschieht, dies verringert die Netzlast. Weiterhin können Backups für einen solchen Klienten parallel gestartet werden, vorausgesetzt, die zu sichernden Filesysteme existieren nicht gemeinsam auf einer partitionierten Platte - AMANDA ermöglicht die Konfigurierung solcher Probleme. Die Planungsphase kann sich extrem verlängern, wenn es sich um ein Filesystem mit extrem vielen kleinen Files handelt oder gar das zu sichernde Filesystem nicht lokal am Backupklienten existiert. In letzterem Fall verdoppelt sich die Netzlast. Die Konsequenz - es sollen nur lokale Daten gesichert werden. Die in den 90-iger Jahren für den ABUS-basierenden Backupdienst gestellte Forderung nach Minimierung der Klientenanzahl hat jetzt keine Gültigkeit mehr.
Die Backupgeschwindigkeit wird ebenfalls negativ beeinflusst, wenn während der Backupphase im zu sichernden Filesystem gearbeitet bzw. sogar stark modifiziert wird - zwischen Planungs- und Backupphase geänderte Files/Verzeichnisse werden ignoriert.
Das Ausschließen von nicht zu sichernden Verzeichnissen (exclude) bringt nicht nur Vorteile gebracht, diese in Bezug auf  geringeres Transfer- und vor allem Speichervolumen, sondern auch Nachteile durch eine spürbare Verlängerung des zeitlichen Aufwands am Backupklienten.
Großen Einfluss auf die Geschwindigkeit hat j die Netzanbindung eines Backupklienten. So gibt es neben dem mittlerweile üblichen FastEthernet (100 MBit/s) noch 10-MBit/s-Anschlüsse. Allerdings fallen diese weniger ins Gewicht, da dies oft ältere Rechner mit kleineren Plattenkapazitäten sind.

Probleme bereitet zur Zeit die Konfigurierung von time out's, dies sind Zeitvorgaben, innerhalb derer ein Backupklient Daten geschickt haben muss. Für einige wenige Backupklienten gibt es die Notwendigkeit, dafür größere Werte zu definieren. Diese höheren Werte gelten für alle an einen Backupserver angeschlossenen Klienten. So kann die eigentliche Datensicherung erst nach Abschluss der Planungsphase gestartet werden, also wenn die Planungsdaten von jedem Backupklienten gesendet wurden. Eine Separierung dieser speziellen Backupklienten durch Konzentration an einem bestimmten Backupserver ist aus Kapazitätsgründen bisher nicht möglich.
 

Netzanschluss der Backupserver

Die obige Grafik zeigt eine durchschnittliche Transferrate um 500 KByte/s, stabilisiert seit März dieses Jahres.
Die von einigen Backupklienten erreichten Spitzenwerte sind aus dieser Darstellung nicht ersichtlich, liegen jedoch über 1000 KByte/s teilweise sogar bei 4000 KByte/s. Hohe Transferraten werden jedoch nur mit großen Datenmengen erreicht, währen der relativ niedrige Durchschnitt aus der Vielzahl von incremental Backups geringen Datenumfangs resultiert.
Die vor wenigen Wochen erfolgte Umstellung der Backupserver auf Gigabit-Technologie, jenseits des switch-Anschlusses, brachte bezüglich der aktuell drei Backupserver keine spürbaren Verbesserungen der Transferraten, dies dürfte aber bei einer künftig größeren Anzahl Backupserver der Fall sein.

Hardware, Betriebssystem und Software

Die eingesetzte PC-basierende Hardware ist die Basis für ein solches low-cost-Backupsystem, insbesondere sind dies die preiswerten IDE-Platten sowie die ARENA-Raidsysteme. Die in der Praxis gesammelten Erfahrungen beweisen, dass diese Technologie eine echte Alternative sowohl zu kommerziellen Backupsystemen auf Basis höherwertiger (und somit teurerer) Technik als auch zu  instabilen (und trotzdem teuren) tape-basierenden technischen Lösungen ist.
Das Betriebssystem Linux erweist sich auch im Backupeinsatz als genügend stabil, die Einordnung der Backupserver in die am URZ betriebene zentrale Administration ist optimal. Zur Administration gehört neben Installation, upgrades, Problembearbeitung/-behebung uam. vor allem die Überwachung dieser drei , aus 9 Rechnern bestehenden, Systeme. Eine automatisierte Überwachung ist notwendig vor allem in Bezug auf eingesetzte bestimmte technische Komponenten, wie Platten, Netzteile, Lüfter, Speicher. In einigen aufgetretenen Problemfällen, die auf Backupklientenseite kaum bemerkt worden sind, erwies sich diese Art  Überwachung als sinnvoll wie auch der unmittelbare technische Zugriff auf diese Systeme.
Die Backupsoftware AMANDA erweist sich aus Sicht des Administrators ebenfalls als stabil. Aufgetretene Probleme konnten immer gelöst werden, zum Teil mit Hilfe ergiebiger Mailinglisten der mittlerweile riesigen weltweiten AMANDA-community.
 

Zusammenfassung

Aufgrund der in mehr als einem Jahr Produktionsbetrieb gewonnenen Erfahrungen kann eine positive Bilanz gezogen werden. Es ist bewiesen, dass mit der freien Software AMANDA und dem Betriebssystem Linux  ein stabiler Backupdienst realisiert werden kann, unabhängig von Herstellern und Finanzen. Besonders hervorzuheben sind die flexibel gestaltbare Technologie sowie der Nachweis, auftretende Probleme einer Lösung zuführen zu können.
Die genutzte preiswerte PC-basierende Technik  erfordert einen höheren Wartungsaufwand gegenüber teureren Lösungen. Da die für den Backupdienst eingesetzte Technik keine Speziallösung darstellt, sondern sich in die URZ-Strategie einordnet, relativiert sich dieser erhöhte Aufwand.

Ausblick

Wichtigste Aufgabe ist die Erweiterung der Hardwarebasis, in erster Linie quantitativ, um die aufgezeigten Engpässe zu beseitigen sowie weitere Fileserver in den Backupdienst aufnehmen zu können.
Der im Jahr 1999 erneut gestellte HBFG-Antrag wurde in diesem Jahr positiv  beantwortet. Die entsprechenden Aktivitäten (Beschaffung, Aufbau, Installation) sind größtenteils abgeschlossen, so dass die neuen Kapazitäten noch in diesem Jahr in Betrieb genommen werden können.
Bezüglich der Basistechnologie wird es keine Änderungen geben.
Jedoch ist die technische Umsetzung den aktuellen Gegebenheiten angepasst worden. Neben Änderungen auf der Kostenseite ist dies besonders die Entwicklung der Plattenkapazitäten, die mittlerweile bei 80 GByte liegen und auch für die kostengünstigen ARENA-Raidsysteme zertifiziert sind.
Dies ermöglicht eine beträchtliche Erweiterung der Backupspeicherkapazitäten und eine Vereinfachung der technischen Realisierung, indem ein Backupserver nicht mehr aus einem Cacheserver sowie mehreren Medienservern besteht, sondern aus nur einem Rechner und dieser jedoch mit mehreren ARENA-Raidsystemen versehen ist. Infolge wird sich der über AMANDA hinausgehende technische sowie technologische Aufwand wesentlich verringern, während andererseits dann mehr als 10 Backupserver zu überwachen/administrieren sind.

Die Realisierung des HBFG-Projektes soll auf folgende Dinge unmittelbar Auswirkungen zeigen:

• Realisierung der avisierten Aufbewahrungszeit von mind. drei Wochen
• Separierung von aufwendigen Backupklienten an spezielle Backupserver
• Aufnahme weiterer Backupklienten

Verweise:

 http://www.amanda.org - AMANDA

 http://www.tu-chemnitz.de/urz/system/backup/backupdienst/ - Backupdienst der TU Chemnitz

Christoph Ziegler, November 2000