Schlagwort-Archive: Backup

Alle Einträge, die mit einer Datensicherung zusammenhängen.

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!

SQL 2005: Systemplatte voll – große modellog.ldf Datei

Problem:

Auf einem SQL 2005 Server läuft die Systemplatte C: voll. Die Anwendungs-Datenbanken liegen aber auf anderen Plattenbereichen.

Lösung:

Per TreeSizeFree (Portable) habe ich mal die dicksten Dateien anzeigen lassen.
Bei zwei Instanzen gab es sehr große „modellog.ldf“ Daten.

Also erst einmal eine Vollsicherung der model gemacht.

Danach noch einmal

BACKUP LOG MODEL WITH TRUNCATE_ONLY

und

ALTER DATABASE model SET RECOVERY SIMPLE
GO
USE model
GO
DBCC SHRINKFILE(‚modellog‘, 2)
GO

Damit war der Spuk vorerst vorbei.
Die ‚model‘ Datenbanken sind jetzt unter genauerer Beobachtung.
Das Wiederherstellungsmodell ’simpel‘ ist bei mir kein Problem, da ich ohnehin für jede Datenbank noch Einstellungen vornehme. Da sollte es einem schon auffallen, wenn es da keine Transaktionsprotokollsicherung gibt. 🙂

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!

Automatisches Backup einer SQL Server 2008 Express Datenbank auf Windows Server 2008 R2

In einem anderen Artikel hatte ich beschrieben, wie man eine SQL-Express auf einem Windows Arbeitsplatzrechner sichert.

Nach einer Softwareinstallation auf einem Windows 2008 R2 Server musste nun dafür gesorgt werden, dass auch dort die SQLExpress Datenbanken gesichert werden.

1. Backup Ziel erstellen:
In meinem Fall habe ich einfach einen Ordner C:\Backup\MSSQL-Express\ angelegt.
Dieser wird dann vom Backup-Tool einfach als File-Backup weggesichert.

2. SQLCMD als Helferlein 🙂
Im Gegensatz zur vorherigen Beschreibung ist in diesem Fall keine Softwareinstallation mehr notwendig! Der Server bleibt also ’sauber‘.
In der Beschreibung der Software war lediglich angegeben, dass eine SQLExpress-Datenbank verwendet wird. Aber für das Backup müsste man schon wissen, welche Datenbanken dort existieren:

Konsole (cmd.exe) als Administrator ausführen und folgendes testen:
C:\Program Files\Microsoft SQL Server\100\Tools\Binn>sqlcmd -S SERVERNAME\SqlExpress
Damit verbindet man sich erst einmal mit dem SQL-Express Server und erhält eine Eingabeaufforderung die mit ‚1>‘ beginnt.
Dort erfragen wir jetzt die vorhandenen SQL-Datenbanken. Nach der ersten Zeile bitte einmal ENTER drücken, um in der zweiten Zeile dann mit ‚Go‘ das Kommando auszulösen::
1> SELECT name from sys.databases
2> Go

Ergebnis:name
—————————————————————————-
master
tempdb
model
msdb
SOPHOS521
SophosSecurity
SOPHOSPATCH52
SOPHOSENC52

Okay:
Die Syntax:
„C:\Program Files\Microsoft SQL Server\100\Tools\Binn\SQLCMD.EXE“ -E -S <SERVERNAME>\<SQLEXPRESSERVERNAME> -Q „BACKUP DATABASE <DATENBANKNAME> TO DISK='<BACKUPVERZEICHNIS>'“

Jetzt das Backup manuell testen:
„C:\Program Files\Microsoft SQL Server\100\Tools\Binn\SQLCMD.EXE“ -E -S MEINSERVER\SQLExpress -Q „BACKUP DATABASE SOPHOS521 TO DISK=’C:\Backup\MSSQL-Express\SOPHOS521.bak'“

Jetzt sollte sich im Backup-Verzeichnis eine Datei namens SOPHOS521.bak befinden.
Die Dateinamen muss man natürlich anpassen. 🙂

UZI – we do it automatic:
Also Aufgabenplaner auf, Einfache Aufgabe erstellen:
Name: SQL-Backup
Beschreibung: Backup der SQLExpress Datenbanken
Sicherheitsoptionen: Unabhängig von der Benutzeranmeldung ausführen + mit höchsten Berechtigungen ausführen + Ausgeblendet Konfigurieren für WinServer 2008
Trigger: Täglich 21:00 Uhr
Aktionen:
Programm starten: „C:\Program Files\Microsoft SQL Server\100\Tools\Binn\SQLCMD.EXE“
Argumente hinzufügen: -E -S SERVER\SQLExpress -Q „BACKUP DATABASE SOPHOS521 TO DISK=’C:\Backup\MSSQL-Express\SOPHOS521.bak'“

