Schlagwort-Archive: Dataprotector

Dataprotector: Linux Clients ohne rexec und rcp

Umgebung:
HP Dataprotector mit einem Linux Installationsserver und einem Windows Cell-Server.

Das Problem:
Wenn man im HP Dataprotector einen Linux-Client hinzufügen will, kommt eine Meldung, dass DP sich nicht über rexec und rcp am Client verbinden kann, um die Software zu installieren.
no-rexecec

Weiter oben im Fehlerprotokoll sieht man allerdings, dass zuerst eine ssh Verbindung probiert wird. Leider gelingt das nicht, weil man an dieser Stelle keine Anmeldedaten übergeben kann. Der Anmeldeversuch wird abgewiesen.

Lösung:
Um den Dataprotector Client zu installieren, benötigt man eine ssh-Verbindung OHNE Passwortauthentifizierung.

Erster Schritt:
Mit ssh vom Installationsserver zum Client verbinden.
Jetzt noch mal vom Client zum Installationsserver verbinden.
Dadurch werden die beteiligten Rechner gegenseitig schon mal in ssh zu den “known-hosts” hinzugefügt.
ACHTUNG:
Bitte einmal nur mit dem Hostnamen und danach noch mal mit dem FQDN verbinden. Z.B.:
’ssh linuxclient’ und danach noch mal ‘ssh linuxclient.domain.local’
Dataprotector verwendet beide Varianten!

