-
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
-
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 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
-
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
-
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
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks