Oliver Schad schrieb am 29. April 2012 15:20
> Lars Rohwedder schrieb am 29. April 2012 11:58
>
> > die Frage ist, welche Datenbanktabellen man ins Backup packt.
>
> Die, die man braucht, um gemäß den Anforderungen wieder rechtzeitig
> online zu sein.
Das ist eben die Frage, was "rechtzeitig" ist.
Außerdem: Als entschieden wurde, dass bestimmte (Cache-)Datenbanken
nicht ins Backup müssen, weil sie ja aus den Rohdaten schnell genug
durch Nachprozessieren wieder neu aufgebaut werden können, war die
Datenmenge noch klein genug, dass die Daten für 1 Monat in wenigen
Stunden verarbeitet waren. Auf einer Maschine, die ansonsten idle
war. :-/
> [...] Aber das Konzept kann sicher nicht sein, ich
> schick mal meine Platte irgendwohin oder ich glaube Oracle wird schon
> meine Platte wieder richten können.
Wir schicken unsere Platten nirgendwohin. Dazu sind die Daten darauf
dann doch zu vertraulich.
> Will man nur Server-Ausfall bei HA abfangen, dafür hat man dann
> mehrere Instanzen, die sich immer live replizieren. Für ein falsches
> "DROP DB" hilft das natürlich nicht.
Beides brauchen wir.
> > Da darf dann bei der Recovery wirklich nichts schiefgehen, sonst
> > kommt man mit Nachprozessieren nicht mehr hinterher.
>
> Disaster-Recovery ist so oder so immer außerhalb der normalen
> Prozeduren, also auch mit Downtimes. Das ist zumindest mein
> Verständnis davon, das wäre dann der Super-GAU. GAU ist dagegen
> Normalbetrieb.
Naja, wenn 1 DB-Server ausgefallen ist und seine Daten ausm Backup
wiederhergestellt werden müssen, sollte das den Betrieb der übrigen
DB-Server möglichst wenig stören.
> > Oder, um es mit DevOp-Borat zu sagen: If you don't have a disaster
> > recovery for your disaster recovery, you're doing it wrong.
>
> Na ja, also wer Backup und Recovery einfach beherrscht, der ist ja
> schon viel weiter als 90% der Unternehmen.
Wie einfach das Recovery ist, weiß ich nicht. Aber es wurde schon
mehrmals durchgeführt. Testweise und auch im Ernstfall. Es scheint
also zumindest zu funktionieren. :-)
Lars R.
> Lars Rohwedder schrieb am 29. April 2012 11:58
>
> > die Frage ist, welche Datenbanktabellen man ins Backup packt.
>
> Die, die man braucht, um gemäß den Anforderungen wieder rechtzeitig
> online zu sein.
Das ist eben die Frage, was "rechtzeitig" ist.
Außerdem: Als entschieden wurde, dass bestimmte (Cache-)Datenbanken
nicht ins Backup müssen, weil sie ja aus den Rohdaten schnell genug
durch Nachprozessieren wieder neu aufgebaut werden können, war die
Datenmenge noch klein genug, dass die Daten für 1 Monat in wenigen
Stunden verarbeitet waren. Auf einer Maschine, die ansonsten idle
war. :-/
> [...] Aber das Konzept kann sicher nicht sein, ich
> schick mal meine Platte irgendwohin oder ich glaube Oracle wird schon
> meine Platte wieder richten können.
Wir schicken unsere Platten nirgendwohin. Dazu sind die Daten darauf
dann doch zu vertraulich.
> Will man nur Server-Ausfall bei HA abfangen, dafür hat man dann
> mehrere Instanzen, die sich immer live replizieren. Für ein falsches
> "DROP DB" hilft das natürlich nicht.
Beides brauchen wir.
> > Da darf dann bei der Recovery wirklich nichts schiefgehen, sonst
> > kommt man mit Nachprozessieren nicht mehr hinterher.
>
> Disaster-Recovery ist so oder so immer außerhalb der normalen
> Prozeduren, also auch mit Downtimes. Das ist zumindest mein
> Verständnis davon, das wäre dann der Super-GAU. GAU ist dagegen
> Normalbetrieb.
Naja, wenn 1 DB-Server ausgefallen ist und seine Daten ausm Backup
wiederhergestellt werden müssen, sollte das den Betrieb der übrigen
DB-Server möglichst wenig stören.
> > Oder, um es mit DevOp-Borat zu sagen: If you don't have a disaster
> > recovery for your disaster recovery, you're doing it wrong.
>
> Na ja, also wer Backup und Recovery einfach beherrscht, der ist ja
> schon viel weiter als 90% der Unternehmen.
Wie einfach das Recovery ist, weiß ich nicht. Aber es wurde schon
mehrmals durchgeführt. Testweise und auch im Ernstfall. Es scheint
also zumindest zu funktionieren. :-)
Lars R.