Werner schrieb am 29. April 2012 22:16
> cd schrieb am 29. April 2012 21:28
>
> > Werner schrieb am 28. April 2012 23:20
> >
> > > Eine defekte CPU, die dem RAID Controller Schrott liefert und die
> > > ganze Oracle DB ist erledigt. Gut wir konnten die DB nach 12 Stunden
> > > auf den Stand etwa 5 Minuten VOR dem CPU Fehler recovern, aber die 5
> > > Minuten waren weg, und da war die CPU noch nett und ist 5 Minuten
> > > nach dem ersten Fehler abgeraucht,
>
> > > ein RAID Controller hat es
> > > geschafft die ganze DB zu korrumpieren, Datenverlust war nur ein
> > > halbes Jahr, als er dann endgültig den Geist aufgab, stellte sich
> > > heraus, dass die Backups nur von ihm lesbar waren.
> >
> > Wie kann so etwas passieren? Sollten Backups nicht immer mal wieder
> > auf einem Reserve-System getestet werden, um solche
> > Fehlerkonstellationen zu verhindern
> > cd
> Fall 1) Hast Du gar keine Chance, hat nebenbei auch die Standby
> Database gleich mit gerissen
Defekte CPU ist natürlich ein richtig schönes HW-Problem, keine
Frage.
> Fall 2) Nützt Dir ein jährlicher Recoverytest auch nichts, und
> wirklich jeden Monat prüft niemand die erfolgreichen Backups und laut
> allen Protokollen waren die Backups nun einmal erfolgreich
Zwischen Jährlich und monatlich fallen mir noch ein paar andere
Zeitintervalle ein. Wenn beim Backup-Check die Prüfsummen stimmen
weil die CPU falsch rechnet, fehlt natürlich dieses Warnsignal.
> Alles andere ist einfach nicht umsetzbar, daher setzt man ja auf
> Produkte, deren Hersteller behaupten, dass nichts passieren kann
Nicht böse sein, aber wenn das hier so eine ausserirdische
Kombination darstellt, wo trotz defekter CPU alle Systeme auf
Grün zeigen und keinerlei Tests gefahren werden, kann man schwer den
SW-Hersteller in die Pflicht nehmen - man sollte sich trotz diverser
Marketing-Aussagen noch einen Rest an Realismus bewahren, was Technik
kann und was nicht.
Nachtrag: wenn ich deine Ergänzungen richtig verstanden habe, ging es
um ein System, wo auch schon ein Verlust der letzten 5. Min. weh tut
- das man solche kritischen Systeme nicht durch entsprechende
restore/recovery-Szenarien absichert verstehe ich dann noch weniger.
cd
> cd schrieb am 29. April 2012 21:28
>
> > Werner schrieb am 28. April 2012 23:20
> >
> > > Eine defekte CPU, die dem RAID Controller Schrott liefert und die
> > > ganze Oracle DB ist erledigt. Gut wir konnten die DB nach 12 Stunden
> > > auf den Stand etwa 5 Minuten VOR dem CPU Fehler recovern, aber die 5
> > > Minuten waren weg, und da war die CPU noch nett und ist 5 Minuten
> > > nach dem ersten Fehler abgeraucht,
>
> > > ein RAID Controller hat es
> > > geschafft die ganze DB zu korrumpieren, Datenverlust war nur ein
> > > halbes Jahr, als er dann endgültig den Geist aufgab, stellte sich
> > > heraus, dass die Backups nur von ihm lesbar waren.
> >
> > Wie kann so etwas passieren? Sollten Backups nicht immer mal wieder
> > auf einem Reserve-System getestet werden, um solche
> > Fehlerkonstellationen zu verhindern
> > cd
> Fall 1) Hast Du gar keine Chance, hat nebenbei auch die Standby
> Database gleich mit gerissen
Defekte CPU ist natürlich ein richtig schönes HW-Problem, keine
Frage.
> Fall 2) Nützt Dir ein jährlicher Recoverytest auch nichts, und
> wirklich jeden Monat prüft niemand die erfolgreichen Backups und laut
> allen Protokollen waren die Backups nun einmal erfolgreich
Zwischen Jährlich und monatlich fallen mir noch ein paar andere
Zeitintervalle ein. Wenn beim Backup-Check die Prüfsummen stimmen
weil die CPU falsch rechnet, fehlt natürlich dieses Warnsignal.
> Alles andere ist einfach nicht umsetzbar, daher setzt man ja auf
> Produkte, deren Hersteller behaupten, dass nichts passieren kann
Nicht böse sein, aber wenn das hier so eine ausserirdische
Kombination darstellt, wo trotz defekter CPU alle Systeme auf
Grün zeigen und keinerlei Tests gefahren werden, kann man schwer den
SW-Hersteller in die Pflicht nehmen - man sollte sich trotz diverser
Marketing-Aussagen noch einen Rest an Realismus bewahren, was Technik
kann und was nicht.
Nachtrag: wenn ich deine Ergänzungen richtig verstanden habe, ging es
um ein System, wo auch schon ein Verlust der letzten 5. Min. weh tut
- das man solche kritischen Systeme nicht durch entsprechende
restore/recovery-Szenarien absichert verstehe ich dann noch weniger.
cd