Hallo Joerg,

- SuSE-Hardware (etwa Low-Cost-Raid, oder Raid-5-System) - DTL-Streamer incl. Arkeia Software zur Datensicherung

DLT ist sicher schön, aber auch schön teuer und angesichts der stark steigenden Datenmengen nur für längere "Konservierungen" notwendig/sinnvoll. Für eine reine Datensicherung von Daten > 10GB würde ich einen zweiten Server aufsetzen mit großen Platten (es reichen IDE mit Software-Raid), der Nachts den Arbeitsrechner spiegelt. Vorteile: Deutlich schneller (auch als DLT), fast unbegrenzt ausbaubar (heute schon >> 100GB), deutlich billiger als DLT. Nachteile: Langzeit-Datensicherungen (z.B. Jahresabschlüsse usw.) müssen extra gefahren werden (dann reicht aber z.B. CD-ROM oder DAT). Gruß Thomas --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com

On 11-Feb-00 Peter Kuechler wrote:

...

Für eine reine Datensicherung von Daten > 10GB würde ich einen zweiten Server aufsetzen mit großen Platten (es reichen IDE mit Software-Raid), der Nachts den Arbeitsrechner spiegelt. Bis zu welchen Datenmengen würdest Du das tun oder dazu raten? Zwei Server mit jeweils 143GB (momentan) Kapazität?

Vorsicht!!!!! Eine solche Plattenspiegelung kann niemals ein ordnungsgemäßes Offline-Sicherungsmedium ersetzen. Was machst Du z.B. bei logischen Fehlern, die erst nach Wochen bemerkt werden? Die haben sich längst auf jede Plattengeneration fortgefressen. Das gleiche gilt z.B. für Virenbefall, trojanische Pferde oder auch Katastrophen (z.B. Brand des Rechenzentrums). In allen diesen Fällen ist eine Online-Sicherung auf einen zweiten Rechner völlig wirkungslos. Ein Backup-Server mit großer Plattenkapazität kann sinnvoll sein, um im "normalen" Fehlerfall den Restore zu beschleunigen. Aber vergleichbare Sicherheit mit einer Bandsicherung bietet er nicht. Das gibts erst mit einer richtig organisierten Sicherung auf Offline-Medien (auch das können Platten statt Bändern sein): - Tägliche Sicherung - mindestens 3, besser 5 Generationen rückwärts verfügbar - Wochen- und Monatsbänder noch weiter zurück verfügbar. Beispiel: 2 Sätze mit je 5 Bändern, für jeden Werktag eines, die abwechselnd benutzt werden. Außerdem wird an jedem 3. eines Monats (nicht am 1., weil da noch Abschlußarbeiten laufen können) das Montagsband ausgetauscht. Diese "Monatsbänder" dann wieder mit 5-6 Generationen rückwärts sichern. So sichern "ordentliche" Rechenzentren. Dazu muß dann aber kommen: - Dokumentierter und regelmäßig geprüfter Restore-Vorgang - Trainierte Mitarbeiter, die wissen, was bei Schäden zu tun ist - Aufbewahrung der Sicherungsbänder räumlich getrennt vom Server, am besten in einem Safe, denn die Bänder enthalten alle wertvollen Daten und sind deshalb gefundenes Fressen für Hacker! - Schriftliche Protokollierung, wann welches Band zum Sichern welcher Daten genutzt wurde (zusammen mit den Bändern aufbewahren) - Desaster-Recovery-Konzept für den "großen" Notfall, das z.B. auch die schnelle Wiederbeschaffung von Hard- und Software regelt Nur wenn das alles mit bedacht wird, ist eine Datensicherung auch tatsächlich wert, so genannt zu werden. -- =========================================================== Erhard Schwenk - alias Bitrunner =)B==o) =========================================================== No Spam replies please. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com

On Fri, 11 Feb 2000, Richard Heider jr. wrote: Hi Richard,

