Veeam Backup und IBM TSM Integration

Sponsored by 

Integration der 

herausragenden 

Virtualisierungs- 

Backup-Funktionen 

von Veeam Backup 

& Replication in eine 

bestehende IBM TSM 

Umgebung 

Andreas Neufert 

VMware vExpert, Veeam MVP

1 Einleitung 3 

2 Kurzfassung 3 

3 Zielgruppe 4 

4 Voraussetzungen 4 

4.1 Software Voraussetzungen: 4 

5 Komponenten Übersicht 5 

5.1 Veeam Backup & Replication 5 

5.2 VMware vSphere 5 

5.3 IBM® Tivoli® Storage Manager 5 

6 Was für Vorteile gewinnen wir, wenn wir Veeam Backup & Replication in IBM® TSM integrieren? 6 

6.1 Legacy Backup über Agenten 6 

6.2 vStorage API 6 

6.3 Applikations- und Datenkonsistenz 7 

6.4 VMware VM Snapshot, Change-Block-Tracking, Datentransfer aus VMware 8 

6.5 Deduplizierung und Komprimierung 10 

6.6 Speicherung der Daten in transportable Backupfiles 11 

6.7 Replikation 12 

6.8 Teilung der Administration, des Scheduling und der Datenströme 13 

6.9 Aufbewahrungsfristen der Backups 14 

7 Die Backup & Replication Paradedisziplin: Schnelle und zuverlässige Wiederherstellung 14 

7.1 Wizard basierte Wiederherstellung einzelner Dateien 15 

7.2 Windows One-Click-File-Restore 15 

7.3 Weltweit zentralisiert portalbasierte Wiederherstellung von Windows Files für den zentralen User-Help-Desk 16 

7.4 Instant Restore 16 

7.5 Universelle Objektwiederherstellung (U-AIR) 17 

7.6 SureBackup 18 

8 Benötigte Veeam und IBM® TSM Infrastruktur 19 

9 Einrichtung der Veeam und IBM® TSM Infrastruktur 20 

9.1 Veeam Backup & Replication Einrichtung 21 

9.2 IBM® TSM Client Einrichtung 31 

10 Aufbewahrungsfristen & Scheduling 32 

10.1 Veeam Backupfiles 32 

10.1.1 „Incremental with Syntetic Full“ 32 

10.1.2 „Reverse Incremental“ 33 

10.1.3 Incremental - Transform previous full backup chain into rollbacks 33 

10.2 Backup & Replication Aufbewahrungsfrist für Backups 33 

10.2.1 Restorepoints to keep on disk. 34 

10.2.2 Scheduler 34 

10.2.3 Manuelles starten des Jobs 35 

10.2.4 „Incremental“ Backupverfahren 35 

10.3 Grundsätzliche Erläuterung der TSM Copygroup Parameter 35 

10.3.1 „verexist“ 35 

10.3.2 „verdelete“ 35 

10.3.3 „retextra“ 35 

10.3.4 „retonly“ 36 

10.4 Beispiel für die zugehörigen TSM ManagementClass und CopyGroup Befehle 36 

11 Zusammenspiel Backup & Replication Scheduler und TSM Scheduler 36 

12 Umsetzungsbeispiele Übersicht 37 

12.1 Übersicht zu Beispiel 1: 37 



12.4 Details zu den Beispielen 1-3: 38 

12.5 Hinweise zum Beispiel 1 39 

12.5.1 Backupzeitfenster von TSM 39 

12.6 Hinweise zum Beispiel 2 39 


12.6.2 TSM Scheduler 40 

12.7 Hinweise zu Beispiel 3 40 


12.7.2 Remote Powershell 40 

13 Restore 41 

13.1 Restore mit Veeam Backup & Replication von Disk 41 

13.2 Restore von älteren Wiederherstellungspunkten die nur noch in einem TSM (Tape) Pool liegen 41 

13.3 Restore der kompletten Veeam Backup & Replication Umgebung 42 

14 Funktionstests und Aufbewahrungsprüfungen 43 

15 Fazit 43 

Über den Autor 44 

Über Veeam Software 44

Integration der herausragenden Virtualisierungs-Backup-Funktionen von Veeam Backup & Replication 

1 Einleitung 

Dieses Whitepaper gibt einen Überblick über Disaster- und Data-Recovery 

Lösungen für VMware Umgebungen und zeigt deren Einsparpotentiale, 

speziell in Zusammenarbeit mit dem IBM® Tivoli® Storage Manager 

(TSM) auf. Es werden hierbei die dafür notwendigen spezifischen Anforderungen 

an die Skalierbarkeit, technische Hintergrundinformationen sowie 

drei Beispiele aus der Praxis dargestellt. 

2 Kurzfassung 

IT-Abteilungen stehen heute mehr denn je unter dem Druck Kosten reduzieren 

zu müssen, wobei gleichzeitig eine immer höhere Verfügbarkeiten 

der Systeme zu erwartet wird. Es sind bewährte Konzepte gefragt, die innovativ 

eingesetzt werden, um Budgets sowohl im personellen als auch im 

finanziellen Bereich zu entlasten. 

Immer häufiger greifen Unternehmen auch für Ihre wichtigsten Tier1 Applikationen 

zur Virtualisierung, um neben der Kostenersparnis für Hardware, 

Energie, Kühlung und Administration auch mehr Flexibilität und eine 

schnellere Wiederherstellung im Notfall zu gewinnen. 

In der Regel werden neue Server immer als virtuelle Server implementiert. 

“VM Backup is the new normal” - Gartner 

Aufgrund der entstehenden Herausforderung, aus der Virtualisierung 

riesige Datenmengen und eine große Anzahl an Servern sichern zu müssen, 

ist es essentiell notwendig, das beste Backup- und Wiederherstellungstool 

einzusetzen, welches auf dem Markt existiert. Veeam Software bietet 

mit seinen im Virtualisierungs-Backupmarkt herausragenden Funktionen 

genau die hierfür notwendigen Mehrwerte und Alleinstellungsmerkmale. 

Ein Highlight ist z.B. die Möglichkeit einen Server und Benutzer-Dienst unabhängig 

von der Datenmenge innerhalb von einer Minute plus Betriebssystemstart 

wieder zur Verfügung zu stellen. Diese Funktion existiert bereits 

als Bestandteil von Veeam Backup & Replication seit über 1,5 Jahren. 

Um bestehende Infrastruktur und Prozesse für das Auslagern von Backupdaten 

weiter nutzten zu können, kann Veeam Backup & Replication in den 

bestehenden IBM® Tivol Storage Manager (TSM) integriert werden. 

3


Abbildung 001: 

Veeam Backup & Replication als Erweiterung zu IBM® TSM 

Die hier dargestellten Verfahren sind unter Berücksichtigung des Best- 

Performance- und Best-Practices-Aspekts zu sehen, und stellen nur einen 

kleinen Teil der Möglichkeiten und dem Funktionsumfang der Veeam und 

IBM ® Produkte dar. 

3 Zielgruppe 

Kunden, potentielle Neukunden und Partner die nach einer Möglichkeit 

suchen Veeam Backup & Replication in eine bestehende IBM® Tivoli® 

Storage Manager (TSM) Lösung zu integrieren und Backupdaten dorthin 

auszulagern. 

4 Voraussetzungen 

Dieses Dokument richtet sich an eine Gruppe aus technischen Entscheidern, 

VMware-, Veeam- sowie IBM® TSM Administratoren mit dem 

entsprechenden Hintergrundwissen. 

4.1 Software Voraussetzungen: 

• Veeam Backup & Replication v6.1 (oder neuer). 

• IBM® Tivoli® Storage Manager 5.x (oder neuer) 

• VMware vSphere 4 (oder neuer) / Standalone ESX(i) 4 (oder neuer) 

IBM® Tivoli® Storage Manager for Virtual Environment wird für die in diesem 

Dokument dargestellte Zusammenarbeit mit Veeam Backup & Replication 

nicht verwendet. 

In diesem Dokument werden verschiedene Funktionen von IBM® Tivoli® 

Storage Manager und IBM® Tivoli® Storage Manager for Virtual Environment 

erwähnt. Die beschriebenen Funktionen basieren hierbei auf der 

jeweiligen Version 6.3 . Die Version 6.3 ist jedoch nicht zwingend für die 

Zusammenarbeit wie in diesem Dokument dargestellt notwendig. 

4


Dieses Dokument geht zwar nicht direkt darauf ein, es ist jedoch möglich, 

das beschriebene Vorgehen auch für Hyper-V und Hyper-V Cluster umzusetzen. 

5 Komponenten Übersicht 

Abbildung 002: Backup Infrastruktur 

5.1 Veeam Backup & Replication 

Veeam Backup & Replication bietet schnelle und zuverlässige Backup und 

Wiederherstellung von VMware vSphere und Mircrosoft Hyper-V Umgebungen 

und Daten. Backup und Replizierung werden hierbei in einer einzigen 