Zweiter Schritt:
Im root home Verzeichnis in den Ordner .ssh wechseln.
Dort generiert man jetzt ein DSA Schlüsselpaar (private/public)
ssh-keygen –t dsa
Dadurch werden zwei Dateien generiert, die in der Regel ‘id_dsa’ und ‘id_dsa.pub’ heißen.
Den öffentlichen key (pub) kopiert man jetzt auf den Rechner, mit dem man sich ohne Kennwort verbinden möchte.
ssh-copy-id –i ~/.ssh/id_dsa.pub benutzer@hostname
oder
cat ~/.ssh/*.pub | ssh benutzer@hostname ‚umask 077; cat >>.ssh/authorized_keys‘
Als Test kann man jetzt probieren, ob man sich vom Installationsserver aus auf den Client ohne Passwort verbinden kann.

Dritter Schritt:
Auf dem Linux-Client noch inet aktivieren. Bei Suse im YAST unter Netzwerkdiensten xinet aktivieren. Dort muss sonst nichts weiter ausgewählt werden.

Viertens:
Jetzt sollte die Installation des Clients gelingen. Danach bitte noch folgendes prüfen:
Auf dem Client sollte in der /etc/services (meistens am Ende) folgender Eintrag vorhanden sein:
omni             5555/tcp    # DATA-PROTECTOR
Es darf auch kein anderer Dienst auf dem Port 5555 laufen, da dies der Standardport für Dataprotector ist.
Es ist NICHT möglich, den Port für einen Client im DP zu ändern.
Wenn dies notwendig sein sollte, muss der Port für alle Clients geändert werden.

Ein letzter Test:
Auf dem Cellserver (nicht dem Installationsserver) anmelden und versuchen, ob man eine Telnetverbindung auf Port 5555 aufbauen kann.
telnet clientname 5555
Wenn es Telnet auf dem Cellserver nicht gibt, kann man das auch alternativ mit einer Software wie Putty probieren.
Ich teste das gerne direkt vom Cellserver aus, da dieser Server die Verbindung später benötigt.

Omniback (HP Dataprotector) Backup für Xenserver

Die Situation: Im Unternehmen ist bereits der HP Dataprotector im Einsatz. Da jetzt auch produktive Systeme auf dem Xenserver laufen sollen, müssen auch die VMs automatisiert gesichert werden können.

Der Ansatz: Die HP Data Protector Integration für Xenserver

Die Umsetzung:
Was wird benötigt?
1. Xenserver mit VMs
2. Data Protector Server
3. Backup Device (Tape und/oder Disk)
4. DP Client (Windows oder Linux Rechner mit installiertem DP Client / Disk Agent, Media Agent)

Auf dem Xenserver muss nichts geändert werden.
Auf dem DP Client muss folgende Software installiert werden:
– Python
– Curl
– Pycurl (Achtung: Passend zur Python Verson)
– XenAPI.py
– Integration Scripts
und noch ein Backup-Ordner für die temporäre Ablage der *.xva Dateien

Genauere Information gibts hier: bizsupport1.austin.hp.com/bc/docs/support/SupportManual/c01749588/c01749588.pdf
Jetzt wird die DPxen_config.py mit einem Editor angepasst.

Hier ein Beispiel (ist aber alles gut kommentiert):
# Before starting the DP backup or restore the values in this script should be update
# Desired way to preform the backup or in case of restore type of backup used
# the types allowed are: [ offline, allOffline, online, allOnline]
mode = „online“

# Url of the xen Server that contains the vm for backup or where we want to restore.
url = „http://IP-des-xenservers“

# Login information of the xen Server
username = „root“
password = „geheimespasswort“

# If needede name of the  vm to backup or restore, is case sentitive
vmNames = [„Debian“]

# Flag for creating a debug file
debug = True #[True, False]

# In case of restore, the name of the sr where we want to restore
srName = „“   #“Local File SR | Shared Storage“#case sensitive If not applicable set to empty string.

 

Statt des root-accounts sollte natürlich ein BAckup-Account angelegt wwerden. Ich habe das nur mal aus meinem Testnetz übernommen.

In Data Protector kann nun ein neues File-Backup angelegt werden:

 

Backup –> Backup Specifications –> Right Click on Filesystem –> Add Backup

Blank Template –> OK

 

Tmp Backup Folder: C:\tmp\backup

 

Pre-exec: C:\Programme\OmniBack\bin\Python25\python.exe C:\Programme\OmniBack\bin\DPxen_backup.py DPxen_config

On client: Mein-DPClient

 

Post-exec: C:\Programme\OmniBack\bin\Python25\python.exe C:\Programme\OmniBack\bin\DPxen_postbackup.py

On client: Mein-DPClient

 

Der Pre-Exec Teil erzeugt das Backup der VM und erstellt sie im temporären Verzeichnis. bei einem Windows DP Client z.B. in C:\tmp\Backup. Dazu gibts noch eine Protokoll-Datei unter C:\tmp.

Dann wird ein normales File-Backup für das tmp-Verzeichnis durchgeführt.

Beim Post-Exec werden dann die *.xva Dateien abgelöscht. Die Protokoll-Dateien bleiben liegen!

Die sollte man von Zeit zu Zeit mal ablöschen.

 

Unterschiede Online-Backup und Offline Backup

Neben der offensichtlichen Tatsache, dass die VM beim Online-Backup weiterläuft (Beim Offline wird sie einmal kurz gestoppt, gesichert und dann wieder gestartet, bzw. in den Status vor Backupbeginn gebracht),

gibt es noch eine Besonderheit:

Das online-Backup erzeugt Snapshot-Dateien mit dem Namensmuster „Xen-IP_VMName_Snapshot.xva“.

Das offline Backup erzeugt Exports mit dem Bezeichnungsmuster „Xen-IP_VMName.xva“.

Das ist für den Restore nicht ganz unwichtig.

Und noch etwas: Ich habe versucht eine VM zu sichern, die keinem Xenserver fest zugeordnet ist.

Das ist mir aber ausschließlich im Onlinemodus gelungen. Beim Offlinemodus wurde lediglich eine 0kb Datei erzeugt und der DP meldete erfolgreichen Vollzug .

 

Das Restore habe ich bisher immer manuell durchgeführt. Man kann aber im DP einen Restore konfigurieren.

Aber ehrlich gesagt ist es mir lieber (und voll ausreichend), wenn ich die Backup-Dateien wiederhergestellt bekomme und ich mir die selbst wieder auf den Xenserver einspiele.

 

Der Data Protector Restore wird aber demnächst auch noch getestet!

HP Data Protector: Upgrade 6.21 auf A.07.00 Installation Server

Beim Upgrade-Versuch von 6.21 auf A.07.00 Installation Server gibt es einen wichtigen Punkt zu beachten 🙂

Voraussetzung:
Die Installationspakete:
ESD,_HP_DP_7.00_for_Linux_TD586-15005.tar.gz
ESD,_HP_DP_7.00_for_HP-UX_TD586-15004.tar.gz

Beim Entpacken der Dateien erhält man folgende Verzeichnisse:
DOCS
HPSW_Integrations
hpux (bzw. linux_x86_64)
LICENSE
LOCAL_INSTALL
Xen_sup

Führt man nun in LOCAL_INSTALL die „./omnisetup.sh -IS“ aus, bekommt man den Hinweis, dass man doch das jeweils andere Installationspaket verwenden solle.

Lösung:
Beide Installationspakete entpacken und dann das Verzeichnis ‚hpux‘ in den entpackten Linux-Installationsordner kopieren.
Die Verzeichnisstruktur sieht dann so aus:
DOCS
HPSW_Integrations
hpux
linux_x86_64
LICENSE
LOCAL_INSTALL
Xen_sup

Also in der Befehlsübersicht:

Ein leeres Verzeichnis erstellen, in das die Installationen hineinkommen:
mkdir TD586-15005

Linux-Paket entpacken mit:
tar -xvzf ESD,_HP_DP_7.00_for_Linux_TD586-15005.tar.gz -C TD586-15005

… und nun das HP-UX Paket auspacken (beachte das hpux – wir benötigen nur diesen einen Ordner):
tar -xvzf ESD,_HP_DP_7.00_for_HP-UX_TD586-15004.tar.gz hpux
und in den anderen Ordner schubsen:
mv hpux TD586-15005

danach in den LOCAL_INSTALL wechseln (ich stehe lieber schon im Verzeichnis):
cd TD586-15005/LOCAL_INSTALL/
chmod +x *.sh
und die Installation ausführen:
./omnisetup.sh -IS

Versionscheck:
/opt/omni/bin/omnicc -ver
Ergebnis:
HP Data Protector A.07.00: OMNICC, internal build 72, built on Sat Mar 17 12:55:28 2012

Alles ist gut!