Lars Rohwedder schrieb am 30. April 2012 10:48
> 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.
Das, was geschäftlich definiert wird.
> 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. :-/
Wie groß sind denn die Cache-DBs? Ist das auch SQL? Welche-SQL-Server
fahrt ihr eigentlich?
> > [...] 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.
Eben, mein Einstiegs-Posting bezog sich genau auf den Fall, dass
jemand Oracle-DBs einsetzt, weil er hofft, im Notfall mehr Daten von
den Platten zu kratzen. Das ist für die meisten Leute, die ich kenne,
gar keine Option sich auf so etwas zu verlassen. Der OP meinte wohl
aber eine automatische Reparatur (hoffe ich).
> > 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.
Es gibt Umgebungen, da ist das technisch bzw. finanziell nicht mehr
darstellbar ein Backup zu fahren. Da muss man dann schauen, dass man
Prozesse und Berechtigungen geradezieht, um falsche Bedienung auf
beinahe 0 runterzufahren.
> > > 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.
Tut es ja auch nicht, wenn man es richtig macht. Man spielt das
Backup ein, danach fängt die Kiste an die Replikation zu starten.
mfg
Oli
> 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.
Das, was geschäftlich definiert wird.
> 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. :-/
Wie groß sind denn die Cache-DBs? Ist das auch SQL? Welche-SQL-Server
fahrt ihr eigentlich?
> > [...] 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.
Eben, mein Einstiegs-Posting bezog sich genau auf den Fall, dass
jemand Oracle-DBs einsetzt, weil er hofft, im Notfall mehr Daten von
den Platten zu kratzen. Das ist für die meisten Leute, die ich kenne,
gar keine Option sich auf so etwas zu verlassen. Der OP meinte wohl
aber eine automatische Reparatur (hoffe ich).
> > 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.
Es gibt Umgebungen, da ist das technisch bzw. finanziell nicht mehr
darstellbar ein Backup zu fahren. Da muss man dann schauen, dass man
Prozesse und Berechtigungen geradezieht, um falsche Bedienung auf
beinahe 0 runterzufahren.
> > > 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.
Tut es ja auch nicht, wenn man es richtig macht. Man spielt das
Backup ein, danach fängt die Kiste an die Replikation zu starten.
mfg
Oli