Lösung zusammengeführt. Veeam Backup & Replication nutzt mit der 

Veeam vPower-Technologie die Vorteile der Virtualisierung, um Datensicherung 

und deren Wiederherstellung neu zu definieren und setzt dabei 

neue Maßstäbe. 

5.2 VMware vSphere 

VMware vSphere stellt Rechenzentrumsvirtualisierung für x86-64 basierte 

Serversysteme zur Verfügung. Sie versetzt Anwender in die Lage, geschäftskritische 

Anwendungen zuverlässig auszuführen und schneller auf 

geschäftliche Anforderungen zu reagieren. 

5.3 IBM® Tivoli® Storage Manager 

Mit dem IBM® Tivoli® Storage Manager (TSM) bietet IBM® eine ganze 

Suite von Dataprotection Lösungen für fast alle Systeme in einem Rechenzentrum. 

Unter anderem werden die Backupdaten auf Tape-Systeme 

vorgehalten und das Verbringen einzelner Tapes zu Offsite-Lokationen 

organisiert. 

5


Mit dem TSM Client können Full Sicherungen von VMware VMs erstellt 

werden. 

Der IBM® Tivoli® Storage Manager für Virtual Environments (TSM VE) 

stellt darüber hinaus inkrementelle Sicherungen von VMs zur Verfügung. 

Er wird jedoch für die in diesem Dokument dargestellten Backupverfahren 

nicht verwendet. 

6 Was für Vorteile gewinnen wir, wenn 

wir Veeam Backup & Replication in 

IBM® TSM integrieren? 

Rechenzentren mit VMware Infrastrukturen sehen sich einem immensen 

Wachstum Ihrer virtuellen Infrastruktur gegenüber, da die Unternehmen 

immer mehr Anwendungen benötigen und diese bzw. alle neuen Systeme 

in der Regel immer auf virtualisierten Servern aufgesetzt werden. 

Dies gilt ebenfalls für geschäftskritische bestehende Applikationen die ebenso 

in die Virtualisierung verlagert werden, um deren Vorteile nutzen zu 

können. 

6.1 Legacy Backup über Agenten 

Bestehende Backupkonzepte, die auf Agenten in virtuellen Servern basieren, 

können den heutigen Anforderungen an Wiederherstellungsflexibilität 

und Wiederherstellungszeit nicht mehr gerecht werden. Auf herkömmlich 

installierten Serversystemen können die freien Ressourcen für die 

Backupprozesse genutzt werden (Indizierung und Prüfung auf geänderte 

Dateien). In der Virtualisierung teilen sich aus Wirtschaftlichkeitsgründen 

diese freien Ressourcen mehrere virtuelle Server. Werden Backups gleichzeitig 

angestoßen kommt es oftmals allein durch das Scannen nach 

geänderten Files zur Überlastung der Systeme und Backupprozesse verzögern 

sich dadurch maßgeblich. 

Agenten belegen selbst im Stillstand auf jedem System einige Ressourcen, 

welche sich durch die Menge an VMs zu einem hohen Kostenfaktor 

für zusätzliche Hardware und Softwarelizenzen aufsummieren. Weiterhin 

müssen Sie von Personal verwaltet und gepflegt werden. 

Bei der eigentlichen Datenübertragung teilen sich die Agenten die physischen 

Netzwerkkarten der Hostsysteme, was oftmals ebenfalls einen 

Engpass darstellt. 

6.2 vStorage API 

VMware vSphere stellt mit der vStorage API eine standardisierte Schnittstelle 

zur Verfügung, um Daten aus den Hostsystemen auszulesen. Hierbei 

gibt es Backupmodi die auf den Hostsystemen gezielt und steuerbar Last 

6


verursachen oder die Daten ohne Last für die Hostsysteme direkt aus dem 

SAN oder iSCSI Netzwerk abziehen. 

6.3 Applikations- und Datenkonsistenz 

Abbildung 003: Backup & Replication – Backup VM Konsistenz 

Betriebssysteme, Datenbanken und Applikationen lagern, um performanter 

arbeiten zu können, Daten in den Arbeitsspeicher und andere Caching- 

Mechanismen aus. Würde man ein Backup der Festplatten Volumes von 

diesem geöffneten Status erstellen, währen die im Arbeitsspeicher ausgelagerten 

Daten nicht enthalten und es käme beim Restore zu Problemen 

bzw. zum Datenverlust. 

Um diesem Worst-Case-Szenario zu begegnen, gibt es z.B. von VMware 

das VMware Tools Quiescence. VMware bietet hierbei eine Möglichkeit, 

für eine limitierte Anzahl an Betriebssystemen, Applikationen und einigen 

anderen Voraussetzungen, mit den Applikationen zu kommunizieren um 

z.B. Applikationen, Datenbanken und das Filesystem in einen konsistenten 

Status zu versetzen. Diese Funktion wird unter anderem auch von IBM® 

Tivoli® Storage Manager for Virtual Environments und anderen Virtualisierungsbackuptools 

verwendet. Neben den VMware Tools werden hierfür 

keine Agenten verwendet. 

Veeam schließt diese offene Lücke und geht noch einen Schritt weiter. Mit 

Backup & Replication wird die eigene VSS Funktion genutzt, um ebenfalls 

einen konsistenten Status der Applikationen herzustellen. Anschließend 

werden nach Microsoft Best-Practices für die Applikationen bestimmte 

Schalter gesetzt, welche nach einem Restore die Applikationen in den 

vorgesehenen Restore Modus versetzen. Weiterhin kann Veeam Log Files 

der Datenbanken und Applikationen verarbeiten (commit). 

Für den Bereich Linux und Applikationen unter Windows, die keine VSS 

Writer besitzen, bietet Veeam die Möglichkeit Pre- und Post-Skripte auszuführen. 

Je nach Umgebung kann dies sogar ohne Netzwerkzugriff erfolgen, 

um z.B. VMs im DMZ-Netzwerk zu sichern, ohne dass eine Möglichkeit 

besteht auf das Backupnetzwerk zuzugreifen. 

7


Somit ist es mit Veeam Backup & Replikation möglich, ohne zusätzliche 

Applikationsagenten (wie z.B. dem TDP for Databases) Applikationen 

und Datenbanken korrekt zu sichern. Durch die Veeam-Agentless Technologie 

sparen Sie sich und Ihren Administratoren eine Menge Zeit und 

Kopfschmerzen, die Sie normalerweise bei der Pflege und Installation 

der Agenten hätten. Weil Applikationen nicht separat gesichert werden 

müssen (doppelter Datenbestand), wird darüber hinaus noch Backup- 

Speicherplatz eingespart. 

6.4 VMware VM Snapshot, Change-Block- 

Tracking, Datentransfer aus VMware 

Abbildung 004: Backup & Replication – Datenabzug beim Backup/Replikation 

Der hergestellte konsistente Status wird durch das Erzeugen eines VM 

Snapshots innerhalb von VMware festgehalten und anschließend (der 

konsistente Status) wieder aufgelöst. Die Daten können von diesem eingefrorenen 

Stand (Snapshot) über das normale Netzwerk (langsam), per 

Mapping an einen virtuellen (Proxy) Backupserver oder direkt aus dem 

SAN Netzwerk (iSCSI/FibreChannel) per physischem Proxy-Backupserver 

ausgelesen werden. Der direkte Transfer der Daten aus dem SAN belastet 

die VMware Host Systeme nicht und ist in größeren Umgebungen zu 

bevorzugen. Nach dem eigentlichen Backup wird der VM Snapshot wieder 

aufgelöst. 

Da die Festplatten nur als Container im Blockzugriff gesehen werden (so 

wie VMware die Daten direkt auf den Disks speichert), und keine Backup-Software 

in der Lage ist das Filesystem zusätzlich zur laufenden VM 

laden zu können, ist es unmöglich Dateiänderungen feststellen zu können. 

Somit steht eigentlich nur jedes Mal der volle Abzug der Festplat- 

8


tencontainer zur Verfügung, wenn nicht VMware eine zusätzliche Funktion 

namens Change-Block-Tracking eingeführt hätte. Hierbei hält VMware in 

einer Datei fest, welche Blöcke sich auf den Datenspeichern verändert haben. 

Backup-Software kann diese Informationen nutzen, um nur die geänderten 

Blöcke die VMware an die Disks übertragen hat, auszulesen und 

abzuziehen. 

Veeam hat für Hyper-V ein eigenes Hyper-V Clusterfähiges Change-Block- 

Tracking entwickelt, um auch hier nur die geänderten Blöcke mit Backup & 

Replication sichern zu können. 

Ein Beispiel für den Nutzen von Change-Block-Tracking: Sie haben eine 

große Filmdatei mit 8GB in einer Datei. Jetzt öffnen und speichern Sie die 

Datei ohne wirklich Änderungen vorzunehmen. Herkömmliche Agenten 