Vorallem beim Restore merkt man wie langsam und unzuverlässig ein DAT ist :-(

DAT-Recorder sind unzuverlässig? - Kannst du das bitte näher erklären? Oder sonst jemand. - Sind das allgemeine Erfahrungen? Wenn dem so ist - woran liegt das? Meine doch, Backups werden zur Sicherheit gemacht: und dann 'unzuverlässig' ? Dann kann man sich das ja glatt schenken. -- mit freundlichen Grüßen Hajo C Jeske u. Tux --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com

Hajo C Jeske schrieb am 13.02.2000 um 08:02:30 +0100: Hallo Hajo,

On Fri, 11 Feb 2000, Richard Heider jr. wrote:

Hi Richard,

...

Vorallem beim Restore merkt man wie langsam und unzuverlässig ein DAT ist :-(

DAT-Recorder sind unzuverlässig? - Kannst du das bitte näher erklären? Oder sonst jemand. - Sind das allgemeine Erfahrungen? Wenn dem so ist - woran liegt das?

unzuverlässig, weis ich jetzt nicht. Aber hast Du alleine mal die Bandführung eines DAT-Recorders mit dem eines DLT verglichen. Da ist das was das DAT macht schon fast Vergewaltigung;-) Da kann ich mir ohne Probleme vorstellen daß DAT unzuverlässiger wird mit steigender Anzahl der Sicherungen pro Band. Bis denne, Michael -- Real programmers can write assembly code in any language. --Larry Wall --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com

Richard Heider jr. schrieb in 1,7K (51 Zeilen):

Michael Schulz wrote:

...

Bandführung eines DAT-Recorders mit dem eines DLT verglichen. Da ist das was das DAT macht schon fast Vergewaltigung;-) Da kann

DAT-Baender sind allerdings auch fuer diese Belastung konstruiert worden, oder? HP empfielt jaehrlichen Wechsel der Baender, und laut http://www.hp.com/tape/datfaq.html#howlong loggen die Laufwerke mit, wie oft ein Band verwendet (ejected) wurde. Maximal 99 mal sollen DAT-Baender verwendet werden, laut HP. [...]

Meine Erfahrung ist allerdings, dass die Ausfallwahrscheinlichkeit eines DAT-Laufwerkes, dass ein Jahr lang regelmässig benutzt wird, schon relativ hoch ist.

1%, 10%, 50%? Welches n und was heisst "regelmaessig", wie alt waren die Laufwerke (und was ihre angebliche MTBF)? Reinigung der Koepfe laut Manual geschah?

Auch bei Bändern, hatte ich durchaus einige Zugriffsprobleme, selten zwar, aber im Vergleich zu DLT schon eine signifikante Unsicherheit.

Zugriffsprobleme != unlesbare Daten. Was genau meinst du damit?

Lange Rede, kurzer Sinn: Wenn die Daten wichtig sind und das Budget es zulässt, dann DLT; Ansonsten kann man mit DAT sicher leben - auf jedenfall besser als ohne Backup :-)

Und DAT ist immer noch wesendlich besser als floppy tape. -Wolfgang --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com

Michael Schulz schrieb in 1,2K (40 Zeilen):

Wolfgang Weisselberg schrieb am 18.02.2000 um 21:46:04 +0100:

...

Richard Heider jr. schrieb in 1,7K (51 Zeilen):

...

Michael Schulz wrote:

...

DAT-Baender sind allerdings auch fuer diese Belastung konstruiert worden, oder?

wenn man ein DAT-Band fragen könnte, glaube ich nicht, daß es das behaupten würde;-)

Du willst damit sagen, das DAT-Band-Hersteller wissentlich schlechte Qualitaet (d.h. Baender, die bewusst (zu) schnell auseinanderfallen) unter die Leute bringen?

...

HP empfielt jaehrlichen Wechsel der Baender, und laut http://www.hp.com/tape/datfaq.html#howlong loggen die Laufwerke mit, wie oft ein Band verwendet (ejected) wurde. Maximal 99 mal sollen DAT-Baender verwendet werden, laut HP.

kann man nicht gut vergleichen aber für DLT gilt 1.000.000 Kopfvorbeiläufe (tolles Wort:-) und > 30 Jahre.

Band, oder Laufwerk? Und 30 Jahre Datenerhalt (HP redet von *mindestens* 10 Jahren Datenerhalt ohne Probleme, aber vermutlich gut mehr) oder 30 Jahre in Gebrauch?

Müßte also mit 1 Jahr und 99 Sicherungen mithalten können. Die Frage ist nur wie oft läuft ein DAT bei 99 Sicherunen am Kopf vorbei?

