[sage] Warum ich keine Bandlaufwerke mag

[Benedikt Stockebrand]

Moin Dieter und Liste,

Dieter Braun <dieter.braun.rgbg at gmx.de> writes:

> Was aber durchaus Bezug zu heute hat: Wieso konnte vor 15 - 20 Jahren
> eine Software Bandfehler frühzeitig erkennen (d. h. bevor's zu spät
> war), während es heute keine mir bekannte und für kleinere Betriebe
> erschwingliche Software mehr kann? Oder habe ich da was übersehen?
> (Vielleicht kenne ich bacula auch noch nicht gut genug?)

gute Frage!  Kann es sein, dass damalige Laufwerke ein Interface
hatten, mit dem man die Anzahl der erfolglos bzw. mehrfach
geschriebenen Blöcke auslesen konnte und man heute an diese
Informationen nicht mehr rankommt?

Wäre mal interessant herauszufinden.

> Tut mir leid Benedikt, aber bei dem Gedanken, die Firmenbackups durch
> einen Arbeitsplatzrechner durchführen zu lassen, stellen sich alle bei
> mir noch vorhandenen Haare in die Höhe. [...]

Das hast Du glaube ich falsch verstanden: Ich will ja das "reguläre
Backup" damit nicht ersetzen, sondern nur ergänzen.  

Mein Ziel beim Backup sieht etwa so aus:

1) Einzelne Dateien weg: Aus einem Snapshot (in meinem Fall ZFS)
   alte Version rauspulen; kein Eingriff auf Admin-Seite notwendig.
   Ein buntes Frontend dafür gibt es bisher leider aber nur bei
   OpenSolaris.

2) Platte kaputt: Dafür gibt's RAID; Admin muss Platte (beschaffen und)
   wechseln, Betrieb wird zeitweise langsamer, es gibt aber keine
   echte Betriebsunterbrechung.  Nebenbei: Hot Spares sind bei RAIDs
   kein Luxus.

3) Server kaputt mit Datenverlust: Backup-Platte aus Desktop
   rausnehmen, an Reserve-Server oder reparierten Server hängen --
   oder Desktop temporär als Reserve-Server missbrauchen.  Daten seit
   der letzten Synchronisation sind weg, Zeitaufwand und
   Betriebsunterbrechung hängen von den Details ab.

4) GAU -- alle Rechner über Nacht abgebrannt/blitzgegrillt: 
   Mit einem Schlepptopp wie bei 3 verfahren.

5) Super-GAU -- Schlepptopp tut's auch nicht: Neuen Server besorgen,
   reguläres Backup von Wechselmedien per Disaster Recovery
   einspielen.  Schon alleine die Neubeschaffung der Hardware kann
   Tage dauern, aber in der Situation hat man eh größere Probleme, und
   hoffentlich eine Hausrat- bzw. Geschäftsinhalteversicherung.  Oder
   einen entsprechenden Supportvertrag mit dem Hersteller, aber den
   haben typischerweise erst größere Firmenkunden.

Bei den Punkten 3 und 4 kann man also mit dem zusätzlichen(!) Backup
auf andere Rechner den Schaden ohne zusätzliche Hardware deutlich
gegenüber dem Vorgehen bei 5 reduzieren und außerdem Schlamperei bei
der Handhabung vermeiden, weil man nicht von Hand Medien
transportieren muss.  Ganz nebenbei, wenn die Offsite-Backups nur
einmal die Woche im Bankschließfach landen, dann verringert man in
diesen Fällen auch den Datenverlust ganz erheblich.

Und bevor Johannes jetzt enttäuscht ist: Ja, beim Punkt 5 kann ein
Backup über's Internet sehr hilfreich sein, wenn es denn im Einzelfall
praktikabel ist.  Erstens eliminiert es die Möglichkeit der
Schlamperei mit den Medien und zweitens ist es in manchen Fällen
aktueller als das letzte ausgelagerte Medium.

> Auch wenn das vielleicht konservativ klingt: Ein verlässliches
> Backup gehört auf einen Server.

Der Server ist mir dabei gar nicht so wichtig.  Wichtiger ist mir,
dass ich die Medien für die Fälle 4 und 5 abstöpseln kann -- ich bin
mal in einem früheren Leben mit reichlich Blitzeinschlägen gesegnet
worden, und alles was zum Zeitpunkt eines Volltreffers am Strom- oder
sonstigen Netz hängt, ist im Zweifelsfall anschließend gegrillt --
egal ob Desktop oder Server.

Meine aktuellen Überlegungen für meine neue Installation sehen
übrigens so aus, dass ich die Desktop-Platte und die Wechselmedien
(alte 3.5"-Platten in einem Sharkoon QuickPort) von meinem
Backup-Serverchen dem File Server als iSCSI-Target zur Verfügung
stelle und der File Server darauf seine ZFS-Snapshots synchronisiert.
Mal sehen, was dabei noch rauskommt...

> Bei denen, die es sich leisten können, auf separate Backup-Server;
> bei kleinen Betrieben, die es sich nicht leisten können und sowieso
> nur einen Fileserver haben, kann das auch der Fileserver selber
> sein. (Mir ist völlig klar, dass letzteres potentiell zu mehr
> Problemen führt als ersteres. Aber wenn keine andere Maschine da ist
> ...)

Ja, wobei Du eine wesentliche Annahme machst, die Du nicht explizit
erwähnst: Dass man mehrere Wechselmedien hat, die sich an dem Ding
abstöpseln, rotieren und wenn praktikabel räumlich trennen lassen.

Wenn's kein Blitzeinschlag während des Backups, kein agressiver
Virenbefall, kein DAU und kein interner Saboteur ist, dann macht man
sonst nach Murphy als Admin was falsch und alles ist auf einen Schlag
weg -- im Zweifelsfall, weil einem beim Schrauben eine strategisch
platzierte Tasse Kaffee wo reinläuft.  Oder noch schlimmer, ein
richtig fieser Hardware-Fehler (in meinem Fall Speicherfehler im
Disk-Controller), sorgt dafür, dass das System schleichend nur noch
Müll sichert.

Deshalb halte ich auch einiges von mehrtägigen oder -wöchentlichen
Vorhaltezeiten -- auch wenn das bei der Frage, wie viele Medien
man denn braucht, wieder zu Diskussionen führt.

> Ich habe vor einiger Zeit mal einen Bericht über die Sicherheit von
> Billigsafes gelesen, weiss allerdings nicht mehr wo. Demnach waren die
> Billigsafes mit Anschaffungskosten in der Höhe von ein paar Hundert
> Euro auch nicht viel sicherer als ein Schlüsselkasten.

Gegen das an dieser Stelle ursprünglich angesprochene "ich brauche
jetzt ganz schnell einen USB-Stick" reicht normalerweise schon der
Schlüsselkasten, oder auch nur eine konsequent abgeschlossene
Schreibtischschublade.  Die Billig-Safes haben demgegenüber vor allem
psychologische Vorteile, weil sie dem Backup optisch eine größere
Bedeutung geben -- was nicht verkehrt ist.  Außerdem halten sie
teilweise etwas länger bei einem Zimmerbrand durch.

Wenn man einen "richtigen" Safe braucht, dann hast Du völlig Recht,
dann wird es wirklich teuer und schwer.


Viele Grüße,

    Benedikt

-- 
			 Business Grade IPv6
		    Consulting, Training, Projects

Benedikt Stockebrand, Dipl.-Inform.   http://www.benedikt-stockebrand.de/