[NEWSboard IBMi Forum]
  1. #1
    Registriert seit
    May 2001
    Beiträge
    29

    Question Incremental Backups

    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
    Grüße
    Michael

  2. #2
    Registriert seit
    Feb 2001
    Beiträge
    20.695
    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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  3. #3
    Registriert seit
    Mar 2002
    Beiträge
    5.365
    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

    Zitat Zitat von Fuerchau
    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.
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  4. #4
    Registriert seit
    Feb 2001
    Beiträge
    20.695
    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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  5. #5
    Registriert seit
    Mar 2002
    Beiträge
    5.365
    ???
    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

    Zitat Zitat von Fuerchau
    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.
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  6. #6
    Registriert seit
    Nov 2002
    Beiträge
    173
    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

  7. #7
    Registriert seit
    Mar 2002
    Beiträge
    5.365
    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.

    Zitat Zitat von bateau
    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
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  8. #8
    Registriert seit
    Dec 2000
    Beiträge
    450
    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

  9. #9
    Registriert seit
    Nov 2002
    Beiträge
    96
    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

  10. #10
    Registriert seit
    Aug 2004
    Beiträge
    923

    backup

    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

  11. #11
    Registriert seit
    May 2001
    Beiträge
    29

    Danke

    Wollte mich für die vielen Antworten bedanken.
    Die Incremental Backup Geschichte ist nun gecancelled worden.
    Jedoch hab ich hier einige sehr gute Antworten bekommen, die ich mal weiter verfolgen werde.
    Danke

    Gruß
    Michael
    Grüße
    Michael

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • You may not post attachments
  • You may not edit your posts
  •