1 * Sicherung 1 * Zuruecklesen 2 * Zurueckspulen bei Sicherungen. Bei Reparaturen kommt je nachdem 1-3 * lesen 1-3 * zurueckspulen dazu. Also ca. 400 Kopfpassagen fuer 99 Ejects. Wieviel kostet ein DLT-Band pro MB? -Wolfgang --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com

Michael Schulz wrote:

Wolfgang Weisselberg schrieb am 19.02.2000 um 05:56:24 +0100:

...

Wieviel kostet ein DLT-Band pro MB?

unkomprimiert 40GB ~180DM. Also rund 4,50 DM pro MB.

Nanu? Nach Adam Riese macht das 0,0045 DM pro MB, also nicht einmal einen halben Pfennig. Oder ca. 222 MB pro Mark. Du meintest wohl DM 4,50 pro GigaByte? christian -- Bitte kein CC: bei Antwort an Mailingliste Etikette per Mail: To: mailings-suse@gmx.de Subject: send etikette http://www.ndh.net/home/schult/etikette.html --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com

Wolfgang Weisselberg schrieb:

Michael Schulz schrieb in 1,2K (40 Zeilen):

...

Wolfgang Weisselberg schrieb am 18.02.2000 um 21:46:04 +0100:

...

Richard Heider jr. schrieb in 1,7K (51 Zeilen):

...

Michael Schulz wrote:

...

...

DAT-Baender sind allerdings auch fuer diese Belastung konstruiert worden, oder?

...

wenn man ein DAT-Band fragen könnte, glaube ich nicht, daß es das behaupten würde;-)

Du willst damit sagen, das DAT-Band-Hersteller wissentlich schlechte Qualitaet (d.h. Baender, die bewusst (zu) schnell auseinanderfallen) unter die Leute bringen?

Ich denke das es eher darum geht, das jede (oder viele?) Technologie auch ihre Nachteile hat. Bei deb Schrägspuraufzeichnungsverfahren ist es nunmal die höherer Bandbelastung/Bandabnutzung durch die Kopfumschlingung und den rotierenden Lesekopf. Klar kann man darüber diskutieren, aber ändern wird man es wahrscheinlich nicht;-) [...]

dazu. Also ca. 400 Kopfpassagen fuer 99 Ejects.

Wieviel kostet ein DLT-Band pro MB?

Falsche Frage! Die richtige Frage ist: Was kosten die Daten die gesichert werden sollen? Ganz klar, DLT ist einiges teuerer, aber dafür auch einiges sicherer! Klar setze ich privat kein DLT ein, sondern DAT weil es biliger ist und weil man auch mal ein Band zum Transport von Daten bequem mitnehmen kann. Aber im Büro kommt mir nix mehr ausser DLT ins Haus. Mir hat der Ärger mit Exabyte (bekanntlich auch ein Schrägspuraufzeichnungsverfahren) gelangt. mfg Peter Küchler Registrierter Linux-User #127408 --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com

On 20-Feb-2000 Wolfgang Weisselberg wrote: Hoffentlich "verquote" ich mich jetzt nicht;-) [...]

...

Ich denke das es eher darum geht, das jede (oder viele?) Technologie auch ihre Nachteile hat. Bei deb Schrägspuraufzeichnungsverfahren ist es nunmal die höherer Bandbelastung/Bandabnutzung durch die Kopfumschlingung und den rotierenden Lesekopf.

Ich sehe es nicht *unbedingt* als Nachteil. Wenn mir meine Daten was wert sind, habe ich eh viele, viele Baender.

IMHO hat das eine mit dem anderen nichts zu tun. Die Bandbelastung steigt mit Kopfumschlingung, das Band wird stärker abgenutzt. Das wäre so ähnlich wie wenn ich ein Auto mit fehlerhafter Spureinstellung fahren würde. Die Reifen nutzen sich natürlich schnell an, aber ich habe je genug Ersatzreifen. Klar, gehen tut das schon...

Nehmen wir den ueblichen Fall:

4 Tagesbaender Mo-Do 2 Freitagsbaender Monatsbaender zur Archivierung

Dabei wird jedes Tagesband im Jahr ca 55 mal benutzt, die Freitagsbaender ca 28 mal. Die Monatsbaender werden erst nach mehreren Jahren recycled (wenn ueberhaupt). Wie oft wuerdest du die Tagesbaender wechseln? [...]

Rein rechnerisch sieht das alles ganz gut aus...

Wenn du natuerlich tape-fs machst und swap auf tape realisierst, ist DLT vermutlich vorzuziehen.

Ach du dickes Ei...wer mach sowas?

...

Falsche Frage! Die richtige Frage ist:

...

Was kosten die Daten die gesichert werden sollen?

Nein. Wenn, dann: KWD == Kosten Wiederbeschaffung Daten %DAT == Wahrscheinlichkeit DAT-Band innerhalb Lebensdauer (10 Jahre) unlesbar KDATH == Kosten DAT Hardware KDATB == Kosten DAT Baender (Kompletter Satz) %DLT == Wahrscheinlichkeit DLT-Band innerhalb Lebensdauer (20 Jahre) unlesbar KDLTH == Kosten DLT Hardware KDLTB == Kosten DLT Baender (Kompletter Satz) KUK == Kosten UmKopieren DLD == Daten: notwendige LebensDauer in Jahren

if (DLD < 10) { vergleiche: KWD * %DAT + KDATH + KDATB KWD * %DLT + KDLTH + KDLTB } elsif (DLD < 20) { vergleiche: KWD * %DAT + KDATH + KUK + KDATB * 2 KWD * %DLT + KDLTH + KDLTB } ...

Das ist ja alles sehr interessant und ist bestimmt auch von klugen Leuten erdacht und errechnet worden. Das dumme ist nur, das uns damals in ähnlicher Form die Vorteile von Exabyte geschildert wurden. Leider entsprechen solche Schilderungen oder "Rechnungen" nicht immer der harten Realität. Wie gesagt, wir hatten vorher Datensichrung auf einem 10fach Wechsler von Exabyte laufen und immer wieder Ärger. Wenn ich daran denke, wie oft ich diesen Wechsler zerlegt habe um ein neues Laufwerk einzubauen... Seit dem wir auf einen 10fach DLT-Wechsler umgestellt haben, herrscht Ruhe. Das sind Argumente, die für mich als Admin zählen (müssen!). Stell dir vor, ich soll Daten von einem Band holen, das ausgerechnet nicht lesbar ist (hatten wir alles schon). Dafür lege ich ihm eine so interessante Rechnung wie die o.g. hin. Hast Du ungefähr eine Vorstellung davon, was der mit mir macht? :-)

...

Ganz klar, DLT ist einiges teuerer, aber dafür auch einiges sicherer!

Ist das bewiesen, oder nur ein Geruecht/eine Vermutung, das "sicherer"? Und ist die zusaetzliche Sicherheit notwendig?

Nunja, ich denke ich habe das oben schon erklärt. Natürlich nicht mit DAT, aber ahlt mit einem ähnlichen Verfahren. Die Erfahrungen habe ich oben geschildert. Sie haben mich dazu bewogen, das Verfahren komplett zu wechseln, und der Erfolg gibt mir bis jetzt recht. [...]

...

Mir hat der Ärger mit Exabyte (bekanntlich auch ein Schrägspuraufzeichnungsverfahren) gelangt.

Das ist eine IMHO unzulaessige Schlussfolgerung ... "Ich nehme keine Computer, mir haben die Probleme mit Win95 gereicht."

Das sehe ich anders! Es handelt sich um mechnisch sehr ähnliche Verfahren. Und genau diese Ähnlichkeit ist es, die diese Probleme hervorruft. Es mag sein, das sie bei DAT etwas geringer sind (nur 90 Grad Umschlingung), aber weg sind sie nicht. Von daher ist Schlussfolgerung IMHO nicht unzulaessig. -- mfg Peter Küchler Registrierter Linux-User #127408 --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com

Wolfgang Weisselberg schrieb:

Peter Kuechler schrieb in 4,2K (130 Zeilen):

...

On 20-Feb-2000 Wolfgang Weisselberg wrote:

...

Das wäre so ähnlich wie wenn ich ein Auto mit fehlerhafter Spureinstellung fahren würde. Die Reifen nutzen sich natürlich schnell an, aber ich habe je genug Ersatzreifen.

...

Klar, gehen tut das schon...

