Data Protector - Passion for Data Protection

data-protector.org

Autor Archiv: danielbraun

Restore AD Controller

Geschrieben am Von 6 Kommentare

Den Fall den man nie haben möchte – den AD Controller oder Teile davon wiederherzustellen. Da ich bereits schon mal in dieser Not war, nachfolgende eine kleine Anleitung wie es funktioniert. 

  1. Für den Restore im Authorative mode, Server booten und mit F8 –> „Verzeichnisdienst wiederherstellen“ auswählen
  2. Auf Server unter c:\progra~1\omniback\bin (oder da wo auf dem Server Data Protector installiert wurde) ein Batchfile erstellen (z.B. ntdsutilpost.cmd) mit folgendem Inhalt:
    • ntdsutil „popups off“ „authoritative restore“ „restore database“ quit
  3. Falls der Data Protector Dienst auf dem Server nicht gestartet wurde –> überprüfen ob der Dienst unter dem [SYSTEM] Account läuft
  4. In der DP GUI die gewünschten Objekte aus der Configuration auswählen – siehe Bild
      AD Restore 1
  5. Unter Restore Optionen im Postexec Bereich den Aufruf der Batch eintragen – nicht verunsichern lassen „Nonauthorative“ – das wurde ja schon über Punkt 1 auf authorative gesetzt
      AD Restore 2
  6. Restore Starten, das Ergebnis sollte dann wie folgt aussehen (nur relevanter Part) … Nach dem Restore den Server neu starten.

C:\WINDOWS\system32>ntdsutil "popups off" "authoritative restore" "restore database" quit
ntdsutil: popups off
Die interaktiven Popups sind deaktiviert.
ntdsutil: authoritative restore
authoritative restore: restore database

Die DIT-Datenbank wird geöffnet... Der Vorgang ist abgeschlossen. 

Aktuelle Zeit 03-10-10 16:34.56.
Die letzte Datenbankaktualisierung erfolgte um 03-10-10 15:50.54.
Die Versionsnummern des Attributs werden um 100000 erhöht. 

Die zu aktualisierenden Datensätze werden gezählt...
Gefundene Einträge: 0000000000______... (Anmerkung der Redaktion: einzelne Counters rausgelöscht)
__0000001675
Der Vorgang ist abgeschlossen. 

1675 Einträge wurden fr die Aktualisierung gefunden. 

Datensätze werden aktualisiert...
Verbleibende Datensätze: 0000001675__________0000001670____... (Anmerkung der Redaktion: einzelne Counters rausgelöscht)
__Der Vorgang ist abgeschlossen. 

1675 Datensätze wurden einwandfrei aktualisiert. 

Die folgenden Textdatei, die eine Liste autorisiert wiederhergestellter Objekte enthält, wurde im aktuellen Arbeitsverzeichnis erstellt:
ar_20100310-163457_objects.txt 

Mindestens ein angegebenes Objekt in dieser Domäne verfgt ber rckwärtige Verknpfungen. Die folgenden LDIF-Dateien mit Verknpfungswiederherstellungsvorgängen wurden im aktuellen Arbeitsverzeichnis erstellt:
ar_20100310-163457_links_Restore.loc-Configuration.ldf
ar_20100310-163457_links_Restore.loc.ldf 

Die autorisierende Wiederherstellung wurde erfolgreich abgeschlossen. 

authoritative restore: quit 

Advisory c02256887

Geschrieben am Von

Unter Der Dokument ID c02256887 ist am 24.06.2010 bei HP zu Data Protector 6.0, 6.10 und 6.11 ein Advisory erschienen, welches ein Problem unter HP-UX 11.31 und Vorgänger beim Benutzen einer Blocksize von > 256kb beschreibt.

Es gibt hier keine Lösung, da die Ursache im Design des stape Treibers von HP-UX liegt. HP empfiehlt eine größere Blocksize als 256 kb nicht zu nutzen.

Der vollständige Artikel kann hier nachgelesen werden: http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=c02256887&dimid=1004694894&dicid=alr_jun10&jumpid=em_alerts/us/jun10/all/xbu/emailsubid/mrm/mcc/loc/rbu_category/alerts

Advisory c02256766

Geschrieben am Von

Unter Der Dokument ID c02256766 ist am 23.06.2010 bei HP zu Data Protector 6.11 ein Advisory erschienen, welches ein Problem beim Backup und Restore von Datenbanken > 4 TB beschreibt wenn der backint Modus verwendet wird und die .omnirc Variable OB2SAPALIGN ungleich 0 ist.