basierte Backup-Software würde erkennen, dass die Datei sich geändert 

hat und die vollen 8GB sichern. Jedoch auf Blockebene betrachtet, wird 

nur die Information mit dem Zeitstempel in neuen Blöcken auf das Disksystem 

übertragen und im Change-Block-Tracking festgehalten. Dies sind 

in unserem Fall nur wenige KB oder MB, die dann als Backup mit minimaler 

Datenübertragung gesichert werden können. 

Nachteil dieses Backupverfahrens innerhalb von VMware ist, dass solange 

der VM-Snapshot besteht, die Änderungen die sich seither ergeben haben 

in einen separaten Bereich abgelegt werden. Wird der Snapshot aufgelöst, 

sind diese aufgelaufenen Daten portionsweise innerhalb von ganz kurzer 

Zeit in den eigentlichen Datenbereich zu schreiben. Dies bedeutet sehr 

viele Random-Writes für das Disksubsystem. Dieser Vorgang profitiert also 

von kurzen Latenzen und Zugriffszeiten der Storagesysteme. Kommt es 

hierbei zu Verzögerungen im Storagesystem, können die betroffenen VMs 

kurzzeitig einfrieren (meist nur im Millisekunden Bereich). Wird z.B. ein 

sehr großes Datenbanksystem (TB) mit sehr vielen Änderungen und damit 

einer hohen Belastung der Storagesysteme in der Zeit des VM Snapshots 

gesichert, kann es dazu führen, dass VMware beim Auflösen des Snapshots 

mit dem Schreiben der Änderungen nicht nachkommt und somit der 

Snapshot nicht wieder aufgelöst werden kann. Sind die Storagesysteme zu 

stark belastet oder nicht mit aktuellen Patches ausgestattet, kann es auch 

vorkommen, dass ein Server etwas länger als im Millisekunden Bereich 

einfriert, was die Applikationen dann bemerken und darauf reagieren. 

Viele Backup-Hersteller übertragen immer wieder auch innerhalb der 

Virtualisierung trotz Change-Block-Tracking ein Full-Backup der Datenbestände. 

Dies führt dazu, dass sich neben der eigentlichen erhöhten Belastung 

durch den Datentransfer auch das Backupzeitfensters verlängert. 

Snapshot bleiben dadurch sehr lange bestehen und sind deshalb anfälliger 

für das „Snapshot-Commit-Problem“. 

Veeam löst dieses Problem elegant, in dem nur einmalig die Daten als Full 

gesichert werden und zukünftig immer nur die geänderten Blöcke. Somit 

kann bei hoch belasteten Systemen innerhalb eines Wartungsfensters 

der Full-Datenbestand übertragen werden und anschließend während 

9


des normalen Betriebes nur die Änderungen. Oftmals können mit Veeam 

Backup & Replication dadurch Systeme gesichert werden, die sonst gar 

nicht mit Standard Virtualisierungsbackup-Methoden sicherbar sind. 

Für Hyper-V Backup werden Volume basierte Snapshots verwendet, diese 

kennen kein „Snapshot-Commit-Problem“. 

6.5 Deduplizierung und Komprimierung 

Neben der Komprimierung als Möglichkeit den Datenbestand zu verringern, 

nutzt Veeam Deduplizierung, um eine weitere Einsparung des 

Backup-Speicherplatzes zu erzielen. Backup & Replication verwendet hierbei 

eine Inline-Deduplizierung die innerhalb des Backupvorgangs die 

Deduplizierung ausführt. Teile der Deduplizierung erfolgen hierbei sogar 

schon auf dem Proxy (welcher die Daten aus VMware ausliest) und verringert 

den Datenbestand bereits, bevor dieser überhaupt über das Netzwerk 

übertragen werden muss. 

Durch die maßgebliche Reduzierung des Datenvolumens der Backup-Files 

durch Veeam können Disk-, Tape- und Lizenzkosten optimiert werden. 

Abbildung 005: Backup & Replication – Deduplizierung/Komprimierung 

10


6.6 Speicherung der Daten in transportable 

Backupfiles 

Mit Veeam Backup & Replication nimmt ein oder mehrere Repository 

Server die Daten von den Proxys entgegen und dedupliziert Sie zusätzlich 

noch innerhalb eines Jobs bevor diese auf Disk geschrieben werden. 

Unterstützte Diskmedien sind hierbei „Lokale Disks“, iSCSI, FibreChannel, 

CIFS oder NFS. Bei den letzten beiden genannten NAS basierten Systemen, 

muss der Protokolloverhead bei der Performanceplanung berücksichtigt 

werden. 

Veeam kann die gesicherten Daten in verschieden organisierten Backupdateien 

ablegen. Eine der Speichermethoden ist das klassische Full- und 

Incremental-Backup Verfahren. Hierbei überträgt, wie bereits dargestellt, 

Backup & Replication nicht den kompletten Datenbestand bei einem Full- 

Backup, sondern baut aus den gesicherter alten Backupfiles und dem neu 

hinzugekommenen Datenbestandsdelta ein sogenanntes „Synthetic Full“. 

Veeam verwendet dieses erprobte Verfahren schon seit vielen Jahren in 

seinen Produkten. 

Um Diskkapazitäten einzusparen, kann Veeam dieses Verfahren auch 

täglich ausführen und erzeugt dabei vom aktuellen Datenbestand jeweils 

ein (Synthetic) Full und speichert ältere Stände als sogenannte Reverse-Incremental-Files. 

Reverse-Incremental-Files entsprechen Incremental Files, 

nur dass diese sich nach vorne auf neue Backup-Stände beziehen, anstatt auf 

ältere, wie beim normalen Incremental-Backup-Verfahren. Dieses Verfahren 

bietet zusätzlich zur Deduplizierung und Komprimierung einen immensen 

Disk-Platzspareffekt, da nur ein Full-Backupfile je Job vorgehalten wird. 

Ein weiterer Vorteil dabei ist, dass ein sehr schneller Restore vom aktuellen 

Backupstand erfolgen kann, da dieser immer als Full-Backupfile vorliegt. 

Die erzeugten Backupfiles sind frei transportabel und in sich selbst zusammen 

mit der Backup & Replication Software nutzbar. Das heißt, Sie sind 

nicht von einer Datenbank abhängig und können somit ohne Probleme in 

IBM® TSM für die Aufbewahrung auf Band und auf Offline-Medien ausgelagert 

werden. Sind im extremen Notfall nur noch die Backupfiles auf 

Band vorhanden, können diese mit TSM auf Disk wiederhergestellt, ein 

neuer Veeam Backup & Replication Server installiert, die Backupfiles importiert 

und anschließend sofort eine Wiederherstellung gestartet werden. 

Der eigentliche Importvorgang dauert dank des Veeam Metadatenfiles in 

der Regel nur Sekunden. 

11


Abbildung 006: Backup & Replication – Schreiben der Backupfiles 

6.7 Replikation 

Neben klassischem Backup kann Veeam Backup & Replication die VMs 

auch auf einem weiteren ESX(i) Host als 1:1 Replik anlegen. Für die 

Übertragung der Daten werden dieselben Transfermethoden inklusive 

Applikationskonsistenz, Change-Block-Tracking und Deduplizierung 

verwendet. Eine Replik benötigt zwar mehr Platz als ein Backup, kann 

aber im Notfall ohne Performanceeinbußen sofort gestartet werden. 

Diese Funktion ist bereits in der Backup & Replication Standard-Lizenz 

enthalten und muss nicht separat lizenziert werden. 

Mit der Replikationsfunktion kann für das Desaster Recovery z.B. ein 

zweites Rechenzentrum aufgebaut werden oder VMs von Außenstellen 

in die Zentrale repliziert werden. Als Verbindung nutzt Veeam Backup & 

Replication hierfür günstige IP Leitungen inkl. eingebauter WAN Optimierung 

und arbeitet unabhängig von der eigesetzten Storage- und Serverhardware. 

Die Replikation in die VMware oder Hyper-V basierte Cloud ist 

ebenfalls möglich. 

12


Abbildung 007: Backup & Replication – Übersicht Replizierung 

Ein Beispiel wie Veeam Backup & Replication für den Aufbau eines Ausweichrechenzentrums 

verwendet werden kann, ohne dass die Storage-oder 

Serverhardware eine konsistente VMware Replikation oder Spiegelung 

bereitstellt, ist folgendes IBM® Whitepaper Beispiel: 

DR solution for IBM® SONAS hosted VMware virtual environment 

using Veeam 

http://www-03.IBM.com/support/techdocs/atsmastr.nsf/WebIndex/ 

WP102052 

6.8 Teilung der Administration, des Scheduling 

und der Datenströme 

Für die Organisation und Administration der Backups und Datenströme 

stehen mehrere Möglichkeiten in der Kombination mit IBM® TSM zur Verfügung. 

Ein typisches Szenario sieht vor, dass der TSM Administrator sich wie bisher 