Nein, das ist ein falsches Beispiel. DAT ist ja an sich keine Fehlkonstruktion. Nimm einen Formel-1 Wagen. Die Qualifikationsreifen reichen gerade fuer die Qualifikationsrunden (dafuer haften sie eben extrem gut), die Rennreifen halten keine 2 Rennen (haften aber besser als langlebige Reifen), die Motoren muessen nach jedem Rennen generalueberholt werden (sind aber leichter).

Klar kannst du soetwas nicht fuer Paris-Dakkar oder fuer den normalen Tagesgebrauch verwenden, umgekehrt kannst du diese Technologioe nicht erfolgreich in der Formel-1 einsetzen.

Gut, sehe ich ein:-)

Wenn du Baender hast, die 100.000 mal gelesen und geschrieben werden muessen, ist DAT eben nicht das richtige. Ich hoffe, nicht *so* oft restores machen. :-) Zudem kosten DAT-Baender

Auch hier sind wir uns einig.

...

Rein rechnerisch sieht das alles ganz gut aus...

Eben. Da musst du schon anders argumentieren.

Nein, muß ich nicht. Denn jeder Statistik und jedem Rechenexempel steht nun mal die Praxis entgegen, und die sieht nunmal oft etwas anders aus. Ich hatte es ja schon geschildert.

...

...

Wenn du natuerlich tape-fs machst und swap auf tape realisierst, ist DLT vermutlich vorzuziehen.

...

Ach du dickes Ei...wer mach sowas?

Alte Grossrechner ohne Platte? :-)

Die haben wir zum Glück schon lange nicht mehr.

Masochisten? :-) Sadisten? :-)

Und was die betrifft so empfehle ich ihnen Foppystreamer:-> [...]

...

Seit dem wir auf einen 10fach DLT-Wechsler umgestellt haben, herrscht Ruhe. Das sind Argumente, die für mich als Admin zählen (müssen!).

Du hast also mit Exabyte schlechte Erfahrungen gemacht. Und der Smart legt sich auf's Heck. D.H. Exabyte kann ohne weiteres mies konstruiert sein (und der Smart buggy sein) ohne dass alle Kopfschlinger-Laufwerke/Kleinwagen betroffen sein muessen.

Ha, freut mich, das Du jetzt einen hinkenden Vergleich gebracht hast;-) Wenn Du schon auf den Vergleich mit den Autos eingehst, dann mußt du einen anderen Wählen. Ich behaupte nicht, das alle Kleinwagen schlecht sind. Ich kann aber sagen, das alle Autos mit Heckmotor Fahrwerkstechnisch mehr oder weniger problematisch sind (Heckschleudern). Nicht mies konstruiert, einfach problematisch! Genau so ist es auch bei den Bandlaufwerken: Ich behaupte NICHT das Exabyte oder DAT schlecht konstruiert sind. Aber sie sind auf Grund ihrer Technik mehr oder weniger problematisch. Bei Exabyte habe ich eine Umschlingung von 270 Grad. Vom Anfang der Umschlingung bis zum Ende hat jeder Punkt des Bandes einen bestimmten Weg zurück zu legen. Dazu kommt noch der zusätzliche Weg durch die drehung des Kopfes. Da kommen pro Bandpunkt etliche cm zusammen! Beim dat habe ich das gleiche, nur ist der Gesamtweg pro Bandstelle etwas weniger, da nur 90 Grad Umschlingung. Bei einem linearen Vefahren muß jede Bandstelle nur ca. 2-3 mm vom Kopf berühren. Man kann also durchaus davon ausgehen, das durch die Verwendung von gleicher oder zumindest sehr ähnlicher Technik auch ähnliche Probleme auftreten.

Das heisst nur, dass (s.o.) die Exabyte-Laufwerke einen Konstruktionsfehler hatten (was nichts ueber die Bandabnutzung sagt!) und dass dein eines DLT-Laufwerk kein Montagsgeraet ist.

Nein, heist es nicht. Es bedeutet, das diese Bandlaufwerke durch hohen Abrieb stark verschmutzen und dadurch erstmal unbrauchbar werden. Wir hatten nicht nur den Wechsler sondern auch ein paar Einzellaufwerke. Alle hatten diese Effekte mehr oder weniger stark.

[Exabyte als Schraegspuraufzeichner]

...