Der Workaround bis zum Erscheinen des Patches ist die Variable OB2SAPALIGN nicht zu verwenden oder einen Site Specific Patch zu installieren, dieser steht für folgende Systeme zur Verfügung:

  • HP-UX – SSPUX611_013
  • Solaris – SSPSOL611_007
  • Linux, AIX, Tru64 – SSPLNX611_014

Der vollständige Artikel kann hier nachgelesen werden: http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=c02256766&dimid=1004694894&dicid=alr_jun10&jumpid=em_alerts/us/jun10/all/xbu/emailsubid/mrm/mcc/loc/rbu_category/alerts

Installation Patches – Allgemein

Geschrieben am Von 5 Kommentare

Nicht immer ist klar wie und in welcher Reihenfolge Patches installiert werden müssen. Es gibt Abhängigkeiten in den Patches die bei der Installation beachtet werden müssen, eine fortlaufende Installation nach den Nummern am Ende des Patchnamens ist nicht möglich, bzw. kann dazu führen das Binaries überschrieben werden.

Generell ist folgende Patch Reihenfolge einzuhalten:

  • Installation Core Patch (Core)
  • Installation Cell Server Patch (CS)
  • Installation Cell Console Patch (CC)
  • Installation Mediaagent Patch (MA)
  • Installation Diskagent Patch (DA)
  • Installation Integrations Patches (z.B. ORA; SMIS, Exchange, …)

Export / Import

Geschrieben am Von 16 Kommentare

Immer wieder mal findet man Anleitungen wie ein Export / Import der internen Datenbank von Data Protector vorzunehmen ist. Diese Prozedur wird immer dann eingesetzt wenn Probleme in der Datenbank auftreten (korrupte Medien, …) – Stichwort Healthcheck und omnidbcheck. Bei der nachfolgenden Prozedur wird nicht nur einfach exportiert und importiert, sondern im Zuge der Arbeiten auch gleich noch aufgeräumt, die Datenbank „gepurged“.

  • 2 leere Verzeichnisse (mit genügend Platz) anlegen wo die catalog database und die media management database exportiert werden kann (z.B.: d:\mmdb und d:\cdb oder /tmp/mmdb und /tmp/cdb)
  • Sicherungskopie von Data Protector anlegen – Stoppen der Dienste (omnisv -stop), Kopieren des kompletten Data Protector Verzeichnisses (z.B.: d:\program files\omniback – es würde eigentlich das db40 und options Verzeichnis ausreichen), Starten der Data Protector Dienste (omnisv -start)
  • Prüfen das keine Sicherungen laufen, der Export benötigt exklusiven Zugriff zur Datenbank (je nach Größe der Umgebung sollte der Schedule gestoppt werden – siehe Blogeintrag  „Commands“
  • Optional: omnidb -strip – entfernt die catalog information von allen Objekten die nicht mehr geschützt sind
  • Optional: omnidbutil -purge -sessions 90 – entfernt media management sessions, restore sessions und obsolete backup sessions (backup sessions ohne gesicherte Daten) die älter wie 90 Tage sind
  • Optional: omnidbutil -purge -filenames -force – entfernt obsolte filenames (Dateinamen ohne Versionen) aus der catalog database (der Prozess kann im Monitor beobachtet werden)
  • Optional: omnidbutil -purge -dcbf -force – entfernt die DCBF files für alle Medien ohne catalog protection
  • Export der Datenbank: omnidbutil -writedb -mmdb d:\mmdb -cdb d:\cdb – die Verzeichnissnamen aud Step 1 sind zu verwenden. Der Export kann je nach Größe der Datenbank einige Zeit dauern (bei großen Datenbanken kann mit 1 GB pro Stunde gerechnet werden – aus Erfahrung kann ich sagen das ein Export schon auch mal 12 Stunden laufen kann)
  • Am Ende des Exports wird aufgefordert die dcbf und msg Verzeichnisse zu kopieren, diese werden später nach dem Import benötigt
  • Neuinitialisieren der Datenbank mit dem Befehl omnidbinit
  • Optional – falls mehr wie ein DCBF Verzeichnis benutzt wurde und eine fnames Erweiterung vorhanden waren, so sind diese jetzt über die GUI anzulegen.
  • Import der Datenbank: omnidbutil -readdb -mmdb d:\mmdb -cdb d:\cdb – die Verzeichnissnamen aud Step 1 sind zu verwenden. Der Import kann je nach Größe des Exports einige Zeit dauern
  • Stoppen der Data Protector Dienste (omnisv -stop)
  • Kopieren der dcbf und msg Verzeichnisse (die während des Exports weggesichert wurden) an die originale Stelle
  • Starten der Data Protector Dienste (omnisv -start)