• Das cumulative NT/Win2000 Novell packet "OMNIBACK_00042" soll einige Fehler unter Netware 5.x beheben:
  • Abend's auf dem Novell-Server beim File-Restore (hatte ich seit "OMNIBACK_00024" nicht mehr)
  • Sichern von Dateien mit langen Dateinamen schlägt mit "Can not stat: ([1] no such file or directory )==> not backed up" fehl (leider ein bekanntes Problem - mal sehen ob HP seine Hausaufgaben gemacht hat?)
     

• Installation der Hardware (Gigabit-Ethernet, LVDS-SCSI, Netraid) und des Betriebssystems auf der neuen Box mit temporärem Rechnernamen
• Anhalten sämtlicher OBII-Dienste und Sicherstellen das während der nächsten Stunden keine Jobs anliegen!! Auch andere Backupoperatoren informieren - das hatte ich doch glatt vergessen ;-))
• Kopieren des gesamten Omniback-Verzeichnisses und der Datenbanken vom alten Zellmanager auf die neue Box
• Sichern des Config-Verzeichnisses des alten Zellmanager auf Diskette
• Abschalten der alten Box
• Umbenennen der neuen Box zum Namen des alten Zellmanagers und Anpassen der IP-Adresse
• Installieren der Omniback-Software inkl. Patches auf der neuen Box (Wiederherstellung der Registry-Einträge)
• Rücksichern des Config-Verzeichnisses (Bei Installation werden einige Config-Files überschrieben, z.B. die Nutzerlisten)
• Anpassung der Konfiguration lokal am Zellmanager angeschlossener Tape-Drives in OBII
• eigentlich Fertig
• Um die Datenbank zu Bereinigen und die Datenbank-files neu zu organisieren habe ich noch ein omnidbutil -writeascii / omnidbinit  / omnidbutil -readascii hinterhergeschoben.
  Achtung:  Das dauert!! für meine DB brauchte die Box 2h (write) und 20h !! (read)
  (man kann das writeascii auch noch auf der alten Box machen. Da mein neuer Server aber wesentlich performanter ist, habe ich mich für diesen Weg entschieden)

• Version1:
  Ab Patchlevel 17 ist es möglich mit Omniback einzelne Postfächer oder öffentliche Ordner zu sichern oder Rückzusichern. Eine genaue Anleitung dieses doch etwas komplexen Vorgangs kann hier im PDF-Format nachgelesen werden.
• Version2: (nachzulesen im Windows-Integrations Handbuch)
  • Installation eines Exchange-Servers auf separatem Rechner (ich nutze VMWare!) mit den selben Struktur und Site-Namen wie auf dem Original-Server (sonst kann später der Information-Store nicht gestartet werden - Dienstfehler 1276)
  • Installation der Omniback-Exchange Integration und Import in OBII-Cell
  • Restore der MDB-Database (Information-Store) auf dem temporären Server  Die Exchange-Dienste müssen hierfür gestoppt werden. Das erledigt Omniback auf Wunsch mit. (DS kann bei Rücksicherung auf anderen Server nicht wiederhergestellt werden!)
  • Konsistenzanpassung des privaten Informationsspeichers mit dem DS-Verzeichniss, damit die rückgesicherten Postfächer auch unter den Serverempfängern erscheinen (Im Exchange-Admin die Eigenschaften des Servers öffnen - weitere Optionen - Konsistenzanpassung)
  • Verbinden zum gewünschten Postfach auf dem temporären Server mit Exchange-Client und extrahieren des gewünschten Postfaches in einen persönlichen Ordner
  • Neuerstellen der gewünschten Mailbox auf dem heißen System
  • Verbinden zum Postfach und Überspielen der rückgesicherten Daten aus dem persönlichen Ordner
  • Fertsch!

