Am Thu, 04 Oct 2001 schrieb Schmitt, Wolfgang (BKA-IT22):

Bisher schreiben wir mittels Verknüpfung von einem find-Befehl und cpio auf das Band. Jetzt habe ich gerade eine Rücksicherung anstoßen müssen von einem Verzeichnis, was im gesicherten Stream ziemlich weit hinten liegt, ergo werde ich hier auch noch ein paar Stunden warten müssen.

Hmm ich würde auf jeden Fall cpio durch afio ersetzen, um die Sicherheit des Ganzen zu erhöhen. afio komprimiert Dateiweise, was dafür sorgt, daß beim Kippen eines Bit nicht gleich das ganze Archiv im A* ist.

Gesichert werden ca. 140000 Dateien bei ca. 8500000 Blöcken.

Ne ganze Menge :-).

Das kann nicht der Weisheit letzter Schluss sein. Ich weiß zwar, dass es so was wie Arkeia oder ARCServe gibt, kann mir aber jemand was empfehlen, was über Katalogdateien auf dem Band verwaltet wird und es somit ermöglicht, dass man direkt an die Stelle mit den Daten spulen kann, ohne dass der der gesamte Stream durchforstet werden muss? Die Krönung wäre natürlich die Administration via Web-Browser...

Ob kostenlos oder nicht soll hier nicht die Frage sein.

Kann mir jemand Tipps/Erfahrungswerte mitteilen?

Also bei der Größenordnung würde ich das anders angehen. Ich würde einen Backup-Server da hinstellen, der über eine schnelle Netzwerkverbindung (mindestens 100 MBit, besser Glasfaser oder GBit-Ethernet) mit dem zu sichernden Rechner verbunden ist. Bei den derzeitigen Plattenpreisen kann man den mit einem entsprechend großen RAID0-Verbund aus IDE-Platten ausstatten und dann erstmal vom Produktionsrechner dorthin sichern. Anschließend sichert man dann von dem Backup-Rechner wie gehabt auf ein DLT oder ein anderes Bandmedium. IDE-Platten reichen dicke, denn außer dem Schreiben auf Band und evtl. vorher einem Komprimierungslauf arbeitet auf der Kiste ja kaum einer, das begrenzende Moment ist eher die Netzwerkverbindung. Vorteile: - Im 90%-Fall (letzte Sicherung wird benötigt) braucht man gar kein Band, die Daten sind ja noch auf der Pufferplatte. Man kann dort auch mehrere Generationen liegen lassen und so diesen Punkt noch weiter verbessern wenn das nötig ist. - Der extra Backup-Rechner kann mit einer Notinstallation der wichtigsten Programme ausgestattet werden und dann bei Bedarf für den Produktionsrechner einspringen, wenn der komplett abgeraucht ist. -Die Datenkompression (und die damit verbundene CPU-Belastung) findet losgelöst vom Produktivsystem statt. Man kann z.B. erst bzip2 oder gzip über den kompletten Tree laufen lassen und erst dann die Bandsicherung anwerfen. Oder man macht das On-The-Fly beim Sichern auf Band, das verlangsamt die Sache aber massiv. -Bei Problemen mit der Datensicherung liegt nicht gleich das Produktionssystem lahm, und im Restore-Fall hat man noch nen Plattenpuffer zur Verfügung -Man kann die sensiblen Backup-Daten relativ gut vom Produktivsystem abschotten und hat so zusätzlcihe Sicherheit gegen Angriffe. Man kann auch das Backup-System relativ leicht entfernt aufbauen (Netzwerkleitungen sind ja recht weit dehnbar). Wenn man auf dem Backup-Rechner noch einen Apache installiert und ein paar passende CGI- oder PHP-Skripte verankert ist das mit dem Web-Interface auch nicht mehr wirklich ein Problem. Nachteile: - zusätzlicher Aufwand für die Hardware, der allerdings nicht allzu hoch wird (ein einfacher PC mit ausreichend IDE-Platten reicht ja und das DLT ist eh schon vorhanden, teuer wird höchstens die zusätzliche Vernetzung) - Die Sicherungslatenz (also die Zeit, die Produktionsdaten auf das Band brauchen) wird etwas länger. Dadurch geringfügig höhere Schäden im Fall der Maximalkatastrophe (z.B. RZ-Brand), da die Bandsicherung ein paar Stunden weiter zurückliegt als sie das bei direkter Bandsicherung tun würde. - bis das ganze wirklich rund läuft ist es halt etwas Arbeit. Wir setzen das hier mit einem DDS4-DAT und ca. 25 GB zu sichernden Daten ein und sind mit dieser Methode sehr zufrieden. Bei den heutigen Plattenpreisen sind auch größere Volumen gut zu realisieren. -- MfG, Erhard Schwenk

Hi Wolfgang On Thu, Oct 04, 2001 at 07:32:05PM +0200, Schmitt, Wolfgang (BKA-IT22) wrote:

Bisher schreiben wir mittels Verknüpfung von einem find-Befehl und cpio auf das Band. Jetzt habe ich gerade eine Rücksicherung anstoßen müssen von einem Verzeichnis, was im gesicherten Stream ziemlich weit hinten liegt, ergo werde ich hier auch noch ein paar Stunden warten müssen.

tapeware, 100~135 MB/Min. je nach filegrösse, Mondstand etc. Braucht idr. zum Rücksichern einer kleinen Datei um eine minute bis max. 3 Das Spulen auf die entspr. Stelle ist ist bei dem Teil einfach genial gelöst. Es macht nicht völlig wunschlos glücklich, ist aber nahe dran.

Gesichert werden ca. 140000 Dateien bei ca. 8500000 Blöcken.

sind so ~42GB wenn das 512er Blöcke sind, ich hab so um die 53GB momentan und brauche dafür von früh um 4 bis gegen 10:30 ohne Vergleich, es hat noch ca. 0,5h overhead um die DB auszuwerten was eigentlich gesichert werden muss. Bandverwaltung incl.

Ob kostenlos oder nicht soll hier nicht die Frage sein.

für ca. 1,5kDM so viele linux server wie du magst, win clients incl. für nt server kosts extra. Imho ein guter Kompromiss wenn man sich Veritas nicht leisten kann/will was auch nicht schneller ist/sein kann bei nur einem Laufwerk. -- MfG. Falk