um das Scheduling, die TSM Server, den Datenfluss zu TSM, das Error 

Reporting sowie die Offline Auslagerung von Backups mit Bordmitteln 

von TSM kümmert. In diesem Szenario nutzt der Virtualisierungs- und 

Applikationsadministrator die sehr einfach und intuitiv gehaltene Veeam 

GUI für die Organisation von Backupinhalten und den Restore. 

Über Post Job Commands kann auch Veeam Backup & Replication genutzt 

werden, um zentral das Scheduling und den Transport der Daten in TSM 

zu organisieren. 

13


Als Alternative zu den beiden zentralen Scheduling-Verfahren, kann Veeam 

auch das Sichern der Daten auf Disk übernehmen, während später 

durch den TSM-Administrator das Auslagern der Daten in TSM separat 

eingeplant wird. Dies kann zu einem Zeitpunkt erfolgen, in dem die 

TSM Server nicht durch Legacy-Backup belastet sind. Ebenso spielt die 

Geschwindigkeit in die Daten in das TSM geschrieben werden für das eigentliche 

Backup-Zeitfenster keine Rolle. 

Sollten Sie externe Scheduler wie z.B. den Tivoli® Workload Manager für 

die Steuerung der Backup verwenden wollen, ist dies ebenfalls möglich. 

Hierauf wird in diesem Dokument jedoch nicht weiter eingegangen. 

Ältere Backupstände die vielleicht nur auf Tape gelagert sind, können über 

den TSM Client auf Disk wiederhergestellt und in kurzer Zeit in Veeam 

Backup & Replication importiert werden und stehen dann wiederum für 

alle Backup & Replication Restore-Möglichkeiten zur Verfügung. 

6.9 Aufbewahrungsfristen der Backups 

Neben einer zeitlichen 1:1 Aufbewahrung der Daten in Veeam Disk Pools 

und TSM Tape Pools, gibt es die Möglichkeit, den schnellen Restore mit 

Veeam auf Disk für einen kurzen Zeitraum z.B. 30 Tage und die Langzeitaufbewahrung 

(z.B. 1 Jahr) auf TSM Tapes einzurichten. 

7 Die Backup & Replication Paradedisziplin: 

Schnelle und zuverlässige Wiederherstellung 

Neben den immensen technischen Vorteilen, Ressourcen- und Kosteneinsparungen 

beim Backup, kann Veeam on top noch mit seinen zuverlässigen 

und einfach zu bedienenden Wiederherstellungsmöglichkeiten punkten. 

Abbildung 008: Ein Backupstand mehrere Wiederherstellungsmöglichkeiten 

14


Von einem der Sicherungsstände, welcher als einzelnes Full Backup File 

oder einer Kombination aus Full und (Reverse-)Incremental Files besteht, 

können alle hier beschriebenen Wiederherstellungsverfahren verwendet 

werden. Es ist deshalb nicht erforderlich, für die Wiederherstellbarkeit von 

Applikationen weitere Backup-Files oder separate Jobs für Daten und Applikationen 

zu erzeugen. Dies spart somit Administrationsaufwand und 

ebenso Kosten für den nicht notwendigen doppelten Backup-Plattenplatz 

ein. 

Wiederherstellungsmöglichkeiten im Detail. 

7.1 Wizard basierte Wiederherstellung einzelner 

Dateien 

(Windows / Linux / Unix). Das Backupfile wird hierbei Veeam intern an einen 

Backupserver oder eine kleine Helper-VM (ohne dass das ganze Backupfile 

zunächst transferiert werden muss) gemapped. Es können Files und 

Ordner inkl. Windows- und Linux-Berechtigungen über einen Wizard mit 

einem Ordner-Dateibaum zurückgespielt werden. 

7.2 Windows One-Click-File-Restore 

Serverübergreifend kann über den Veeam Enterprise Manager (Web basierend) 

nach einem Filenamen gesucht werden. In den Ergebnissen kann 

dann mit der rechten Maustaste „Restore“ ausgewählt werden. Im Hintergrund 

wird das File wiederhergestellt. 

Abbildung 009: One-Click-File-Restore über die zentrale 

Enterprise Manager Weboberfläche 

15


7.3 Weltweit zentralisiert portalbasierte 

Wiederherstellung von Windows Files für den 

zentralen User-Help-Desk. 

Der User-Help-Desk kann hierbei nur Dateien an den Originalplatz 

zurückspielen und selbst nicht auf den Inhalt der Files zugreifen. Weiterhin 

kann die Wiederherstellung auf bestimmte Filetypen begrenzt werden. 

(nur Benutzerfiles wie z.B. Word Files, Excel Files, Videos und Bilder) 

7.4 Instant Restore 

Die herausragendste Wiederherstellungsfunktion von Veeam stellt innerhalb 

von 1 Minute, plus die Zeit in der das jeweilige Betriebssystem 

zum Booten benötigt, einen Server und dessen Dienste wieder 

für die Benutzer zur Verfügung. Diese Funktion operiert unabhängig 

vom verwendeten Betriebssystem des gesicherten Servers und dessen 

Datenmenge, da sich die Serversysteme direkt von den sich auf 

Disk befindlichen Backupfiles komplett starten lassen. Während die 

Benutzer arbeiten, können im Hintergrund per VMware Standardfunktion 

„Storage vMotion“ oder per Veeam „Quick Migration“ die Daten 

wieder an das ursprüngliche Storagesystem übertragen werden. 

Instant Restore hilft Ihnen effektiv, Produktionsausfälle im Wiederherstellungsfall 

auf eine Hand voll Minuten zu minimieren. 

Abbildung 010: Instant Restore 

16


7.5 Universelle Objektwiederherstellung (U-AIR) 

Server-Backups werden mit dem Universal Application Item Recovery (U- 

AIR) in einer abgeschotteten Umgebung (Veeam VirtualLab) mit der Instant 

Restore Technologie parallel zur Produktion gestartet. 

• Von dem auf diese Weise gestarteten Server können sowohl 

einzelne Files als auch Applikationsobjekte von jedem Betriebssystem 

und jeder möglichen Applikation wiederhergestellt werden. Die 

Möglichkeiten hierbei sind: 

- Nutzung von Betriebssystem-eigenen Kopierverfahren (z.B. Windows 

Explorer oder der Abgleich von Verzeichnissen zwischen 

Produktionssystem und vom Backup gestarteten System mit 

Microsoft Robocopy) 

- Nutzung der Standard Applikations- und Datenbankverwaltungstools, 

um einzelne Objekte wiederherstellen zu können. Der 

Applikationsadministrator kann hierbei seine gewohnten Tools 

und Programme verwenden 

Abbildung 011: U-AIR Beispiel: Wiederherstellung einer SQL 

Tabelle über ein Standard-Oracle-Verwaltungstool 

17


- Nutzung der Veeam U-AIR Wizards für Active-Directory / Exchange 

/ SQL Single Object Restore 

7.6 SureBackup 

Abbildung 012: U-AIR Wizard Beispiel: 

Wiederherstellung eines Active-Directory Benutzers 

Ein häufiger Stolperstein beim Restore von Servern und Anwendungen 

ist nicht die verwendete Backuptechnik an sich, sondern die zu sichernde 

Ausgangsbasis. Hierbei kommt es häufig vor, dass systemkritische Dateien 

beschädigt sind oder erst gar nicht dem Backupjob hinzugefügt worden 

sind. 

Seit über 20 Jahren fordern deshalb die Backupsoftwarehersteller von 

ihren Kunden regelmäßig die Wiederherstellung zu prüfen. Hierbei 

wird auf einem extra dafür vorgesehenen, separat beschafften Storage 

der Datenbestand zurückgespielt. Im Nachgang nimmt ein Administrator 

langwierige Änderungen vor, um ein Serversystem parallel 

zur Produktion in einem Testnetzwerk anzustarten. In der Regel sind 

dies nur stichprobenartige Prüfungen, die zwar aufzeigen, dass grundsätzlich 

die Backuptechnologie in der Lage ist ein Restore auszuführen, 

befreit jedoch den Administrator nicht von der Sorge, im Fehlerfall 

keinen sauberen und funktionsfähigen Restore ausführen zu können. 

Veeam nimmt diese Last von den Administratoren und automatisiert diesen 

Vorgang mit Hilfe der SureBackup-Technologie. Diese Funktion prüft 

jedes Backup in einer Sandbox-Umgebung (Virtual Lab) auf seine Wiederherstellbarkeit, 

den korrekten Betriebssystemstart, die Netzwerkerreich- 

18


barkeit und die Erreichbarkeit der Applikationen. Veeam liefert hierbei 

für die verschiedensten Applikationen Prüfskripte von Haus aus mit. Es 

können jedoch auch eigene Prüfskripte z.B. für die eigenen Fachanwendungen 

hinterlegt werden. Abhängigkeiten zwischen Servern können ebenfalls 

berücksichtigt werden, solange diese im Backup & Replication als 