Soll Omniback über eine Firewall betrieben werden, sind einige Punkte zu beachten. Laut HP wird nur der Zugriff mit der GUI auf den Zell-Manager über eine Firewall supportet, aber auch das sichern "auf der anderen Seite" ist möglich. Hierzu gibt es zahlreiche Postings im ITRC-Forum (All Stuff about Backup over Firewall in ITRC-Forum)
Ein Backup über eine Firewall ist nur möglich, wenn sich die beteiligten Disk- und Media-Agents auf der selben Seite der Firewall befinden!

Meine Konfig:

• Cellmanager: OBII 3.5 auf W2K im internen LAN (DNS:backup.xyz.lan)
• Clients: NT4+W2K Server:OBII 3.5 in DMZ (installiert ist der DA und der MA, jeder Server verfügt über eigenes DAT-Drive, DNS:Clientx.xyz.de)
• Das Backup soll vom internen Zellmanager aus gesteuert werden. In der DMZ befindet sich keine USER-GUI. Die Backup-Infos (Filenames, Versionen, Meldungen) werden in die DB auf dem Zellmanager geschrieben.

Meine Lösung:

• Als erstes muß die Namensauflösung funktionieren. Um dies Einzurichten und zu Testen, habe ich kurzzeitig das Ping zwischen den Clients und dem Zellmanager auf der Firewall erlaubt. Der Zellmanager, sowie jeder Client muß alle Namen der anderen beteiligten Server auflösen können:
  vom Zellmanager muß gehen:
  • nslookup Clientx.xyz.de
       -> Rückgabe der korrekten IP_Adresse_des_Client
  • nslookup IP_Adresse_des_Client
       -> Rückgabe des korrekten DNS-Namens: Clientx.xyz.de
  • Ping Clientx.xyz.de
       -> IP_Adresse_des_Clients sollte korrekt angezeigt werden und mit dem
           erlaubtem Ping auf der FW sollte auch eine Rückantwort kommen

  Dasselbe ist von allen Clients aus zum Zellmanager zu überprüfen. Erst wenn die Namensauflösung steht ist es sinnvoll mit der Installation Fortzufahren.
  Ein typischer Fehler bei mangelhafter Namensauflösung ist: "Can not connect Media Agent on system <XXXXXX>, port 2422 (IPC Invalid Hostname or IP Address, sytem error:[11001] Host not found"

• Nun die Firewall-Regeln - zu diesem Punkt gibt es im ITRC-Forum die verschiedensten Aussagen. Einmal reicht die Freigabe des Ports 5555 - in anderen Fällen soll im omnirc-File ein Portrange definiert werden, der dann über die Firewall freigegeben wird, oder gar alle Ports über 42000!. Mit solchen Löchern ist natürlich kein Firewall-Admin einverstanden.
  
  Mir jedenfalls genügte folgende kleine Regel auf der Firewall:
   

  Source	Destination	TCP-Source-Portrange	TCP-Destination-Portrange
  backup.xyz.lan	Clientx.xyz.de	5555	5555

• Anschließend die Software-Installation auf den Clients. Hier habe ich die Installations-CD bemüht und eine Clientinstallation nur mit Disk- und Media-Agent durchgeführt. Den aktuellen Service-Pack für OBII auf Windows habe ich gleich nachgeschoben.
• Nach der Installation gleich wieder ein Test: vom Zellmanager aus sollte sich mit einem Telnet auf Port 5555 des Clients der Omniback-Dienst melden.
• Als letztes habe ich nun noch den Client in die OmniBack-Zelle importiert (GUI auf Zellmanager) und die Tape-Drives der Clients konfiguriert.

Sind diese Schritte alle erfolgreich absolviert, kann eine Sicherungsspezifikation angelegt werden. Hierbei ist darauf zu achten, das wirklich nur vom Diskagent auf dem Client in der DMZ zu dessen Mediaagent gesichert wird. Eine Sicherung der Daten aus der DMZ auf ein Laufwerk im internen LAN (oder umgekehrt) ist nicht möglich!

