Backup-Strategie -- Hardeware + Software

[Alexander Foken]

[Teil 2 von 2]

Ausrangierter Rechner mit großer Platte und Linux, mit WakeUp on LAN Netzwerkkarte, dann schreibe ich irgendein bash-script, welches über das Netzwerk diesen Rechner startet,

(ftp://ftp.scyld.com/pub/diag/ether-wake.c / ftp://ftp.scyld.com/pub/diag/etherwake.8 vom Linux-NIC-Guru Donald Becker)

und dann am besten per FTP ein tar-Archiv des File-systems hochläd. Oder ein Image.

Soweit ok.

Problem ist aber - was machen wenn der Server jetzt die neuen Daten braucht?
Wie wärs so:
ich besorge _2_ Wechelrahmen, einen für den Server und einen für den Backup-Rechner, dazu 3 80 GB Platten(was auf alle Fälle erheblich billiger ist als 2 Firewire-Platten).

Du bräuchtest nur eine -- mit Wechselrahmen.

Dann läuft auf dem Server ein softraid 1, mit 1 Platte fest installiert, und einer im Wechelrahmen,

Du solltest beide Server-Platten im Wechselrahmen haben. Frei nach Murphy stirbt sonst die fest eingebaute Platte zuerst.

die dritte Platte kommt in den backup-Rechner, und wird wie oben bechrieben täglich neu per Script beschreiben.
Wobei, dann kann ich das Backup ja gar nicht ohne weiteres autauschen. Hm, schon schwierig das ganze. Es kann doch nicht sein das Firewire das einzig sehlig machende ist.

Nein, aber es hilft sehr.

Außerdem hat der Servcer iMHO gar keine solche Schnittstelle!

Dem könnte man ja mit einer Firewire-Karte abhelfen.

So, jetzt schaffe ich mal den Backup-Rechner wieder ab, ignoriere mein "laß die Finger vom Image", und verordne Dir eine Firewire-Karte und ein Firewire-Gehäuse mit Wechselrahmen, in dem abwechselnd zwei IDE-Platten laufen. Insgesamt brauchst Du vier möglichst identische Platten (und vielleicht ein oder zwei in Reserve).

Und dann kommt die große RAID-1-Mißbrauch-Imaging-Aktion:

Das RAID-1 (Mirroring, nur zur Erinnerung) in Deinem Server konfiguiertst Du erstmal so, daß Linux direkt vom RAID bootet (RAID autodetect, Partitionstyp auf FE und der Rest geht fast von selbst) und alle Daten auf dem RAID liegen, Swap nutzt leeren Platz auf beiden Platten getrennt.
Jede Platte sollte ein IDE-Kabel für sich haben, notfalls mit dem CDROM als Secondary Slave.

Dann kommt eine IDE-Platte in den Firewire-Rahmen und an den Server. Diese Platte wird jetzt als dritte Platte ins RAID-1 gehängt, sprich: Du speicherst jedes Byte auf drei Platten. Dann wartest Du, bis das SW-Raid alles rüberkopiert hat (/proc/mdstat lesen). Dann meldest Du die Firewire-Platte aus dem RAID ab, nochmal ein sync zur Sicherheit, und ziehst den Firewire-Rahmen samt Platte ab. Jetzt hast Du eine Backup-Platte, von der Dein Server wahrscheinlich sogar booten würde: Sie steckt im Firewire-Rahmen.

IDE-Platte aus dem Firewire-Rahmen raus, nächste rein, nächstes Backup.

Server-Ausfall:

Beide(!) RAID-Platten rausnehmen, Backup-Platte rein. Booten und die zweite Platte als defekt konfigurieren. Runterfahren. Neue Platte im Rahmen reinstecken, RAID wiederaufbauen lassen. Neues Backup anfertigen. Wenn Du dabei Fehler machst, hast Du nur noch einen Versuch mit dem alten Backup. Deswegen solltest Du das vielleicht einmal durchspielen und jeden Schritt exakt dokumentieren, den Du machen mußt.

Wie wären zwei gemirrorte RAID5-Systeme mit je ein oder zwei Hot Spare Platten ? Dann hast Du eine recht gute Ausfallsicherheit. Gut, kostet etwas. Wie viele Neuner nach dem Komma sollen's denn sein ?
Was fürn Komma?

Das Komma in "99,999% Verfügbarkeit". Je mehr Neuner, desto teurer.

Preislich soll es möglichst niedrig liegen, daher brauche ich an solche Dinge gar nicht zu denken. Softraid1 wäre ein guter kompromiss.

So sehe ich das auch.

100MByte/s ist die Kapazität von ATA-100. Das schafft aber noch kein Schreib-Lese-Kopf.
Wieviel denn?

Das steht öfters mal in der c't, im Plattenvergleich. Soweit ich weiß, gibt es kaum eine IDE-Platte, die auch nur ATA-66 auslasten würde. Im Burst aus dem Cache heraus sind durchaus mal 100 MByte/sec drin, aber der Cache ist im Glücksfall 512 KByte groß. Wenn aber die Platte auf einen Schlag von 0 auf 80% voll bringst oder ein vollständiges Image machst, ist der Cache fast nutzlos. Dann zählt fast nur der Durchsatz am Kopf (und der ist für Schreiben und Lesen auch noch unterschiedlich).

Fast-Ethernet läge bei gut 10 M/sec.
Je nach Protokoll-Overhead, natürlich.
FTP ist doch kein Problem, oder?

Wenn Du's wirklich schnell haben willst, nimmst Du netcat über TCP-Sockets und pipest dein tar gleich ins netcat. (Da fällt mir gerade rmt ein, das macht prinipiell genau das, nur mit einem Minimum an Protokoll, um Fehler abfangen zu können. => man rmt) Aber das bringt gegenüber FTP wohl höchstens ein paar Prozent.

Problematisch an FTP ist, daß Du Dein backup.tar erst einmal auf der lokalen Maschine haben mußt. Wenn Du (wie auch immer: NFS/AFS/SaMBa) ein Verzeichnis von der Backup-Kiste mountest, kannst Du gleich auf die Backup-Maschine schreiben, mit ein klein wenig Protokoll-Overhead.

Alexander