PDA

View Full Version : Incremental Backups



Seiten : [1] 2

mic74
13-10-04, 13:36
Hallo AS/400 Spezies,
ich hätte da gerne mal ein Problem.
Wir wollen in den nächsten Wochen auf Incremental Backups umsteigen und müssen 100% sicher sein, daß es funktioniert bevor wir live einsetzen.
Unser Problem:
Wir sichern täglich über BRMS auf einem Backup System ( deferred Backup ) an dem wir 3 3590E Units angeschlossen haben. Währenddessen läuft auf der Produktionsbox unsere Nachtverarbeitung. Wir können derzeit nur nach der Nachtverarbeitung auf der Produktionsbox testen. Dort haben wir 3 3592 Tapeunits laufen. Daher werden wir keinen direkten Vergleich über Zeiteinsparung machen können. Habt Ihr bereits Erfahrung mit Incrementals und ist die Erfahrung positiv oder eher nicht? Wie habt ihr getestet?

Danke für die vielen Antworten.

Gruß
Michael

Fuerchau
13-10-04, 15:08
Das Sichern ist natürlich schneller, da z.T. erheblich weniger gesichert wird.
Andererseits wird das Wiederherstellen DEUTLICH problematischer.
Insbesonders wenn man mal einzelne Objekte sucht. Der gesamte Restore umfasst dann den letzten Komplettbackup sowie ALLE darauf folgenden Incremental-Backups.

BenderD
13-10-04, 16:19
Hallo,

macht die BReMSe das anders als der SAVCHGOBJ? ich habe da im Hinterkopf, dass die Komplettsicherung und der letzte SAVCHGOBJ den aktuellen Stand ergeben.

mfg

Dieter Bender,
der kein Freund von inkrementellen Sicherungen ist


Das Sichern ist natürlich schneller, da z.T. erheblich weniger gesichert wird.
Andererseits wird das Wiederherstellen DEUTLICH problematischer.
Insbesonders wenn man mal einzelne Objekte sucht. Der gesamte Restore umfasst dann den letzten Komplettbackup sowie ALLE darauf folgenden Incremental-Backups.

Fuerchau
13-10-04, 16:28
Das würde dann auch bedeuten, dass der Objekt-Update, auf welchem Band gesichert wurde (DSPOBJD), fehlt ???
Wenn das der Fall ist, läßt sich ohne Listen wohl kaum noch heruasfinden, wo ein Objekt zuletzt gesichert wurde.

BenderD
13-10-04, 16:54
???
Normal starte ich mit einem SAVLIB
dann mache ich täglich SAVCHGOBJ mit REFDATE(*SAVLIB), was default ist; mit der Folge dass selbiger jeden Tag größer wird und wenn ich die Faxen dicke habe, mache ich wieder einen SAVLIB.
Dann steht im DSPOBJD entweder der Tag des letzten SAVLIB drin, oder das Datum des letzten SAVCHGOBJ, wo ist da das Problem?

Dieter


Das würde dann auch bedeuten, dass der Objekt-Update, auf welchem Band gesichert wurde (DSPOBJD), fehlt ???
Wenn das der Fall ist, läßt sich ohne Listen wohl kaum noch heruasfinden, wo ein Objekt zuletzt gesichert wurde.

bateau
13-10-04, 17:30
Namd Michael,

ich rate dir eindeutig von inkrementellem Backup ab!

Argumente:

1.) Die Anzahl der SPOFs erhöht sich dramatisch. Ist eines der Cartridges im A.... kannst Du dein Backup in die Tonne treten. Es sei denn, Du machst von jedem einzelnen Medium eine Kopie per DUPTAP.

2.) Warum inkrementell? Wenn Du schon ne 3494 hast und die 3590 Drives durch die 3592 ersetzt wirst Du dein Backup um Faktor 2-3 beschleunigen.

3.) Die Komplexität für die Wiederherstellung erhöht sich extrem, wie schon von BänderD und Baldur angesprochen

4.) Ein Vielfaches der beim Backup gesparten Zeit geht in einem Disaster Fall für den Restore drauf, das sollte man bedenken.

Grüsse

Martin

BenderD
13-10-04, 22:54
Hallo,

Batto hat natürlich recht, was die Grundeinschätzung zu inkrementellem save angeht: obertse Priorität hat die Einfachheit und Geschwindigkeit des recovery Vorgangs, wer sowas schonmal gemacht hat, weiss warum.
Dennoch habe ich da ein paar Einwände. der guten Ordnung halber:
ad 1.) es verdoppelt sich genau: die Grundsicherung muss passen und die letzte SAVCHG
ad 2.) das größte Potential liegt in der Parallelisierung von SAVE Vorgängen, die Geschwindigkeit der Bandgeräte ist sekundär und kann auch durch Spooling (save in Savefile und anschließend auf Band) beliebig kompensiert werden - wobei ich mich nicht aktuell damit beschäftigt habe, was die BReMSe da so treibt.
ad 3.) wenig Einwand
ad 4.) hier kommt noch dazu, dass paralleles Restore, sogar notfalls nach initialem DUPTAP, die Kuh zum fliegen bringt.

mfg

Dieter Bender,
den das früher mal mehr interessiert hat als heute.


Namd Michael,

ich rate dir eindeutig von inkrementellem Backup ab!

Argumente:

1.) Die Anzahl der SPOFs erhöht sich dramatisch. Ist eines der Cartridges im A.... kannst Du dein Backup in die Tonne treten. Es sei denn, Du machst von jedem einzelnen Medium eine Kopie per DUPTAP.

2.) Warum inkrementell? Wenn Du schon ne 3494 hast und die 3590 Drives durch die 3592 ersetzt wirst Du dein Backup um Faktor 2-3 beschleunigen.

3.) Die Komplexität für die Wiederherstellung erhöht sich extrem, wie schon von BänderD und Baldur angesprochen

4.) Ein Vielfaches der beim Backup gesparten Zeit geht in einem Disaster Fall für den Restore drauf, das sollte man bedenken.

Grüsse

Martin

Bruno Jakob
14-10-04, 08:31
Hallo Michael,

warum wollt ihr denn überhaupt auf inc. Backups umsteigen? Wenn nicht absolut notwendig, würde ich da auch die Finger davon lassen. Im K-Fall ist wahrscheinlich eh schon genug Verwirrung. Da muss man die Wiederherstellung nicht auch noch komplizierter und fehleranfälliger machen.

Gruß
Bruno

systemer
14-10-04, 09:22
Hallo Michael,

ich kann Bruno nur zustimmen. Vor einiger Zeit hatten wir in unserem Hause ähnliche Überlegungen angestellt. Bis uns ein sehr kompetenter Mitarbeiter von SAP dringend davon abgeraten hat (wir haben hier nur SAP auf der Maschine, aber die Sicherungslogik ist ja die gleiche).

Er meinte auch, daß der kurzfristige Zeitgewinn beim Incremental Backup mehr als zunichte gemacht wird durch die ungleich höhere Komplexität beim Recovern eines so gesicherten Systems.

Warum wollt Ihr denn Euer Sicherungsverfahren umstellen?

Gruß,
Systemer

kuempi von stein
14-10-04, 09:56
Hello Alle,

ich vermute mal, dass da ein doppeltes Problem besteht.
War bei mir bei nem früheren Arbeitgeber auch mal so...
Da wurde "Live" gesichert weil einfach kein Plattenplatz mehr war um über SAVF zu arbeiten...
Da kamen genau solche Ideen wie incrementales Save hoch...

Grussle

kuempi