• DNS-Eintrag für jede zu sichernde Clusterressource mit der Cluster-Ressource-IP-Adress erzeugen und Namensauflösung vom  Cellmanager aus testen
• Für das Backup wird die auf SYS: der jeweiligen Node installierte Version von Omniback genutzt. Da diese in der Regel schon in der Omniback-Cell registriert ist, ist ein Import der Clusterressource als Omniback-Client nur möglich, wenn die Cell-Infos auf der Node die die Ressource momentan hält gelöscht wird.
  Dies geschieht einfach durch Löschen der Datei CELL_SERVER im Verzeichniss sys:usr\omni\config\cell. Mann kann natürlich auch vorher eine Sicherheitskopie der Datei erstellen!
  Beim Import der Clusterressource in OBII wird die Datei neu erstellt. (… und muß vor dem Import der nächsten Ressource natürlich wieder gelöscht werden)
• Nun sollte in der/den Sicherungsspezifikation noch die Importierte Clusterressource der Sicherung hinzugefügt werden. Aber bitte nicht komplett, sondern nur das zur Ressource gehörende Volume. (Es werden hier jetzt alle Volumes der momentan aktuellen Node angezeigt, da unter dem virtuellen Server die eigendliche Clusternode angesprochen wird)
• Sind alle Clustervolumes in beschriebener Art und Weise konfiguriert, muß die Sicherungsspezifikation für die Clusternodes selbst noch angepasst werden. Hier sollte nun nur noch das Volume SYS und gegebenenfalls die NDS (Configuration) gesichert werden!

Ab sofort gibt es keine Sucherei mehr, wenn Lutz Meier mal wieder seinen Urlaubsschein aus Versehen gelöscht hat.

Ich sicher auf diese Art und Weise nun schon einige Monate, und konnte keine Probleme feststellen, die nicht vorher auch schon da waren.

Ich habe auch damit experimentiert, die Omniback-Software vom jeweiligen Clustervolume aus im Ressource-Script zu laden und zu entladen. Prinzipiell funktionierte das auch. Da aber die Omniback-Instanzen selbst nicht Clusterfähig sind wird beim Migrieren einer Ressource Omniback auf der Source-Node komplett entladen.

• Type of device (capacity of the tape)
• Block size

Generally, you want to increase Medium Header to 0.5% of the estimated complete capacity of the tape. For example:
 

Achtung: die geänderten Werte gelten nur für danach Neu initialisierte Bänder, Omniback kann die Bufferblöcke nicht zu bereits initialisierten Bändern hinzufügen!

Beispiel omnirc:

# OB2BLKPADDING_n
# Default: 0
# When copying tapes it can happen that the data on the source tape does
# not fit on the target tape. This can be due to a perfect streaming of
# the source tape during the backup which may not be the case for the
# target tape during the copy or a slightly different length of source
# and target tape. In order to avoid this, this set of variables
# specifies the number of empty blocks written after the tape header at
# the initialization time. The effect is that the size of data on the
# medium is smaller, and tape copy should not have any problems. Of course,
# when the medium is copied, those empty blocks are not copied.
#
# For each device type, there is a special variable used, specifying the
# number of dummy blocks to be written after the medium header (device
# default block size is used):
#
# OB2BLKPADDING_1 DAT/DDS
# OB2BLKPADDING_2 QIC Quarter Inch Cartridge
# OB2BLKPADDING_3 8mm - ExaByte
# OB2BLKPADDING_4 AIT - Advanced Information Technology
# OB2BLKPADDING_5 3480 Cartridge (or STK9840 in OB 3.00/3.10)
# OB2BLKPADDING_6 Raw Magnetic Disk
# OB2BLKPADDING_7 Regular Disk File
# OB2BLKPADDING_8 STK9840   <————--ONLY FOR OB 3.50 and higher
# OB2BLKPADDING_9 Generic Magnetic Tape Device
# OB2BLKPADDING_10 DLT - Digital Linear Tape
# OB2BLKPADDING_11 StorageTek SD-3 - Redwood
# OB2BLKPADDING_12 3590 Cartridge (Magstar)
#
# For example:
# OB2BLKPADDING_3=5
# If uncommented, this will put 5 empty blocks on the beginning
# of every 8mm - Exabyte media written.
#