Backup vorliegen. 

Prüfungsjobs können zentral erfolgen oder auf mehrere VMware ESX(i) 

Systeme verteilt werden. Es können sowohl dedizierte VMware ESX(i) Systeme 

als auch VMware ESX(i) Systeme mit produktiven VMs für die Prüfungen 

verwendet werden. 

Die Budgets für viertel- oder halbjährig von Hand ausgeführte Wiederherstellungstests 

inklusive der dafür vorgesehenen Hardware und Disk- 

System-Platzreservierungen können eingespart, Compliance Anforderungen 

automatisiert und deren Erfüllung dokumentiert werden. 

Abbildung 013: SureBackup – Automatische Wiederherstellungsprüfung 

nach jedem Backup 

8 Benötigte Veeam und IBM® TSM 

Infrastruktur 

Die Veeam Backup & Replication Infrastruktur untergliedert sich in 4 Komponenten. 

1. Enterprise Manager 

Zentrale Verwaltung aller Backup Server + Reporting 

2. Backup & Replication Server (Management) 

Job Erstellung + Scheduling + Proxy Load Balancing + Verwaltung 

3. Proxy Server 

Liest Daten aus den Datastores für Backup und Replikation aus. Im 

Falle von Replikation, übernimmt einer der Proxys am zweiten Standort 

die Aufgabe die Daten als VM anzulegen. 

4. Repository Server 

Nimmt im Falle von Backup die Daten vom Proxy entgegen und er- 

19


stellt Backup Files. Repository Server sind ebenfalls für den Daten- 

Rücktransport beim Restore verantwortlich. 

Auf Seiten von IBM ® TSM werden folgende Infrastrukturkomponenten 

benötigt: 

1. TSM Client 

Auf allen Veeam Repository Servern installiert 

2. (Vorhandener) TSM Server 

Nimmt Filedaten vom TSM Client entgegen und speichert bzw. organisiert 

diese auf einem (Tape) Pool. 

Abbildung 014: Beispiel Backup Infrastruktur bei Zusammenarbeit von Veeam Backup & 

Replication und IBM® TSM 

Das hier abgebildete Infrastrukturbild stellt eine häufig umgesetzte Implementierungsvariante 

in größeren Umgebungen dar. Im Backup & Replication 

User Guide finden Sie weitere Varianten, Beispiele und Hinweise zum 

Aufbau der Infrastruktur. Den jeweils aktuellen User Guide finden Sie unter: 

http://www.veeam.com => „Produkte“ => „Backup & Replication“ => 

in der Mitte der unteren Navigation auf „Ressources“ => 

„User Guide“ 

9 Einrichtung der Veeam und IBM® TSM 

Infrastruktur 

Die hier gezeigten Verfahren und Einstellungsmöglichkeiten sind lediglich 

als Beispiel zu sehen, stammen jedoch alle aus der Praxis. Ihre Veeam- und 

IBM ® TSM-System Engineers können Ihnen weitere Möglichkeiten aufzeigen. 

20


9.1 Veeam Backup & Replication Einrichtung 

Auf den für Veeam vorgesehenen physischen und virtuellen Serversystemen 

wird ein Windows 64 Bit Betriebssystem eingerichtet (z.B. Windows 

2008 R2) und in das bestehende Patch- und Überwachungsmanagement 

mit eingebunden. Zu beachten ist hierbei, dass Update-Patchläufe nicht zu 

Backupzeiten stattfinden dürfen. Weitere Voraussetzungen zu Hardwareund 

Softwarekomponenten entnehmen Sie bitte dem Veeam Backup & 

Replication User Guide und den Backup & Replication Release Notes Dokumenten. 

Der Veeam Backup & Replication (Management) Server wird in einer virtuellen 

Maschine installiert (Standardsetup mit im Setup enthaltener lokaler 

Microsoft SQL Express Datenbank). Von diesem System aus werden 

die Proxy und Repository durch die integrierte Softwareverteilung später 

eingerichtet. 

Der Enterprise Manager wird in der Regel ebenfalls auf einer eigenen virtuellen 

Maschine installiert. Hier wird die Veeam Backup & Replication 

Lizenz hinterlegt. Durch Hinzufügen des bereits installierten Backup & 

Replication (Management) Servers, werden von diesem zukünftig Informationen 

für das Reporting abgerufen. Der Enterprise Manager verwaltet 

für alle Backup & Replication Server zentral die Lizenzen. 

Weitere Basiseinstellungen des Management Servers und Verteilung der 

Proxy/Repositories: 

Abbildung 015: Aufruf der Optionen 

21


Abbildung 016: E-Mail Benachrichtigung aktivieren 

Abbildung 017: Hinzufügen eines Proxys 

22


Abbildung 018: Auswahl des Servers für die Proxy Installation 

Abbildung 019: Name des Proxy Servers 

23


Abbildung 020: Eintragen der (Proxy) Windows Logindaten 

Abbildung 021: Softwareverteilung starten 

24


Abbildung 022: Proxy Optionen: in unserem Infrastrukturbeispiel: „Direct SAN“ Transport 

Mode. Der „Max concurrent tasks“ Wert sollte so hoch wie möglich gewählt werden, ohne 

dass eine Warnung erscheint. 

Abbildung 023: Start der Repository Einrichtung 

25


Abbildung 024: Name des in den Jobs später auswählbaren Repository, welches auf einem 

ausgewählten Repository Server abgelegt wird. 

Abbildung 025: Auswahl des Repository Server Typs (Windows) 

26


Abbildung 026: Repository Server hinzufügen oder existierenden Server auswählen 

Abbildung 027: Gegebenenfalls ist der Server in der Auswahl nicht vorhanden und es 

muss über „Add new“ hinzugefügt werden. 

27


Abbildung 028: Gegebenenfalls Login Daten für den Repository Server angeben. 

Abbildung 029: Verzeichnis Auswählen in dem die Backupdaten abgelegt werden. 

28


Abbildung 030: vPOWER NFS Server auswählen (Gleicher Server wie ausgewählter Repository 

Server). NFS Verzeichnis sollte nicht auf dem C: Laufwerk abgelegt werden sondern 

auf einem schnellen Storagesystem (Schnell drehende SAS/FC oder SSD Platten). 

Abbildung 031: Hinzufügen eines VMware vCenters 

29


Abbildung 032: Auswahl des Servertyps 

Abbildung 033: Eintragung des FQDN des vCenter Servers 

30


Abbildung 034: Angabe von Login Daten 

9.2 IBM® TSM Client Einrichtung 

Dieses Dokument geht von einer bereits installierten und konfigurierten 

IBM® TSM Server Umgebung aus. Die Einrichtung einer solchen Umgebung 

wird deshalb hier nicht näher beschrieben. 

Auf allen Repository Servern wird ein TSM Client installiert. Hierbei wird 

das Setup wie bei normalen Fileservern installiert. 

Abbildung 035: TSM Client Setup Optionen 

31


Mit dem Befehl 

register node ”RepositoryServername“ ”Password“ 

domain= “TSMDomain” userid=none PASSExp=0 

wird Beispielsweise der TSM Client auf der Serverseite registriert. Dieser 

Name und andere Netzwerkeinstellungen müssen jetzt noch zusätzlich 

im TSM Client festgelegt werden. In der Regel gibt es hierfür eine Vorlage 

Ihres Unternehmens für die Konfigurationdatei „dsm.opt“. 

Einfaches Beispiel: 

NODENAME RepositoryServername 

CLUSTERnode NO 

PASSWORDAccess generate 

COMMMethod TCPip 

TCPServeraddress tsm 

TCPPort 1500 

DOMAIN \\RepositoryServername\e$ 

Um zu begrenzen welche Backupfiles gesichert werden können, wird in 

dieser dsm.opt Datei noch eine Include-/Exclude-Liste gepflegt. 

Startet jetzt ein durch TSM geschedulter Backupjob oder wird die Sicherung 

per CLI ohne Optionen gestartet, werden alle Dateien, welche durch 

die Include-/Exclude-Liste definiert sind, gesichert. 

Unter Punkt 12.4 in der Tabelle finden Sie 3 Beispiele für die Include-/Exclude-Liste 

und weitere Optionen zum Umgang mit geöffneten Files (VSS). 

10 Aufbewahrungsfristen & Scheduling 

10.1 Veeam Backupfiles 

Backup & Replication liest aus VMware eine VM nur einmalig als Full für 

einen Job aus und sichert zukünftig nur Änderungen auf Blockebene. Für 

die Aufbewahrung von Backupfiles baut Veeam daraus zuverlässig eigene 

Backupfiles. 

Wird ein neuer Backupstand in einem Veeam Backupfile festgehalten, so 

bekommt mindestens eines der Backupfiles einen neuen Namen oder wird 

neu generiert. Aus Sicht von TSM werden Backupfiles nicht wieder verändert. 

Hierbei gibt es in der Praxis zwei Backupverfahren und eine Kombination 

