the Sky is the Limit
Erst kürzlich hatte ich das Betaprogramm der kostenlosen Backuplösung für PCs von Veeam angekündigt. Jetzt ist diese für Betatester verfügbar. Ich schildere in diesem Beitrag die Installation und die ersten Tests.
32- and 64-bit Versionen der folgenden Betriebsysteme:
Changed-Block-Tracking (CBT) ist eine sehr nützliche Funktion, um beispielsweise einer Backup Software mitzuteilen, welche Blöcke sich seit einen Zeitpunkt [t] verändert haben. Somit können gezielt diese Blöcke gesichert werden, was natürlich erheblich Zeit spart.
Genau in dieser CBT Funktion gibt es einen Fehler, der lange unerkannt blieb. Er tritt nach Angaben von VMware dann auf, wenn eine vDisk über 128 GB vergrößert wurde.
VMware und Veeam empfehlen, nach einer Vergrößerung der vDisk einer VM, einen CBT reset durchzuführen. Beim nächsten Durchgang von Veeam Backup wird CBT wieder aktiviert und arbeitet korrekt.
Alternativ kann auch ein PowerCLI Skript verwendet werden, das CBT im laufenden Betrieb zurücksetzt. Das Skript resetCBT wurde vom Veeam Support erstellt. Der Aufruf erfolgt mit Parametern. Es funktioniert nur bei eingeschalteten VMs.
Verwendung auf eigen Gefahr !
-vcenter: <FQDN vCenter>
-vms: Liste der VMs durch Komma getrennt (keine Leerzeichen!)
resetCBT.ps1 -vcenter example.vcenter.local -vms "vmname1,vmname2,vmname3,vmname4"
Möglicherweise löst VMware das Problem in ESXi5.5 mit aktuelltem Patchlevel (2143827) automatisch (?). Nach der Vergrößerung einer vDisk meldete Veeam Backup (v7) folgende Warnung:
Wurde von Seite des ESXi Servers das CBT automatisch deaktiviert?
Veeam hat einen Hotfix für B&R Version 7 veröffentlicht. Er besteht aus 4 DLL Dateien, die getauscht werden müssen. Voraussetzung ist Veeam Backup and Replication 7.0.0.871 (patch 4).
Gelegentlich ist es notwendig, die Anwendung Veeam Backup & Replication auf ein anderes System oder eine andere Partition zu migrieren. Die einfachste Methode ist folgende:
Diese Methode ist einfach und funktioniert sehr zuverlässig. Die Sicherung enthält alle Angaben zu Backupjobs, Historie, Infrastruktur, etc.
Sollte es aus irgendwelchen Gründen notwendig sein, die bestehende Datenbank zu erhalten, so muss man einige Hürden umgehen. Der Ablauf ist zunächst gleich wie oben geschildert:
Hier wählt man die bereits existierende Instanz des SQL Servers aus. Im Beispiel unten war der Hostname = Veeam und ebenso der Instanzname.
Ganz so einfach ist es dann doch nicht. 😉 Die Installation erfolgt mit der ungepatchten Version, während die bestehende Datenbank bereits einige Patchzyklen hinter sich hat.
Hierfür gibt es einen Lösungsvorschlag in der Veeam KB. Mit dem SQL Management Studio verbindet man sich auf die Instanz der bestehenden Veeam Datenbank und ermittelt die aktuelle Version.
Select current_version from [VeeamBackup].[dbo].[Version]
Im Beispiel war das Ergebnis der Abfrage 1205 (Veeam 7.0.0.871 Patch 4). Bevor man mit der Neuistallation beginnen kann, muss zunächst in der Datenbank die Versionsnummer heruntergesetzt werden. Diese Nummer ist Abhängig von der zu installierenden Basisversion. Für Veeam Backup 7.0.0.690 ist dies 1179.
Use VeeamBackup UPDATE [Version] SET current_version = 1179
Danach lässt sich das Setup durchführen. Anschliessend muss die Applikation wieder auf den ursprünglichen Patchlevel gehoben werden.
Diese zuvor beschriebene Methode ist nicht so reibungslos, wie sie hier erscheinen mag. Mich kostete dies mehrere Anläufe, wesewegen ich die Methode mit dem Import der Konfiguration bevorzuge. Dabei bleibt die Datenbank Instanz erhalten. Man muss jedoch die bestehende Veeam Datenbank löschen, da es ansonsten zu Störungen beim Import kommen kann. Der Ablaufplan ist am Anfang dieses Artikels geschildert.
Veeam Support – Installation Fails with Patched Database
Im Storage Area Network SAN gibt es mehrere Wege, den Zugriff auf Speichervolumes zu steuern. Zunächst kann man über Zoning festlegen, welche Initiatoren welche Targets sehen dürfen. Unterhalb des Targets werden Zugriffe auf LUNs in der Regel mittels LUN-Mapping gesteuert. Meist gibt es drei Optionen:
Auf diese Weise lässt sich der Zugriff unterschiedlicher Hosts kanalisieren. Beispielsweise Lese- und Schreibzugriff (RW) für ESXi Hosts und reinen Lesezugriff (readonly) für den Backupserver. Somit kann verhindert werden, daß dieser versehentlich Signaturen auf VMFS LUNs schreibt. Man kann dies zwar unterbinden, aber ein readonly LUN Mapping ist da die bessere Wahl.
Zur Erhöhung der Sicherheit wollte ich kürzlich Volumes auf einem Eternus DX Storage System als readonly einem Host bereitstellen. In der GUI fand ich keine Einstellung hierfür (was nichts heissen muss), auch das Handbuch hatte keinen Hinweis darauf. Letztlich blieb mir nur die Anfrage beim FTS Support. Der Storage Support in Paderborn teilte mir mit, was ich bereits befürchtete:
Ein Readonly Zugriff ist für ausgewählte LUNs und Hosts nicht möglich.
Schade. Dies ist ein Rückschritt im Vergleich zu den ausgemusterten Storages der SX Serie.