QuicksearchEvents13.10 - 15.10 - Horizons EMEA
![]() Trusted AdBlower Door Test
Luftdichtigkeitsmessung für Gebäude Raum Hamburg ab 160 € excl. MwSt www.m-tectum.de Kategorien
|
Backups irrelevant?Monday, April 7. 2008Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
Backups nur auf Disk zu machen verbiete sich doch schon angesichts der aktuellen "Green-IT" Diskussion. Zudem muss ich deutlich mehr Geld investieren um eine vergleichbare Kapazität mit Disks hinzubekommen. Gerade im Enterprise-Umfeld wird es noch sehr, sehr, sehr lange Tapes geben.
Erzaehlst Du das bitte mal den Kunden, die durch bestimmte Hersteller getrieben B2D fuer eine furchtbar tolle Idee halten?
Vielleicht reichte es ja auch aus, den B2D-Herstellern zu erzählen, dass man Festplatten bei Nichtbenutzung auch abschalten kann?
Hmm, ist trotzdem aus meiner Sicht ein ziemlicher Hack: Elektronik laeuft trotzdem weiter, hoher Einschaltstrom beim Anlaufen der Platten und meines Wissens sind Festplatten fuer Server auch nur fuer eine bestimmte Anzahl Einschaltzyklen spezifiziert.
Korrekt, wobei es langsam drehende Platten gibt, die für eine hohe Anzahl von Anlauf/Stopp-Prozesssen gebaut sind (so in Richtung Notebookplatten). Die schalten auch einige leistungshunrige Komponenten der Elektronik ab. Das Problem liegt m.E. eher dann in den MTBFs und den Fehlerquoten der Platten. Da muss man dann gleich Raids und Prüfsummen auffahren, damit das interessant wird. Die Stromspitzen beim Hochfahren bekommt man vielleicht durch verstetzes Hochfahren in den Griff - trotzdem bleibt es ein merkwürdiges Rumgemache.
Wichtig wäre vielleich die Robustheit der Bänder vs. die Nichtrobustheit der Festplatten, wenn man sie - aus welchen Gründen auch immer - aus der Backupmaschine herausnimmt (hier kommt der Maschinenbauer durch). Bänder überstehen einen Fall aus 2m Höhe. Festplatten würden mir da Sorgen machen - insbesondere wenn die Lager schon ein paar Jahre auf dem Buckel haben.
Relying solely on disk backup is stupid. This begins with disk systems being buggy, too. Having good old tape backups with tar files handy was a godsend when recently our backup 3510 got magically inconsistent after a harddisk failed. Should never happen, but so it goes.
Jetzt habe ich auch mal den referenzierten Artikel gelesen:
Das Zitat hier ist schon sehr sehr verkürzend. Es geht nicht darum, dass Backup an sich irrelevant sei. Der Autor behauptet vielmehr, dass Online-Backup-Features in Datenbank-Serversofttware irrelevant seien, weil man sie durch Snapshots auf dem Storage Layer ersetzen könne. Ich persönlich habe trotzdem gerne Online-Backup in der Datenbank, aber auf jeden Fall ist die Aussage eine komplett andere.
Ja, Du hast da recht. Ich hatte das zunaechst anders gelesen. Ich nehme die kritik in diesem punkt an jenem artikel zurueck. Problem ist : es gibt kunden die wirklich so denken .....
Die Behauptung, daß Online-Backup durch Snapshots im Storage-Layer überflüssig wird, stimmt so in der Form auch nicht.
Wenn z.B. ZFS eines Tages die Transaktions-API exportiert und die relevanten Datenbanksysteme dieses für ihre Schreiboperationen nutzen, dann kann man davon sprechen - vorher nicht. Im Fall von DB2 beispielsweise wird regelmäßig ein so erstelltes "Backup" auf eine Komplettprüfung der Datenbank laufen, die schon bei wenigen Hundert GB etliche Stunden dauern kann. Ohne wirklich präzise das physische Transaktionsverhalten der Datenbank und der Snapshot-Funktion des Storage-Layers verstanden zu haben, sollte man nicht von Online-Backup weggehen. Im Grunde ist der ganze Artikel ziemlich oberflächlich. Warum sollte die Verfügbarkeit von ZFS für MacOS X darüber entscheiden, daß "makes Apple start to look like a viable platform for servers"? Aha, und vor ZFS waren alle Betriebssystem incl. Solaris nicht "viable platforms", oder wie? Das sollte man alles nicht so ernst nehmen..
Eine der vornehmsten Aufgaben eines Datenbanksystems ist es, den Datenbestand auf Platte unter allen Umständen konsistent zu halten.
U.a. auch bei einem Stromausfall, und ein Snapshot auf dem Storage-Layer hat genau den selben Effekt: in einem Moment hören schlagartig alle Schreiboperationen auf dem Snapshot auf. Der Storage-Layer muss nur sicherstellen, dass das für alle Volumes der Datenbank exakt zum selben Zeitpunkt passiert. (damit haben manche Storage Manager schon ein Problem.) Richtig ist, dass bei einem solcherart angefertigten Backup genau wie bei einem Systemausfall unter Umständen der Wiederanlauf deutlich länger dauert, weil das Datenbanksystem eine Menge Aktionen aus dem Log wieder einspielen oder ungeschehen muss. Ein Datenbanksystem aber, die sich zusätzlich zum Log-Replay beim Wiederanlauf nach einem Systemausfall erstmal stundenlang mit Prüfungen beschäftigt, würde ich allerdings nicht so gut finden. Ganz egal, wie ich Backup mache. Ein Nachteil an der Snapshot-Methode ist allerdings, dass ich die Datafiles des Datenbanksystems sichern muss, die unter Umständen erheblich größer sein können als ein Dumpformat.
"Der Storage-Layer muss nur sicherstellen, dass das für alle Volumes der Datenbank exakt zum selben Zeitpunkt passiert"
Das "nur" ist aber schon eine sportliche Herausforderung, zudem sind in der Praxis leider auch die renommiertesten Datenbanksysteme in dieser Hinsicht nicht so fehlerfrei wie man sich das wünschen würde. "Restore from backup" habe ich schon mehr als einmal herstellerseitig in Bezug auf logische Fehler in Volumes gehört nach Hardwarefehlern, Stromausfall (typisch: Murks bei Installationsarbeiten im Serverraum) oder auch nur "erst das Storagesystem, dann den Server runtergefahren". Meine besten Wünsche demjenigen, der versucht, alleine mit Snapshots auf Storageebene auszukommen. Was da alles perfekt funktionieren muß, damit das garantiert gutgeht... |
The LKSF bookThe book with the consolidated Less known Solaris Tutorials is available for download here
Web 2.0Contact
Networking open.bc My photos SyndicationComments about Hoerempfehlung: Peter Heppner - solo Tue, 07.10.2008 13:35 Heute morgen auf dem Weg zur A rbeit lief im Radio das Lied A lleinesein. Die Stimme klingt nach Wolfsheim aber der [...] about ZFS in der c´t Tue, 07.10.2008 13:03 Jo ... das ist enterprise-grad e ... es soll verhindern, das die Daten auf keinen Fall und unter keinen Umstaenden [...] about ZFS in der c´t Tue, 07.10.2008 11:49 ob die Datenhalde eines typisc hen ct-Lesers schneller werden wuerde, wenn man sZIL und L2A RC auf nen USB-Stick leg [...] about ZFS in der c´t Tue, 07.10.2008 11:48 da steht auch das ZFS nicht si nnhaft erkennt wenn man zwei P latten aus dem Raid-Verbund zi eht (hang forever+reboot [...] Getaggte ArtikelAMD Apple avs Bahn Blogging Blogosphere braindump Business Travel CeBIT cec cec2006 CMT del.icio.us deutsch dtrace fliegen Fundsache General Hamburg IBM i hate sundays Intel iscsi jumpstart Links Linux lksf Mindfuck Movies Music Musik Niagara Opensolaris Opteron Photographie policy of ... Politik Security Solaris storage Sun suncec2007 sunw t1 The IT Business Ultrasparc ultrasparc t1 Wirtschaft Work ZFS
Blog Administration |