aus beiden: 

10.1.1 „Incremental with Syntetic Full“ 

Es werden aus den gesicherten Daten *.vbk Full Backupfiles (meist 

Wochenende) und *.vib Incremental Backupfiles (unter der Woche) abgelegt. 

Wählt man den Aufbewahrungszeitraum über mehrere Wochen, 

liegen mehrere Fulls + Incrementals auf Disk. 

32


10.1.2 „Reverse Incremental“ 

Es wird einmalig ein Full-File erzeugt. Tägliche Änderungen werden direkt 

in das Full-File geschrieben (neuer File Name), jedoch werden vorher noch 

die zu überschreibenden Blöcke in ein sogenanntes *.vrb Reverse-Incremental-File 

ausgelagert. Wird dieser Vorgang wiederholt, erhält man immer 

vom aktuellen Stand ein Full-File zusammen mit mehreren kleineren 

Reverse-Incremental-Files(ältere Stände). 

Hinweis: Reverse-Incremental-Files beziehen sich auf neuere Backupfiles, 

während normale Incremental-Files sich auf ältere Backupfiles 

beziehen. 

Der Vorteil beim Reverse-Incremental Verfahren ist, dass vom aktuellen 

Backupstand ein Full für einen möglichst schnellen Restore vorliegt und 

dass je Job nur ein Full-File auf Disk gespeichert wird. 

10.1.3 Incremental - Transform previous full backup chain into 

rollbacks 

Unter der Woche werden bei diesem Backupverfahren normale Incremental-Files 

geschrieben. Am Wochenende werden alle Incremental-Files der 

Reihe nach mit dem Full des letzten Wochenendes zusammen in Reverse- 

Incrementals umgebaut, bis vom aktuellen Stand ein Full auf Disk liegt und 

die älteren Backupstände als Reverse-Incremental-Files vorliegen. Vorteil: 

Es wird nur ein Full-File aufbewahrt und unter der Woche können kleine Incremental-Files 

auf Band ausgelagert werden. Nachteil: Am Wochenende 

werden die Disksysteme, auf dem die Backupfiles liegen, über Stunden 

sehr hohen I/Os Belastungen ausgesetzt. 

Weitere Erläuterungen zu den Backupverfahren erhalten Sie im Veeam 

User Guide. Die jeweils aktuelle Version finden Sie unter: 

http://www.veeam.com => „Produkte“ => „Backup & Replication“ 

=> in der Mitte der unteren Navigation auf „Ressources“ => „User 

Guide“ 

10.2 Backup & Replication 

Aufbewahrungsfrist für Backups 

In Backup & Replication wird festgelegt wie viele Backupstände aufbewahrt 

werden. Zusammen mit dem individuell festlegbaren Scheduler 

ergeben sich daraus Zeiträume wie lange Backupstände und somit die 

Backupfiles auf Disk vorgehalten werden. 

30 Backupstände bei täglich geplantem Backup ergeben 30 Backupfiles die 

je 30 Tage aufbewahrt werden. Für diese Zeiträume und dessen genauen 

Ständen stehen sämtliche weiter oben beschriebenen Wiederherstellungen 

zur Verfügung. 

33


Parameter, die die Backupstände beeinflussen: 

10.2.1 Restorepoints to keep on disk. 

Legt fest, wie viele Stände aufbewahrt werden 

10.2.2 Scheduler 

Abbildung 036: Resorepoints to keep on disk 

Legt fest, wie häufig ein Backup automatisiert ausgeführt wird. 

Abbildung 037: Scheduler 

34


10.2.3 Manuelles starten des Jobs 

Wird der Job von Hand gestartet reduziert sich die Aufbewahrungszeit je 

manueller Ausführung, da ein weiterer Backupstand dabei erzeugt wird. 

Nicht betroffen hiervon ist „Retry Backup Job“) 

10.2.4 „Incremental“ Backupverfahren 

Ist der letzte Restorepoint der aufbewahrt werden muss, ein inkrementelles 

Backupfile, so werden alle weiteren Backupfiles die zur Wiederherstellung 

des inkrementellen Backupfiles benötigt werden ebenfalls noch 

aufbewahrt. 

10.3 Grundsätzliche Erläuterung der TSM 

Copygroup Parameter 

Der Tivoli® Storage Manager sichert im Gegensatz zu anderen Legacy 

Backup Tools eine Datei nur einmalig. Solange diese Datei sich nicht verändert, 

wird Sie auch nicht noch einmal an den TSM Server übertragen (Incremental 

Forever). 

Um z.B. die Veeam Backupfiles auf Tape auszulagern, muss für TSM bestimmt 

werden, wie lange die gesicherten Files (in unserem Fall die Veeam 

Backup Files) in TSM aufbewahrt werden. Dies wird mit 4 Parametern festgelegt. 

Es empfiehlt sich für das Auslagern von Veeam Backup & Replication Backupfiles 

an TSM eine oder mehrere separate CopyGroups und Managementklassen 

anzulegen. 

10.3.1 „verexist“ 

Legt fest, wie viele Versionen einer noch auf dem zu sichernden Server 

existierenden Datei in TSM gespeichert werden. 

Für Veeam kann dieser Wert fest auf 1 gesetzt werden, da Veeam seine 

Backupfiles nicht verändert, bzw. beim Reverse Incremental Verfahren 

nicht unter gleichem Namen erneut speichert. 

10.3.2 „verdelete“ 

Legt fest, wie viele geänderte Versionen einer gelöschten Datei aufbewahrt 

werden sollen. Wie bereits beschrieben, existiert beim Veeam Backup im 

Sinne von TSM nur eine Version einer Datei und somit kann dieser Schalter 

auf 1 gesetzt werden. 

10.3.3 „retextra“ 

Legt für alle in TSM existierenden Versionen einer Datei fest, wie lange 

diese aufbewahrt werden. 

Ausnahmen: 

1. Die (aktive) aktuell existierende Dateiversion wird immer aufbewahrt. 

35


2. Bei der zuletzt verbleibenden Dateiversion einer gelöschten Datei greift 

der retonly Schalter. 

Da es keine zusätzlichen Versionen einer Veeam Backup Datei gibt, kann 

dieser Schalter auf 0 gesetzt werden. 

10.3.4 „retonly“ 

Der retonly Parameter legt fest, wie lange die letzte in TSM verbleibende 

Version einer Datei aufbewahrt wird. Eine Ausnahme stellt die aktuell noch 

existierende Version einer Datei dar. Sie ist von diesem Schalter erst betroffen, 

wenn sie gelöscht wird. 

Der retonly Parameter kann im Nachhinein verändert werden und hat sofort 

Auswirkungen auf die in TSM gesicherten Files. Wird beispielsweise 

der Wert vergrößert und es befindet sich noch eine Datei im retonly Status, 

erhält diese automatisch die längere (neue) Aufbewahrungsfrist. 

Gleicher Wiederherstellungszeitrahmen in TSM und dem Veeam eigenen 

Repository Disk Pool 

Hierfür müsste eigentlich bei diesem Parameter und bei dem „verdelete“ 

Parameter eine 0 stehen. Um den Fall abzusichern, dass aus Versehen jemand 

die Files aus dem Veeam Repository Disk Pool löscht, sollte hier ein 

Wert von mindesten 4 (Tagen) gesetzt werden. 

Längere Aufbewahrungsfrist in TSM als im Veeam Repository Disk Pool 

Eintrag der Anzahl an zusätzlichen Tagen bei retonly, die auf Band länger 

als im Veeam Repository Disk Pool vorgehalten werden sollen. 

10.4 Beispiel für die zugehörigen TSM 

ManagementClass und CopyGroup Befehle 

Genauere Details finden Sie auch in den ausgearbeiteten Beispielen in den 

folgenden Kapiteln. 

Hier ein Beispiel für die Einrichtung auf dem TSM Server: 

define mgmtclass „TSMdomain“ „TSMpolicyset“ Veeam- 

Full migdestiation=none 

define copygroup „TSMdomain“ „TSMpolicyset“ Veeam- 

Fill type=backup destination=”TapePoolName” verexists=1 

verdelete=1 retextra=0 retonly=90 

11 Zusammenspiel Backup & Replication 

Scheduler und TSM Scheduler 

Für die Organisation und Administration der Backups stehen mehrere 

Möglichkeiten in der Kombination mit IBM® TSM zur Verfügung. 

Ein typisches Szenario sieht vor, dass der TSM Administrator sich wie bisher 

um das Scheduling, die TSM Server, den Datenfluss zu TSM, das Error 

Reporting und die Offline Auslagerung von Backups mit Bordmitteln von 

36


TSM kümmert. Für den Virtualisierungs- und Applikationsadministrator 

stehen hierbei die sehr einfach und intuitiv gehaltene Veeam GUI für die 

Organisation von Backupinhalten und den Restore zur Verfügung. 

Über Post Job Commands kann auch Veeam Backup & Replication genutzt 