Rufen Sie omnidbcheck aus einer Terminalsession des W2K-Servers auf? Da läuft es nicht und bricht mit dieser Fehlermeldung ab. Aus der Traum von kompletter Fernwartung von Omniback per Terminal-Services.

Läuft omnidbcheck direkt am Server dann können sie  folgende Lösungen probieren:
Ich bin im Omniback-Forum auf 2 Lösungsansätze Ansätze gestoßen:

Einen Versuch kann man auf jeden Fall mit writeascii/readascii versuchen, um die korrupte Datenbank wieder zu reparieren. Hier besteht die Chance, das die Daten der Datenbank erhalten bleiben - aber mit erheblichem Zeitaufwand. (meine DB mit ca. 6 GB dauert 24h in denen kein Backup erfolgen kann) Diese Variante hat allerdings den Vorteil, das gleich die Datenbank Bereinigt und neu Organisiert wird. Je nach Defekt der Datenbank kann aber auch schon das writeascii scheitern.

Meine (vom Zeitbedarf her meiner Meinung nach praktikablere) Lösung ist ein Restore der letzten guten Datenbanksicherung und (wenn notwendig) anschließendes Einlesen der nach dieser Sicherung genutzten Bänder. Das Restore ist schnell erledigt, und die fehlenden Bänder können bei Bedarf in noch bestehenden Zeitfenstern des Backupregimes eingelesen werden. Eine Anleitung hierfür gibt es im Adminhandbuch (adminnt.pdf: Kapitel 9 - Restoring the Database).
Hier meine Variante:

• Restore
  • Im Omniback-Manager auf Wiederherstellen ->Omniback Datenbank
  • Datenbank-Backup auswählen und "Auswahl für Wiederherstellung" aktiviern
  • wiederherzustellende Datenbankversion (Backupdatum) auswählen
  • Laufwerk und Pfad für temporäres Verzeichniss angeben
  • Start Restore
• Recovery (Einspielen der Datenbank)
  • mit "omnisv stop" alle Omniback-Prozesse stoppen
  • Inhalt des Verzeichnisses <Omniback_home>\db löschen, oder besser Verzeichniss in db.old umbenennen, damit der Rückweg offen bleibt. (Ist genügend Plattenplatz vorhanden??) Auch alternative Datenbankverzeichnisse mit Erweiterungsdateien auf anderen Laufwerken löschen/umbenennen!!
  • Datenbankdateien von temporärem Verzeichnis der Rücksicherung an Originalstandort verschieben
  • Omniback Starten
  • sicherheitshalber omnidbcheck - mal sehn ob es läuft, und die wiederhergestellte DB in Ordnung ist
  • Fertsch

Wenn das Problem hiermit noch nicht behoben ist, (Sicherung der Datenbank auch schon fehlerhaft ?) bleibt nur Variante 1 (write-/readascii) oder der Start mit einer neuen leeren Datenbank.

• SmMaIdleTimeout=240
  Zeit, die der Sessionmanager (SM) auf eine Antwort vom Media-Agent (MA) wartet. Dieser Wert hat sich bei mir bewährt. Der Timeout wird in Minuten angegeben. Standard ist 140 Min.
• SmDaIdleTimeout=200
  Zeit, die der Sessionmanager (SM) auf eine Antwort vom Disk-Agent (DA) wartet.Der Timeout wird in Minuten angegeben. Standard ist 120 Min.

Es ist zu Beachten, das der Wert für SmMaIdleTimeout immer größer als SmDaIdleTimeout ist!