I'm a member of
Quicksearch
Codenews Search
Disclaimer
The individual owning this blog works at Sun Microsystems GmbH in Germany, a subsidiary of Oracle. The opinions expressed here are his own, are not necessarily reviewed in advance by anyone but the individual author, and neither Oracle nor any other party necessarily agrees with them.
Navigation
Categories
About this blog- Apple
- iPhone
- Aviation
- Bahn
- Begriffe des Lebens
- Blogosphere
- Braindump
- Business Travel
- CANBOX
- CeBIT
- CEC
- Computing
- del.icio.us
- Fundsache
- General
- HHOSUG
- i hate sundays
- Kochen
- Mindfuck
- Movies
- Music
- On Benchmarketing
- Persoenliches Pech
- Photographie
- policy of ...
- Privacy
- Recommended Blogs
- Security
- Solaris
- Strange Days
- Sun/Oracle
- suncec2007
- suncec2008
- Technology
- The IT Business
- Toolbox
- Travel
- Work
Backups irrelevant?
Monday, April 7. 2008
It´s nice that he references to ZFS in his article, but i think his opinion stated in #"PostgreSQL to Scale to 1 Biilllliooonnnn Users, Dr Evil would be proud" is dangerous:
Backup is irrelevant for those of you who care about this discussion. LVM/ZFS snapshots are the rule of the land.Well, when the first disaster hits your datacenter (and such disaster begin with a failed disk too much) , you will recognize that you are toast without tapes or at least with a disk-based backup on a different storage as a last line of defence. Neverever rely on a single pool of disk blocks on a single machine for disaster recovery, even when it gives you features like snapshot to freeze the disk state at one or multiple points in time.
Posted by Joerg Moellenkamp
in English, The IT Business
at
10:49
| Comments (12)
| Trackbacks (0)
View as PDF: This entry | This month | Full blog
Defined tags for this entry: storage
View as PDF: This entry | This month | Full blog
Trackbacks
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.
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.
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..
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.
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...
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...
Links in this article
The LKSF book
The book with the consolidated Less known Solaris Tutorials is available for download here
Twitterfeeds
twitter.com/c0t0d0s0
just blogged: Informationweek about the speculations surrounding Sun/Oracle merger: There is a paragraph in Infowe... http://bit.ly/c9JXKm
twitter.com/codenews
6869236 pkgmk is broken after putback for large file support in 6514450 http://bit.ly/dm0MAG
twitter.com/SunPatches
Security patch: 120228-40 - Messaging Server 6.3-11.01: core patch. Available for SPARC since Mar/17/10. http://bit.ly/bk1hw3
twitter.com/SolPatchesX86
122301-49 - SunOS 5.9_x86: Kernel Patch. Available since Mar/17/10. http://bit.ly/9ETInV
twitter.com/SolPatchesSPARC
122300-49 - SunOS 5.9: Kernel Patch. Available since Mar/17/10. http://bit.ly/b9ZvRJ
just blogged: Informationweek about the speculations surrounding Sun/Oracle merger: There is a paragraph in Infowe... http://bit.ly/c9JXKm
twitter.com/codenews
6869236 pkgmk is broken after putback for large file support in 6514450 http://bit.ly/dm0MAG
twitter.com/SunPatches
Security patch: 120228-40 - Messaging Server 6.3-11.01: core patch. Available for SPARC since Mar/17/10. http://bit.ly/bk1hw3
twitter.com/SolPatchesX86
122301-49 - SunOS 5.9_x86: Kernel Patch. Available since Mar/17/10. http://bit.ly/9ETInV
twitter.com/SolPatchesSPARC
122300-49 - SunOS 5.9: Kernel Patch. Available since Mar/17/10. http://bit.ly/b9ZvRJ
Web 2.0
Contact
Networking
open.bc
LinkedIn
Facebook
My photos
- mail: joerg@c0t0d0s0.org
- icq: 144000169
- Me, myself and I
- openBC
- My del.icio.us
- c0t0d0s0@twitter
- c0t0d0s0@last.fm
- wiki@c0t0d0s0
- Amazon Wishlist
Networking
open.bc
My photos
Syndication
Tagged articles
AMD 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
Comments
about Ich bin angewidert ....
Fri, 19.03.2010 09:52
@NoTarget:
Heinsohn ist ein
kluger Mann (siehe hier: http
://bit.ly/drhRLA). Das heisst
aber nicht, dass er *nur [...]
about Ich bin angewidert ....
Fri, 19.03.2010 07:38
1. Zum einen habe ich einen Ge
genvorschlag formuliert (bitte
Text zu Ende lesen). Es ersch
eint mir sinnvoller, Gel [...]
about Landungsbrücken
Fri, 19.03.2010 07:14
Benutz ich immer noch. Ich ha
b dies und ein anderes Bild nu
r mit einer Neuinstallation vo
n Aperture bearbeitet un [...]
about Ich bin angewidert ....
Thu, 18.03.2010 23:37
"Vorab ein paar unangenehme Wa
hrheiten zur demographischen E
ntwicklung: Von 100 Kindern, d
ie Deutschland benötigt, [...]
about Landungsbrücken
Thu, 18.03.2010 22:48
Hi Du,
wieso bist Du wieder
bei flickr. Was ist mit Smugm
ug?
Viele Grüße
Buttons
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Germany License