Es handelt sich um mechnisch sehr ähnliche Verfahren. Und genau diese Ähnlichkeit ist es, die diese Probleme hervorruft. Es mag sein, das sie bei DAT etwas geringer sind (nur 90 Grad Umschlingung), aber weg sind sie nicht.

Dazu musst du beweisen, dass das Exabyte-Problem definitiv ein Problem mit der *Idee* Kopfumschlingung ist, und nicht nur ein Implementationsproblem. NT ist nicht der Beweis,

Warum muß ich etwas tun, was andere Techniker schon getan haben? Bitte vergiss nicht, das ich mich nicht hier hinstelle und eigene Theorien als bewiesen preise;-) Nein, das sind Sachen, die man liest oder erfragt (bzw. lesen oder erfragen mußte:-( ). Wundert mich eh ein wenig das Du versuchst, dieses Problem bzw. die Beweisführung dazu an mir fest zu machen. Das sieht immer ein wenig danach aus, als wollte man sich gegenseitig blos stellen. Und das wollen wir ja nicht, nicht wahr? Wir wollen den Leuten Tips und Erfahrungen und Wissen weiter geben:-)

dass alle OS 'Blue Screens' haben, NT ist der Beweis, dass man mindestens ein OS bauen kann, wo das passiert.

Das hast Du recht. Aber auch dieser Vergleich passt nicht richtig, da die meisten unterschiedlichen Betriebssysteme auch unterschiedliche Techniken einsetzen. Bei unseren Laufwerken sprechen wir aber von sehr ähnlichen Techniken.

Es gibt Menschen, die DAT (==DDS) ohne Probleme benutzen, ohne irgendwelche Abnutzungen festzustellen:

From: Tim Jones CC: Ftape Mailinglist Date: Mon, 12 Oct 1998 09:40:11 -0700 Organization: Enhanced Software Technologies, Inc.

[... eating tapes ...] I've been using DAT since 1989 (Archive days). I have never seen the problem that you describe unless the drive was a Gigatech drive (no longer made) or simply bad. I use DDS-2 and DDS-3 drives under Linux, SCO, BSDI, Solaris, and HP/UX on a daily basis and don't recall the last time that I've replaced media (we use only FUJI or IMATION media). [...]

EST stellt u.a. BRU (kommerzielles Backup-Program fuer Linux) her.

Nun gut. Wie gesagt, mit DAT selbst habe ich nur privat Erfahrung, und da ist das Problem durch weniger Gebrauch nicht so deutlich. mfg Peter Küchler Registrierter Linux-User #127408 --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com

Vorbemerkung: Cc's sind unnoetig, ich lese diese Liste auch ... Erhard Schwenk schrieb in 2,6K (60 Zeilen):

Also grundsätzlich muß man 2 Dinge unterscheiden: den Verschleiß des Bandes durch mechanische Beanspruchung und Schäden durch Alterung.

Wer Magnetbänder unkopiert mehr als 5-6 Jahre liegen läßt riskiert in jedem Fall Leseprobleme --> entweder ist die Sicherheit von 5-7 Jahren ausreichend oder man muß alle 5 Jahre mal ne Kopie machen.

HP behauptet: HP-DDS( == DAT)-Baender halten ihre Daten mindestens 10 Jahre, HP-DLTs mindestens 20 Jahre, wenn sie vernuenftig gelagert werden. Wobei DDS 5-40°C und 20-80% Luftfeuchtigkeit moegen und DLTs 18-26°C und 40-60% Luftfeuchtigkeit wollen. (http://www.hp.com/tape/papers/mediatips.html) Nicht, dass ich dir unrecht gebe, bei wichtigen Daten sind mehrere Kopien, die auch offsite gelagert werden, wichtig, und geg. muessen die Kopien halt umkopiert werden.

routinemäßig ständig Restores?, ok, alle 1-2 Monate sollte man mal nen Test machen, aber sonst wohl eher nicht)

Hmmm, was meinst du mit "Test"? Ob die Restore-Prozedur funktioniert? Ob Daten sich geaendert haben?

würde ich nach 30-50 Durchläufen ein DAT-Band austauschen. Bei Systemen ohne Schrägspuraufzeichnung ist zumindest der Abrieb in der Regel etwas geringer.