werden, um zentral das Scheduling und den Transport der Daten in TSM 

zu organisieren. 

Als Alternative zu den beiden zentralen Scheduling-Verfahren, kann Veeam 

auch das Sichern der Daten auf Disk übernehmen, während später durch 

den TSM-Administrator das Auslagern der Daten in TSM separat geplant 

wird. Dies kann dann zu einem Zeitpunkt in dem die TSM Server nicht 

durch Legacy-Backup belastet sind stattfinden. Die eigentlichen Veeam 

Backups hängen hierbei nicht von der TSM Performance ab. 

12 Umsetzungsbeispiele Übersicht 

12.1 Übersicht zu Beispiel 1: 

Backup Mo-Fr mit Backup & Replication und einer Aufbewahrung auf Disk 

von 10 Wiederherstellungsständen (2 Wochen). Die wöchentlichen Fulls 

werden in TSM zur Aufbewahrung mit einer Aufbewahrungsfrist von 1 Jahr 

ausgelagert. Das Scheduling wird getrennt von Backup & Replication und 

TSM übernommen. Dies ermöglicht eine separate Datenstromsteuerung 

=> Veeam steuert das VMware Backup und das Schreiben in den Veeam 

eigenen Disk Pool (Repository). TSM steuert dann die Auslagerung der 

Veeam Backup & Replication Backupfiles auf Tape. 


Tägliches Backup mit Backup & Replication. Die Aufbewahrung auf Disk 

erfolgt für 30 Tage. Eine Kopie der Backupfiles wird täglich in einen TSM- 

Pool geschrieben. Die Aufbewahrung in TSM erfolgt ebenfalls 30 Tage. 

Das Scheduling übernimmt TSM komplett. 


Tägliches Backup mit Backup & Replication. Die Aufbewahrung im Veeam 

Disk Pool (Repository) erfolgt 14 Tage lang. Es werden täglich nach der 

Backup & Replication Sicherung die Veeam Backupfiles an TSM, zur ebenfalls 

14-tägigen Aufbewahrung (Incremental- und Fullfiles) übergeben. 

Die Full-Wochensicherung wird zusätzlich noch 8 Wochen in TSM (Tape) 

zusätzlich aufbewahrt. Das Scheduling erfolgt komplett durch Veeam 

Backup & Replication. 

37


Veeam Backupverfahren 

12.4 Details zu den Beispielen 1-3: 

Beispiel 1 Beispiel 2 Beispiel 3 

Reverse Incremental Incremental Incremental 

Veeam Restore Points 10 30 14 

Veeam Scheduler täglich deaktiviert täglich 

Veeam Error Reporting E-Mail / SNMP / Enterprise Manager 

Webinterface / Userinerface 

(nur Backup & Replication 

Backup) 

Veeam Post Job Command 

IBM® TSM Scheduler Normaler Scheduler wie File 

Backup. 

Wöchentlich nach allen Veeam 

Sicherungen. Zu sichernde 

Backupfiles werden über dsm.opt 

bestimmt. 

TSM Error Reporting Wie bei normalem File Backup 

(für das Auslagern der Backupfiles 

in TSM) 

TSM MGMT 

Class “Veeam” verexists 


Class “Veeam” verdelete 


Class “Veeam” retextra 


Class “Veeam” retonly 

TSM MGMT Class 

“Veeam-Full” verexists 


“Veeam-Full” verdelete 


“Veeam-Full” retextra 


“Veeam-Full” retonly 

E-Mail / SNMP / Enterprise Manager 

Webinterface / Userinerface 

(nur Backup & Replication 

Backup) 

- - 

Je Veeam Job wird ein eigener 

Scheduler (Command) angelegt, 

der auf dem jeweiligen Repository 

Server nur das Backup-Verzeichnis 

des zugehörigen Jobs 

sichert. Der Scheduler startet 

hierbei ein Powershell Script: 

Add-PSSnapin -Name VeeamPSSnapIn 

-ErrorAction Silently- 

Continue 

Get-VBRJob | where{$ _ .Name 

-eq "Jobname"} | Start-VBR- 

Job 

Dsmc incremental – 

optfile=dsm.opt e:\VeeamRepositoryPfad\Jobname\ 

Der letzte Parameter bewirkt, 

dass nur die Dateien eines einzelnen 

Jobs gesichert werden. 

Wenn Veeam Backup über TSM 

Scheduler gestartet wird und 

fehlschlägt wird ein Error Wert 

an TSM Client übergeben. Dieser 

kann wie bei anderen Skripten 

(SQL Backup) aus TSM überwacht 

werden. Beim Auslagern der 

Daten in TSM erfolgt Error Reporting 

wie beim normalen TSM 

Client File Backup. 

1 1 

1 1 

0 0 

366 

4 (Schutz für versehentliches 

löschen) 

n/a n/a 

E-Mail / SNMP / Enterprise 

Manager Webinterface / 

Userinerface (nur Backup & 

Replication Backup) 

Ein Remote Powershell command 

führt auf dem Repository folgendes 

aus: Dsmc incremental 

–optfile=dsm.opt e:\VeeamRepositoryPfad\Jobname\ 

Wie bei normalem File Backup 

(für das Auslagern der Backupfiles 

in TSM). Wichtig hierbei 0 

Byte/Files gesendet Überwachung. 

- 

n/a 

1 

1 

0 

56 

38



“Veeam-Incr” verexists 


“Veeam-Incr” verdelete 


“Veeam-Incr” retextra 


“Veeam-Incr” retonly 

n/a n/a 

12.5 Hinweise zum Beispiel 1 

12.5.1 Backupzeitfenster von TSM 

Nach dem Freitagsbackup hat TSM bis zum Backuplauf am nächsten Montag 

Zeit, den Datenbestand (Full-Backup-Files eines Tages) wegzusichern. 

Wie bei TSM VE auch, sind dies eher wenige dafür recht große Files. Der 

Vorteil von Veeam hierbei ist, dass die Files dedupliziert und komprimiert 

werden, bevor Sie in TSM ausgelagert werden, was eine große Einsparung 

an Übertragungs- und Platzressourcen ermöglicht. 

Eine Aufteilung in mehrere Datenströme in Richtung TSM ist zwingend 

empfohlen, jedoch skaliert die Übertragung von wenigen großen Files 

nicht so gut wie bei vielen kleinen Files. Auf TSM Server- und Client-Seite 

sind deshalb Optimierungen für die Sicherung von großen Files zu treffen. 

Alternativ kann das Auslagern der Full-Backup-Files auch über die 

Wochentage verteilt erfolgen (Montag 1/5 aller Backupjobs, Dienstag 1/5 

aller Backupjobs, usw.) Dies reduziert die Belastung von TSM anteilig. 

12.6 Hinweise zum Beispiel 2 


Am Wochenende werden von Veeam in diesem Beispiel Full-Backup-Files 

geschrieben, die mit TSM weggesichert werden. Wie bei TSM VE auch, sind 

dies eher wenige große Files. Der Vorteil von Veeam hierbei ist, dass die 

Files dedupliziert und komprimiert werden, bevor sie in TSM ausgelagert 

werden, was eine große Einsparung an Übertragungs- und Platzressourcen 

ermöglicht. 



nicht so gut wie bei vielen kleinen Files. Auf TSM Server und Client Seite 


1 

1 

0 

4 (Schutz für versehentliches 

löschen) 

TSM Client Backupmode File-Backup File-Backup File-Backup 

Dms.opt Exclude * 

Exclude * 

Exclude * 

Include *.vbk Veeam 

Include *.vbk Veeam 

Include *.vbr Veeam-Full 

SNAPSHOTPROVIDERFS VSS Include *.vib Veeam 

Include *.vib Veeam-Incr 

Include *.vbm Veeam 

Include *.vbm Veeam-Incr 

SNAPSHOTPROVIDERFS VSS SNAPSHOTPROVIDERFS VSS 

Veeam SureBackup 

Kann über das TSM Backupscript 

optional mitgestartet werden: 

Separat geplant 

Get-VSBJob | where{$ _ .Name 

-eq "Jobname-Surebackup"} | 

Start-VSBJob 

Separat geplant 

39


Auf TSM Server 

Auf Repository Server: 

C:\Scripts\Jobname.ps1 

Optional inklusive 

SureBackup (z.B. für die 

wichtigsten Server) 

Alternativ kann das Auslagern der Full-Backup-Files auch über Wochentage 

verteilt erfolgen. Der Syntetic Full Wochentag kann über die Jobs verteilt 

auf andere Wochentage erfolgen. Dies reduziert die Belastung von 

TSM anteilig. 

12.6.2 TSM Scheduler 

def schedul Veeam VEEAMREPOSITORY-SERVER-NODE action=command object="c:\windows\system32\ 

WindowsPowershell\v1.0\powershell.exe c:\scripts\jobname.ps1" priority=2 starttime=22:00 

