Phillip Richdale, Donnerstag, 26. Dezember 2002 12:53:
Und ich hab' mich damit zumindest bis jetzt um einen fetten 10-Stufen Plan für Backupverfahren herumgedrückt, was ja auch eine Erleichterung ist.
Mit derartigen Plänen hab ich überhaupt noch keine gute Erfahrung gemacht. Ich administriere auch im Produktivbereich einige Linux- und Macintosh-Hobel, sogar eine NT4 ist mit in der Serverfarm, und ich habe wo ich konnte diese komischen Empfehlungen wie "dreißig Bänder kaufen, für jeden Tag eines, zwölf weitere für jeden Monat, Mitarbeiter einstellen zum Bänderwechsel" beiseite geschoben. Stattdessen sorge ich cronjob-mäßig dafür, daß die Daten mindestens dupliziert werden. Mindestens heißt, daß für jedes Nutzbyte auf jeden Fall ein Backup-Byte existiert, und zwar auch jeweils auf einer HDD. Bänder nutze ich überhaupt nicht. Ferner - zur physikalischen Verbreiterung der Sicherheit wg. Feuer, Einbruch usw. - bekommt immer mal wieder einer der Mitarbeiter die zentrale Datenbank aufs Notebook, das die meisten immer brav mit nach Hause nehmen. Diese Strategien gehen natürlich nicht überhall auf, aber bei uns machen sie Sinn. Das entscheidende Kriterium einer Backup-Strategie ist mE, daß das Backup auch tatsächlich gemacht wird. Das wiederum bedeutet, daß es keinen händischen Eingriff erfordern darf, sondern automatisch verlaufen muß. Das Medium ist weniger entscheidend, aber der Einsatz von Bändern zieht halt doch meist wieder manuelle Eingriffe nach sich. Das wird dann vergessen, die nervenden Fehlermeldungen abgeschaltet, und schon wars das mit dem schönen 30+12-Bänder-Plan. Ich empfehle übrigens rsync statt tar oder sowas. Geht tierisch schnell. Und tar hat mE den Nachteil, daß alles in einer einzigen Datei drinsteckt. Wenn die nen Schuß kriegt, ist alles vorbei. Da ist Deine Methode im Vorteil, einfach dateiweise zu kopieren. -- Andreas Feile www.feile.net