Da zumindestens HP-Laufwerke (angeblich) die Anzahl der Soft-Errors melden, sollte es ein leichtes sein, bei einem raschen Anstieg oder beim Ueberschreiten einer Schwelle das Band als 'bald am Ende' zu flaggen. Von daher muss man sich nicht auf fest eingestellte Zahlen verlassen.

können. Trotzdem muß man auf jeden Fall auch beide Laufwerke regelmäßig reinigen - also alle 1-2 Wochen mal ein Reinigungsband durchlaufen lassen.

Ich wuerde das eher nach Betriebsstunden zaehlen. Der eine arbeitet 1 Stunde in der Woche mit dem Laufwerk, der andere 18 Stunden am Tag.

...

Und DAT ist immer noch wesendlich besser als floppy tape.

Das auf jeden Fall - allerdings hauptsächlich wegen der mechanisch robuster konstruierten DAT-Laufwerke. Das physikalische Aufzeichnungsverfahren selbst ist beim Floppy-Tape sogar eher robuster,

Soso. Ein Band, welches *vor-formatiert* werden muss und bei der kleinsten Straffungsschwankung seinen naechsten Sektor nicht mehr findet ... ist robuster. Von 'wir gehen ueber den Floppy-Controller' mal ganz abgesehen. Von 'wir machen 80 ips und spulen daher recht schnell und brauchen deshalb 50(!) Spuren auf einem Tape' mal ganz abgesehen[1]. Und 'wir haben 2* einen Header am Anfang, da steht drin, wo was auf dem Band ist, wenn der weg ist, gute Nacht'. Ist zwar ganz nett als Inhaltsverzeichnis am Anfang ... aber ...

mehrere DAT-Laufwerke. Man kann auch durch die Sicherungsorganisation (z.B. nicht jedesmal eine VOllsicherung machen) die Kapazität erhöhen - allerdings auf Kosten einer längeren Restore-Phase-

Da Restores nicht der Normalfall sind, kann man ruhig fuer den Normalfall optimieren --- zumindestens was Zeitverbrauch angeht --- solange die Tradeoffs nicht groesser sind als der Gewinn. (i.e. ich muss innerhalb von 2 Stunden das System wieder am Laufen haben koennen ... :-) -Wolfgang [1] i.e. wo ein DAT oder DLT 4 Kopfpassagen hat, (schreiben, lesen, 2 rewinds) hat ein Floppy-Tape bis zu 104 (1 retension am Anfang, 50 schreiben, 50 lesen, geg. 1-3 rewinds). Und das ist, ohne den Header am Anfang mitzuzaehlen, da wird auch noch 3 mal (+ 3 rewinds) druebergegangen ... jedes Mal. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com

Erhard Schwenk schrieb:

On 11-Feb-00 Peter Kuechler wrote:

...

Ich muß also einen Rechner aufbauen mit mindestens 280GB Kapazität. Das dann alles mit IDE Platten...ich weiß nicht so recht.

Nee, so ja wohl nicht.

Dachte ich mir eigentlich auch.

Für Massenspeicher dieser Größe sollte man nen RAID-Controller und ein externes SCSI-Array nehmen, sonst hat man nur Ärger. IDE hat da nix zu suchen. Dieses Array kostet dann aber alleine ein paar 1000

Sehe ich auch so...

DM, und auch der Controller (z.B. ICP Vortex) will bezahlt sein.

Diese Teile setzen wir bei Fileservern ausschließlich ein.

Billige Plattengehäuse haben da außerdem oft Temperaturprobleme, weil die Lüftung nicht ausreicht oder in die falsche Richtung bläst.

So ein Backup-Server bringts nur dann, wenn man auch dort wieder ne Möglichkeit hat, auf Band zu sichern. Sonst ist das viel zu unsicher. Der Vorteil des Verfahrens ist ein schneller Restore, wenn man nur die neueste Generation braucht.

Nun, auch ich bin ein verfechter des Bandlaufwerks für Datensicherung:-) Was das Tempo eines Restors angeht, so kann ich nicht klagen. Wir beutzen einen 10fach DLT Wechsler und als Backupsoftware ARKEIA. Damit sind Daten wirklich sehr schnell wieder verfügbar. Was das Tempo angeht, so machen wir jeden Tag inkrementelle Sicherungen, die Dauern etwa 2 Stunden. Am Wochenende läuft dann von Samstag auf Sonntag eine Vollsicherung, die dauert dann allerdings etwa 12 Stunden.