duration=60 durunits=minutes period=1 perunits=days dayofweek=any 

Add-PSSnapin -Name VeeamPSSnapIn -ErrorAction SilentlyContinue 

Get-VBRJob | where{$ _ .Name -eq "Jobname"} | Start-VBRJob 

Dsmc incremental –optfile=dsm.opt e:\VeeamRepositoryPfad\Jobname\ 

Add-PSSnapin -Name VeeamPSSnapIn -ErrorAction SilentlyContinue 

Get-VBRJob | where{$ _ .Name -eq "Jobname"} | Start-VBRJob 

VSBJob | where{$ _ .Name -eq "Jobname-Surebackup"} | Start-VSBJob 

Dsmc incremental –optfile=dsm.opt e:\VeeamRepositoryPfad\Jobname\ 

12.7 Hinweise zu Beispiel 3 


Am Wochenende werden von Veeam in diesem Beispiel Full-Backup-Files 

geschrieben, die mit TSM weggesichert werden. Wie bei TSM VE auch, sind 

dies eher wenige große Files. Der Vorteil von Veeam hierbei ist, dass die 

Files dedupliziert und komprimiert werden, bevor sie in TSM ausgelagert 

werden, was eine große Einsparung an Übertragungs- und Platzressourcen 

ermöglicht. 



nicht so gut wie bei vielen kleinen Files. Auf TSM Server und Client Seite 


Alternativ kann das Auslagern der Full-Backup-files auch über Wochentage 

verteilt erfolgen. Der Syntetic Full Wochentag kann über die Jobs verteilt 

auf andere Wochentage erfolgen. Dies reduziert die Belastung von 

TSM anteilig. 

12.7.2 Remote Powershell 

Post Job Commands werden auf dem Backup & Replication Management 

Server ausgeführt. Wir wollen jedoch die Backupdaten von einem Repository 

Servers sichern und müssen deshalb über Remote Powershell das 

Script vom Veeam Backup & Replication (Management) Server aus auf 

dem Repository Server remote starten. 

Eine Anleitung hierzu finden Sie unter: 

http://forums.veeam.com/viewtopic.php?f=26&t=11836 

40


13 Restore 

13.1 Restore mit Veeam Backup & Replication 

von Disk 

Mit Veeam Backup & Replication lassen sich einzelne Files, ganze VMs, 

einzelne VMware Files, einzelne VM Volumes und Applikationsobjeckte 

(wie z.B. einzelen Mails oder Active Directory Benutzer) wiederherstellen. 

Die Highlights der Restore Möglichkeiten sind in Kapitel 7 näher beschrieben. 

Eine detaillierte Anleitung mit Screenshots findet sie ebenso im Veeam 

Backup & Replication Userguide unter: 

http://www.veeam.com => „Produkte“ => „Backup & Replication“ 

=> in der Mitte der unteren Navigation auf „Ressources“ => 

„User Guide“ 

13.2 Restore von älteren 

Wiederherstellungspunkten die nur noch in 

einem TSM (Tape) Pool liegen 

Über den auf den Repository Servern installierten TSM Clients können 

die Veeam Backup & Replication Backupfiles zurückgespielt werden. Anschließend 

erfolgt ein schnell abgeschlossener Import der Backupfiles in 

Veeam Backup & Replication, welches dann sofort in der Lage ist, sämtliche 

zu Verfügung stehenden Restoremöglichkeiten zu starten. 

Bei dem Restore der Backupfiles aus dem TSM Client ist darauf zu achten, 

dass der TSM Client in den Modus versetzt wird, in dem er ebenfalls "inaktive 

Files" anzeigt. 

Abbildung 038: Restore der Veeam Backupfiles im TSM Client 

41


Der Import der Backupfiles erfolgt über folgenden Menüpunkt in Veeam 

Backup & Replication: 

Abbildung 039: Import der Backupfiles in Veeam Backup & Replication 

Starten des eigentlichen Restores: 

Abbildung 040: Restoremöglichkeiten in Veeam Backup & Replication 

13.3 Restore der kompletten Veeam Backup & 

Replication Umgebung 

Ging die gesammte VMware Umgebung inklusive der Veeam Backup & 

Replication Server unter (z.B. Feuer), kann diese Umgebung wieder aus 

einem TSM (Tape) Pool mit enthaltenen Veeam Backupfiles aufgebaut 

werden. Hierzu sind folgende Schritte notwendig: 

42


1. Installation eines Windows Servers mit TSM Client und neu installiertem 

Backup & Replication 

2. Restore der Veeam Backupfiles über den TSM Client, so dass diese 

auf Disk liegen. 

3. Import der Backupfiles in Veeam 

4. Starten der normalen VM Restores jetzt möglich. 

Soll der Veeam Backup & Replication Server mit seinen Jobinformationen 

ebenfalls hergestellt werden, so kann dieser aus dem Backup ebenfalls 

wiederhergestellt werden. 

14 Funktionstests und Aufbewahrungsprüfungen 

Es wird empfohlen die installierte und eingerichtete Umgebung ausführlich 

zu prüfen und zu dokumentieren um Konfigurationsfehler auszuschließen. 

Erst nach erfolgreicher Prüfung ist die Umgebung in die Produktion zu 

überführen. 

Eventuell können die Prüfungen mit verkürzten Aufbewahrungszeiten erfolgen 

um schnelleres Feedback zu gewinnen. 

Bei der Dokumentation der Umgebung kann die Veeam ONE Reportingfunktion 

helfen. Hier kann auf Knopfdruck die komplette VMware Umgebung 

in Word-, Excel-, PDF- und Viso-Files dokumentiert werden. 

15 Fazit 

Veeam Backup & Replication bietet extrem schnellen Wiederanlauf vom 

Backup in Verbindung mit dem sicheren Bauchgefühl, dass die Wiederherstellung 

auch zu 100% erfolgreich sein wird, da alle Backups automatisch 

auf Wiederherstellbarkeit geprüft werden können. 

Die erweiterten Backupverfahren und die Möglichkeit, Datenströme auf 

ein optimal mögliches Minimum zu begrenzen, sind ein weiteres Kriterium 

Veeam Backup & Replication (als Erweiterung) mit IBM® TSM einzusetzen. 

Die in diesem Dokument dargestellten Beispiele Verfahren stammen aus 

der Praxis und stellen Best-Practices-Verfahren dar. Je nach Umgebung 

lässt sich Veeams Backup & Replication auch entsprechend an andere Anforderung 

angepasst integrieren. 

Die Replikationsmöglichkeiten bieten On-Top Disaster Reocery Möglichkeiten 

für verteilte Standorte. Ebenso sind Sie erste Wahl wenn Im Fehlerfall 

ein Server sofort mit voller Leistung wieder zur Verfügung stehen 

muss. 

Neben diesen Verfahrens- und Administrativen-Vorteilen kann Veeam 

auch helfen, die Kostenseite zu optimieren. 

43


Über den Autor 

Andreas Neufert, 

System Engineer Central EMEA, Veeam Software 

Andreas Neufert berät mit seinem 16-jährigen 

IT Infrastruktur Background bei Veeam Software 

strategische Großkunden und Partner im Bereich 

Hochverfügbarkeit, Backup und Betriebsoptimierung 

von virtuellen Umgebungen. Schwerpunkte seiner 

bisherigen Laufbahn waren Consulting und Projektmanagement von 

großen IT Infrastruktur Projekten bei Public Kunden im IBM® Storageund 

Virtualisierungsumfeld. Als Business Development Manager 

sammelte er ergänzend mehrjährige Erfahrungen bei der Umsetzung von 

Wachstumsplänen und Vertriebskonzepten bei und für IBM® (Premier) 

Business Partner. Er leitet seit über 10 Jahren erfolgreich Teams. 

Andreas Neufert studierte Betriebswirtschaftslehre an der 

VWA-Stuttgart. 

Über Veeam Software 

Veeam ® Software entwickelt innovative Lösungen für VMware-Backups, 

Hyper-V-Backups und das Virtualisierungsmanagement. Veeam Backup 

& Replication ist die branchenführende Lösung für Backups virtueller 

Maschinen. Veeam ONE bietet in einer einzigen, integrierten Lösung 

Echtzeit-Überwachung, Ressourcenoptimierung, Dokumentation und 

Management-Reporting für VMware und Hyper-V. Veeam ermöglicht 

mit dem Veeam Management Pack (MP) eine umfassende VMware- 

Überwachung direkt über Microsoft System Center. Mit dem Veeam 

Smart Plug-In (SPI) überwachen Sie Ihre VMware-Umgebung direkt 

über HP Operations Manager. Veeam stellt außerdem kostenlose 

Virtualisierungs-Tools bereit. Weitere Informationen finden Sie unter 

www.veeam.de 

Hinweise: 

IBM® und Tivoli® sind eingetragene Marken der International BusinessMachines Corporation. 

44

Veeam Backup und IBM TSM Integration

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?