Das sollte es schon gewesen sein. Hat man mehrere Datenbanken, kann man übrigens eine  bestehende Aufgabe exportieren, in einem Texteditor anpassen und dann wieder importieren. So muss man die Jobs nicht immer komplett neu einrichten, sondern muss nur den Datenbanknamen und den Namen der Backupdatei anpassen.

Was tun, wenn die Instanz nicht SQLExpress heißt?
In einigen Fällen kann es sein, dass ein Softwarehersteller eine eigene SQLExpress Instanz anlegt, die natürlich dann auch einen beliebigen Namen hat.
Keine Ahnung? Kein Problem:
Einfach die Dienste auf dem Server anzeigen lassen: Start -> services.msc oder START -> Verwaltung -> Dienste
Dort gibt es einen SQL Server Dienst, der einen Namen in Klammern stehen hat.
Z.B. „SQL Server (SOPHOS)“
Dieser Name in den Klammern ist der Instanzname. Also in dem Fall SOPHOS – SERVERNAME\SOPHOS.

ZUSATZ:
Wenn man die .bak Datei bei jedem Lauf überschreiben will, muss man an die Argumente noch ein ‚WITH INIT‘ anfügen.
Also:
Programm starten: „C:\Program Files\Microsoft SQL Server\100\Tools\Binn\SQLCMD.EXE“
Argumente hinzufügen: -E -S SERVER\SQLExpress -Q „BACKUP DATABASE SOPHOS521 TO DISK=’C:\Backup\MSSQL-Express\SOPHOS521.bak‘ WITH INIT“

 

Automatisches Backup einer SQL Server 2008 Express Datenbank

Problem:
Ein Problem der SQL Express Varianten ist, dass man mit Bordmitteln zunächst einmal kein automatisches Backup erstellen lassen kann, da der gesamte Wartungsbereich, den man aus „echten“ SQL-Servern kennt, in der Express Variante fehlt.

Lösung:

Benötigte Software:
Microsoft® SQL Server® 2008 Management Studio Express
Aufgabenplanung (Systemsteuerung -> Verwaltung -> Aufgabenplanung) oder über START –> taskschd.msc

Vorgehensweise:
Zuerst startet man das SQL Server Management Studio Express und erstellt eine manuelle Sicherung über „Rechtsklick auf die Datenbank“ -> Tasks -> Sichern.
Dort werden alle notwendigen Einstellungen angepasst, wie z.B. das Sicherungsziel.
Das Backup wird aber noch NICHT gestartet.

Im nächsten Schritt klickt man nun auf „Skript“ (oben in der Mitte), um sich das SQL-Skript zu diesem Sicherungsjob anzeigen zu lassen.
Das sieht dann etwa so aus:

SQLQuery-WFDB.sql

BACKUP DATABASE [WFDB] TO  DISK = N’D:\Backup\MSSQL-Express\WFDB.bak‘ WITH NOFORMAT, NOINIT,  NAME = N’WFDB-Vollständig Datenbank Sichern‘, SKIP, NOREWIND, NOUNLOAD,  STATS = 10
GO

Dieses Skript muss nun an einem gut erreichbaren Ort abgespeichert werden.
Als Test kann man das Backup einmal laufen lassen.
Vorsicht: Das Backup Ziel muss für den Benutzer, der den SQL-Dienst ausführt, beschreibbar sein. Das kann man prüfen, indem man sich in der Dienste-Ansicht auf dem Karteireiter ‚Anmelden‘ anzeigen läßt, unter welchem Acount der SQLEXPRESS ausgeführt wird. Bei mir war es das Konto ‚Netzwerkdienst‘.
Diesem Konto muss man auf das Backup-Ziel noch Schreibrechte eintragen.

Jetzt öffnet man die Aufgabenplanung und fügt eine neue ‚einfache Aufgabe‘ dazu.

Aktion: „Programmstarten“
Programm/Skript: „C:\Program Files\Microsoft SQL Server\100\Tools\Binn\SQLCMD.exe“
Argumente hinzufügen (optimal): -S SERVERNAME\SQLEXPRESS -i „D:\Scripte\SQLQuery-WFDB.sql“

Jetzt nur noch einstellen, wann der Task laufen soll und schon ist man fertig.
Sollte das Backup-Ziel augf einem Netztlaufwerk liegen, sollte man einen Domänen-Benutzer für die Ausführung des SQL-Dienstes verwenden.