Außerdem sollte man auch mal an die Netzbandbreite denken: 100 MBit-Ethernet überträgt im Idealfall ca. 10 MByte/Sekunde, Für 100 GB Speicherplatz braucht man dann 10000 Sekunden, das sind nicht ganz 3h Zeit. Wohlgemerkt, im Idealfall. Mit 10BaseT oder sowas braucht man bei solchen Datenmengen gar nicht erst anfangen.

Das haut lange nicht hin, wir sichern im Moment etwa 80GB in 12 Stunden von verschiedenen Rechnern. mfg Peter Küchler Registrierter Linux-User #127408 --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com

On 13-Feb-2000 Erhard Schwenk wrote: [etwas gekürzt, wir schonen die Liste:-)]

Für eine Bandsicherung, ja. Wenn aber noch eine Generation auf den Platten des Backup-Servers zur Verfügung steht, geht das halt noch um einiges schneller und hat auch noch andere Vorteile:

Jaja, aber das Problem hat viele Seiten...

- der Admin des Servers mit dem Datenverlust muß keinen Zugriff auf die Bänder haben, ein Fileserver-Zugriff auf das Share seines Servers reicht.

Stimmt, ist für uns aber unwichtig.

- Die Restore-Geschwindigkeit ist ein vielfaches höher als vom Band, besonders bei einem Teilrestore. Wenn z.B. einer versehentlich ne einzelne Datei gelöscht hat, ist die in Sekunden wiederherzustellen. Damit kann kein Bandlaufwerk mithalten.

Auch das ist richtig, aber auch hier gibt es zwei Seiten. Die andere istide, das auf diese Art und Weise die Leute zu immer lachserem Umgang mit den Daten verleitet werden. Es werden u.U. künstliche bedürfnisse geweckt, die man dann teuer bezahlen muß und vor allem auch nur schwer wieder los wird.

...

Was das Tempo angeht, so machen wir jeden Tag inkrementelle Sicherungen, die Dauern etwa 2 Stunden.

Das zögert dann aber den Restore gewaltig raus, denn man muß mehrere Bänder einlesen.

Warum das? Unsere inkrementellen Sicherungen brauchen im Schnitt 10% von einem Band. Und selbst wenn es mehrere Bänder wären, wie gesagt, es ist ein 10fach Wechsler;-)

...

Am Wochenende läuft dann von Samstag auf Sonntag eine Vollsicherung, die dauert dann allerdings etwa 12 Stunden.

Aber nicht übers Netz, sondern von Platte auf Band, nehme ich an?

Doch. Die Backupmaschine macht nix anderes wie femde Rechner zu sichern. [...]

Die Rechnung geht davon aus, daß zunächst schnelle Platten eines Sicherungssystems geschrieben wird, das dann in aller Ruhe auf Band wegsichert. Natürlich dauert das Wegschreiben auf Band länger (hängt aber vom Band ab, DAT und DLT können inzwischen ganz schön flott sein.

Das bedeutet aber, das ich den Nutzdatenbereich doppelt vorhalten muß. Nicht ganz billig und auch ein gewisser Aufwand.

Ich hab hier sowas im Einsatz: Ein älterer Rechner mit ca. 40 GB Plattenplatz, auf den via Netz alle Rechner nachts ihre Daten schieben. Morgens um 10 Uhr (wenn das Netz anderweitig gebraucht wird und die Schiebereien ohnehin nicht sinnvoll sind) beginnt der dann mit der Wegsicherung dieser Bestände auf ein DDS4-Band, was für unsere Zwecke noch absolut ausreicht. Wenn's mal crasht, muß nur sehr, sehr selten überhaupt auf ein Band zurückgegriffen werden.

Klar, das ist im Restorefall natürlich wesentlich schneller. Aber der Aufwand ist wie gesagt nicht unerheblich und bei uns auch nicht nötig (wir sind keine Bank;-) ) Abgesehen von den anderen Nebeneffekten, s.o. So lange wie ich genug Zeit am Wochenende habe um eine Vollsicherung zu fahren, werde ich es mal so lassen. Und was die Zeit betrifft, so habe ich noch genug Luft:-) -- mfg Peter Küchler Registrierter Linux-User #127408 --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com