New Blog

Dear reader,

To work more inline with my twitter activities and to open my blog for more interessting stuff (not just Veeam related), I am blogging only on the blog from now.

If I will write some updates at individual posts (e.g. Exchange Backup stuff) I will add an warning message with a link to the article on this blog.

So do not hesitate to check out my new blog under

Thanks for all the Feedback and support


Donnerstag, 20. Dezember 2012

HA? DataProtection? DataRecovery? - IBM San Volume Controller SVC and Veeam Backup & Replication

Many DR scenatios didn´t reflect the need of the companies. Sometimes because of budget problems, sometimes of other things.
Why you want to bring data to another site?
HA? DataProtection? DataRecovery?

If you look at syncron mirrors. This is a typical HA szenario. If you go active-active there it can help to bring the servers back online as fast as of a boot. (VMware HA or othe cluster/failover solutions at legacy systems). Because this is an expensive one for legacy systems, this leeding to a scenario which VMs are ways better protected (HA) than my Tier 1 legacy systems. This and the advantages for maintenance (vmotion), power and cooling savings brings customer to a point that more and more Tier 1 applications are placed on virtualization.
Products that can be helpful here are IBM SVC, Datacore, Netapp, others.

Why this szenario has nothing to do with DP or DR.
You replicate only the disk data, so applications and DBs are not in a consistent state. Also the Applications and DBs are not in a Application Restore aware state. (see below)
Software errors are mirrored as well and if there are bugs in the code of the solution both sides are affected.
If you look at the storage and storage virtualization systems and their bigger and bigger fail domains you need a backup solution that fits your datarecovery needs.
Many customers looking because of the big fail domain at Replication solutions and looking for storage replication that can store more then 1 restore point (replicated snapshots).
Here you need to regard that your Servers/DBs/Applications are in the following states that you have no problems in case of restore/recovery. This is pretty the same demand for BackupSoftware.
a) Consistency (Application/OS/DBs). Basically before you do a replication/snapshot all RAM caches needs to be written to disk and no open write commands of the filesystem are there.
b) Application awareness: You have to set some settings in the OS/Application/DBs that after next boot(after restore/recovery) they jump into a mode that they needed in that secenario to avoid problems. A typical problem that is a good example for this is if you start active directory servers without this from different snapshots/recovery points you end up with an inconsistent and not supported active directory database.

So in most cases you need some software that can do this in addition to the storage snapshot replication base. IBM Flash Copy Manager or Netapp SnapManager for example. Or if you do this on the Software side Veeam (Virtualization) is a good example for this.

If you look at the size of your fail domains and your demand to bring back a lot of servers in a fail szenario. You need tools that can do this with an easy to use solution. Because of budget concerns many go only here with their backup software.

Most Backupsoftware can help to restore a Server in a timewindow you need (SLA) but if more than one server are affected this leeding into the situation where normal SLA are exceeded. There are some Backup Software that can help with this and can start systems directly out of the backup, start the OS and Applications and user can work, while later the data is transfered back to the repaired storage system. Veeam do this for example with VMs since 2010, but there are other solutions that can do this, for example NetBackup has announced that they will have that sort of recovery for VMs. Veeam holds the patents for this Instant VM Recovery.

Because this solutions uses the backup environment ressources to bring up the systems this can only be done with a limited number of systems, depending on the backup environment (20-100 VMs). So the idea was to add software based replication (Veeam for example) that has no direct interaction with storage System (storage fails can not harm this system) to replicate most critical systems to a separated datacenter over IP WAN links. There you can start (application aware) your core systems and you can recover over the next time your not so critical systems.

One cool thing I want to add from Veeam side. You are able to automatically test your Replicas (with v7 or newer) or Backups (v5 or newer) if they are able to restore your workloads. This scheduled restore checks test the  OS boot,  Network Connection and application Response.This include problems that are based on source side server. Simple example is a corrupt windows boot file that you do not detect in production. All backup solutions checks only the data with checksums > if same = backup/replication successfull. And you fail in case of restore. So this can be helpful to detect problems before you run into a failover scenario.

This described scenario reflect most budgets and can dramatically increase your operating safety.

Examples for a small szenario:

2 ESX Hosts with shared storage (redundant controllers)
Third ESX host on separate fire section or hosted datacenter. Which hold allsVMs as replicas.
Backup on the first side for fast restore and application/file restore.
Backup and recovery cheks on the second side of the replicas will help to prevent you from trouble in case you need your DR. 

Implementation of automatic Restore Checks with SureBackup and SureReplica.
 HW: Small Budget (Standard solution)
SW: Hyper-V or VMware Essentials + Veeam Essentials
Powerfull solution I think

Example for midsize - enterprise szenario:
VMware Hosts
Active-Active mirrored Storage (vdisk mirroring) for example with IBM SVC splitted over to datacenter on two fire sections. Third site with SVC Quorum.
Another datacenter many miles away with another Vmware environment which you use with Veeam replication of most critical systems.
Backup to third site (SVC Quorum) with Veeam (Fast Restore of Files/Objects/Servers).
Implementation of automatic Restore Checks with SureBackup and SureReplica.

What do you think? Yes it is very virtualization related but you get more operation safety than in legacy environments. Why not virtualize your biggest DBs on a 1:1 ratio and profit from this DR scenario. If you are concerned about VMware Snapshot commit szenarios or 2TB volume size limit, have a look at Hyper-V 3. The main idea behind this described szenario works there as well.

CU Any

Freitag, 7. Dezember 2012

Neues Video auf VMware/HyperV Backup: Lösungen für die strategischen Herausforderungen Ihrer Virtualisierungsumgebung

Hallo zusammen,

gemeinsam mit Carsten Rachfahl haben ich das Thema

"VMware/HyperV Backup: Lösungen für die strategischen Herausforderungen Ihrer Virtualisierungsumgebung"

näher auf erläutert.

Hier wurde im allgemeinen über das Thema Virtualisierungsbackup gesprochen, welche Unterschiede es hier bei VMware und Hyper-V gibt und wie eine passende Lösung zu den angesprochenen Herausforderungen idealerweise aussieht.

Happy viewing


Freitag, 30. November 2012

Exchange Backup unter VMware Herausforderungen gelöst *UPDATE3*

Please find updated Version here:

Danke an Claus Pfleger für die vielen Hinweise

Backup von Exchange über die VMware VADP Schnittstelle (welche auch Veeam nutzt) kann einige Herausforderungen mit sich bringen, die häufig im Vorfeld schon durch das passende Design gelöst werden können.
Die hier beschriebenen Lösungen sind teilweise meine eigenen Erfahrungen und teilweise auf den Beiträgen des Veeam Forums basierend. Ich hoffe hier hat niemand etwas dagegen, dass ich Sie hier komprimiert zusammenfasse (einfach melden). Ziel ist auch gewesen, das ganze auf Deutsch aufzubereiten.


VSS timeout with Exchange 2010
Issue with VMware & Exchange 2010 DAG

Es gibt bei der Verwendung eines Exchange DAG Clusters auf Virtualisierungsumgebungen bzw. bei dem Backup von großen Exchange Umgebungen zwei Dinge zu beachten.
1) DAG Cluster Heart Beat Einstellungen (hier muss aktiv in jedem Fall etwas getan werden)
2) Fest in Exchange eingebautes Timeout für den VSS (Backup-) Konsistenzstatus von 20 Sekunden (hier nur tätig werden bei Errors)

Diese Zusammenfassung soll Sie nicht verschrecken, sondern gleich im Vorfeld auf mögliche Herausforderungen hinweisen, um im Vorfeld schon dagegen zu wirken und um dementsprechend in keine Dienstausfälle für die Benutzer zu laufen.

Zu 1) DAG Cluster Heart Beat Einstellungen
In einem DAG Cluster tauschen die DAG Nodes Heartbeats aus, um zu prüfen ob alle Knoten noch online sind. Wird ein festgelegter Wert überschritten, schwenkt das Cluster und die aktiven Datenbanken der nun mehr nicht aktiven Cluser-Node, werden auf einem der anderen DAG Member aktiviert. Dies ist in der Regel transparent für die User. Es kann jedoch vorkommen, dass durch häufige Schwenks z.B. Index Dienste die Systeme so auslasten, dass das Userverhalten beeinträchtigt wird. Dies kann vor allem vorkommen wenn nach kurzer Zeit mehrere Schwenks vorkommen. Die Situation dargestellt: Backup Server 1 ist fertig, Schwenk durch Auflösen des Snapshots auf Server 2 => Server 2 wird kurze Zeit später wieder fertig und löst Snapshot auf => Somit wieder Schwenk auf Server 1 => Indexdienst Auslastung kann dann so hoch sein, dass User beeinträchtigt werden.

Auf Seiten von VMware und dessen VADP Backup Schnittstelle wird ein VM Snapshot nach der Herstellung des Konsistenzstatus erzeugt, um danach sofort den Konsistenzstatus wieder aufzulösen. Dies dauert in der Regel nur einige Sekunden, in denen der Konsistenzstatus etwas Performance kostet. Der Snapshot gibt dem Backup die Möglichkeit,  ohne den Konsistenzstatus aufrechterhalten zu müssen, auf den im Snapshot eingefrorenen konsistenten Status zuzugreifen.
Bei VMware werden bei einem VM Snapshot die Daten der aktuell laufenden VM in einen separaten Storageplatz gelegt. Wird nach dem Backup der Snapshot aufgelöst, werden portionsweise diese Daten in den ursprünglichen Storage-Bereich der VM übertragen. Dies verursacht für eine kurze Zeit sehr viel Random Write I/Os.  Wird eine dieser Daten -„Portionen“ zurückgeschrieben, wird die VM kurz eingefroren bis Datenmenge der „Portion“ geschrieben wurde. Dies dauert in der Regel nur einige Millisekunden und die VM läuft aus Sicht des Benutzer ohne Ausfall weiter. Es kann jedoch vorkommen, dass das Zurückschreiben  etwas länger dauert und die VM gerade dann nicht - oder verzögert den Heartbeat sendet. Es kann dadurch zu einem Schwenk des DAG Clusters kommen. Auswirkungen siehe oben.
Um dies zu vermeiden gilt es folgendes zu beachten:

  1. Verwendung von schnellem Storage für die Exchange Server damit das Schreiben der Snapshot commits nur sehr kurz dauert.
  2. Erzeugen von möglichst wenig Änderungen in der Zeit des Backups, damit weniger Daten vom ausgelagerten Snapshot Bereich zurück geschrieben werden müssen.
    a. Deaktivierung von Hintergrunddiensten von Exchange in dieser Zeit (z.B. Datenbank Aufräumservicezeit in den Datenbankoptionen)
    b. Möglichst wenig Usertraffic => Backup Zeit so legen, dass möglichst wenig Benutzer arbeiten.
    c. Falls möglich Mails im E-Mail-Annahmeserver in dieser Zeit cachen und erst danach an die Datenbank DAG Server weiterreichen.
  3. Möglichst viel Storage Performance Ressourcen freihalten. I/O Belastung des Storage möglichst klein halten.
    a. Keine anderen Backupjobs auf oder von dem Storagesystem, das die Exchange Datenbanken hält, laufen lassen.
    b. Möglichst wenig Hintergrundbelastung auf dem Storagesystem verursachen (z.B. SQL Batch Läufe die meist nachts laufen)
    c. Keine Virus Scans, Viren Signaturverteilung und Windows Updates in dieser Zeit,  => belasten Storage Systeme
  4. Verwendung der neuesten Veeam Backup & Replication Version bzw. der neuesten anderen Backup Software (meist neuestes VMware VDDK Kit integriert). Installation von aktuellen Patches der vSphere Umgebung (wichtig)
  5. Zweingend ist das Hochsetzten der Cluster Heartbeat Timeout Zeit notwendig:
    cluster /prop SameSubnetDelay=2000:DWORD
    cluster /prop CrossSubnetDelay=4000:DWORD
    cluster /prop CrossSubnetThreshold=10:DWORD
    cluster /prop SameSubnetThreshold=10:DWORD

    Ein Neustart scheint hier nicht erforderlich, da das DAG Cluster die Änderungen sofort annimmt.
  6. Falls dies alles nichts geholfen hat, kann in Abstimmung mit VMware folgender VMX Eintrag bei den DAG Member VMs (Offline) gesetzt werden.
    snapshot.maxConsolidateTime = "1"
    1 entspricht 1 Sekunde
    Dies setzt die Zeit für das Schreiben der Snapshot Restore „Portionen“ herunter, was dazu führt, dass wir nicht in den Heartbeat Timeout laufen. Dies sollte in Abstimmung mit dem VMware Support erfolgen, da der Schalter undokumentiert ist. Weiterhin sollte man mit einem Überwachungstool (Veeam ONE, vCOPS) das Snapshot Alter der VM überwachen (Länger als 10 Stunden=Alert), um zu prüfen ob der Snapshot auch wirklich immer sauber aufgelöst wird und wie lange dies dauert.

    *UPDATE1* Neuer Text
  7.  Hat dies alles nichts geholfen oder wollen Sie von vorne herein auf Nummer sicher gehen,  ist ein DAG Member zu installieren, welcher nur inaktive Datenbankrepliken aller DAG Members enthält. Nur dieser Server ist dann zu sichern. Da es hier durch Snapshot commit zu keinem Clusterschwenk kommen kann umgehen wir hier das Problem. Beim Restore kann Veeam hier einzelne Objekte (z.B. Mails) mit dem Veeam Explorer for Exchange zurückspielen. Das nach erfolgreichem Backup stattfindende truncaten der Logs wird durch Exchange automatisch an alle Member weitergereicht.
  8. *UPDATE2* Neuer TextWird Veeam Backup & Replication eingesetzt kann es helfen Forward Incrementals mit Syntetic Fulls zu verwenden. Soll aus Platzgründen Reverse Incremental verwendet werden kann anstatt dessen auch Forward Incremental mit Syntetic Fulls und TÄGLICHEN Transform into Rollbacks die bessere Wahl sein.
  9. *UPDATE2* Neuer TextvSphere 4.x legt die Snapshot Dateien in der Regel neben das VMX File. Ist dieses Volume nicht schnell genug kann es zu Snapshot auflösen Problemen kommen (siehe oben). Lässt sich anpassen.
    vSphere 5.x legt die Snapshot Dateien neben die passenden VMDKs und kann helfen das Problem zu beheben.
  10. *UPDATE3* Neuer Text Mit Version 7 bringt Veeam dire Möglichkeit mit in der Enterprise Plus Version Storage basierte Snapshots zu Entlastung von VMware VM Snapshots zu verwenden. Hier bei wird sofort nach dem VM Snapshot ein Storage Snapshot erzeugt und sofort wieder der VM Snapshot commited. In diesen Sekunden fallen nur wenige Änderungsdaten an und der Snapshot commit stellt keine Herausforderung mehr dar.

Zu 2) Fest in Exchange eingebautes Timeout für den VSS (Backup-) Konsistenzstatus von 20 Sekunden
Die weitere Herausforderung ist, dass in Microsoft Exchange fest hinterlegte Exchange VSS Writer timeout von nur 20 Sekunden. D.H. man hat 20 Sekunden Zeit Exchange in den Konsistenzmodus zu versetzten, einen VMware VM Snapshot zu erzeugen und den VSS Konsistenzstand wieder aufzulösen. Ist dies alles nicht innerhalb der 20 Sekunden passiert, löst Exchange den VSS Konsistenz Stand von alleine auf und es kommt in der Backup Software zu einem Fehler. Bei Veeam ist dies meist der VIX-Error.

Beim Backup wird folgendes Ausgeführt:
Non Veeam
VSS wird über Standard VMware Tools angesprochen (Non Application Aware Backup. Dies hat zur Folge, dass oftmals von MS dies als non supportet bezeichnet wird. Auch findet hier kein LogFile truncation statt


  1. Veeam verbindet sich über das vCenter oder dem ESX durch die VMware Tools hindurch auf den Exchange Server und startet den Veeam VSS Requestor on the fly. Alternativ verbindet sich Veeam über das Netzwerk zum Admin Share und übergiebt das den Veeam VSS Requestor dort. (Benötigt eine ausgeschaltete Windows UAC oder einen Benutzer mit exactem Namen und Rechten des „Administrator“)
  2. Alle VSS Writer werden ausgelesen (unter anderem auch Exchange) (manuell über „vssadmin list writers“ möglich)  und diese werden benutzt um die Konsistenz herzustellen.
  3. Ein VM Snapshot wird erzeugt.
  4. Der VSS Konsistenzstatus wird aufgelöst.
  5. Weitere Schritte (Backup)

Zwischen 2. wenn der Exchange VSS Requestor benutzt wird und 4. dürfen maximal 20 Sekunden vergehen. Dauert es länger, löst der Exchange Writer automatisch den Konsistenzstatus wieder auf. Es folgt ein VSS Error (dass der Konsistenzstatus hart von Exchange beendet wurde) und Veeam erzeugt einen Error „VIX“ bzw. andere Backup Software erzeugen hoffentlich auch einen Error.
Um dem Entgegenzuwirken kann man folgendes tun:

  1. Schnellen Storage verwenden (Block Storage für die Datastores meist weniger betroffen als NFS-Shares)
  2. Snapshot Zeit im vCenter überwachen. Zwischen Absetzten des Kommandos und Fertigstellen des Snapshots darf nur eine kurze Zeit (kleiner 10 Sekunden) vergehen.
    a. Je mehr Volumes die VM hat desto länger dauert der Snapshot
    b. Eventuell vCenter Performance optimieren (Patches, Leistung CPU RAM Disk I/O, richtige SQL Datenbank verwenden anstatt Express).
    c. Wenn alles nichts hilft, Hinzufügen des ESX Servers zu Veeam Backup und Auswahl des Exchange Servers per ESX Host und nicht per VCenter + Passendes setzen, dass die VM auf dem Host nur im HA fall wegmigriert wird)
  3. Umsetzten der Reihenfolge mit der Veeam der VM das Tool übergibt. Dies ist nur Erforderlich falls der Veeam Server nicht per Netzwerk auf den Admin Share des Servers zugreifen kann. Ist dies nicht Möglich wartet Veeam etwas und startet den Vorgang dann direkt über die VMware Tools. Wenn Sie also kein Zugriff per Netzwerk haben, macht es Sinn die Wartezeit für den Netzwerkconnect zu umgehen und gleich über die VMware Tools die Verbindung aufzubauen. Dies kann man erzwingen mit dem Registry Key: InverseVssProtocolOrder DWORD 1  (HKLM/Software/Veeam/Backup & Replication/) und Neustart der Veeam Dienste auf dem Veeam Backup & Replication Server in. Der Modus durch die VMware Tools ist an sich selbst langsamer und nur zu setzten wenn keine Netzwerkverbindung zwischen dem Veeam Server und dem Exchange Server möglich ist.
  4. Neustart des Servers vor dem Backup  (oder Neustart von COM+  und Exchange Dienste) ACHTUNG: Neustart nur des COM+ Dienstes behebt zwar den Fehler, leert aber die VSS Writer Liste für einige Zeit. Somit schließt der Backup Job erfolgreich ab (weil der Exchange VSS writer für die Backupsoftware nicht da ist und somit auch nicht verwendet wird), aber es wird KEIN konsistentes Backup erzeugt. Datenverlust/ Probleme beim Restore!
    Beim Neustart des Servers sind folgende Vorbereitungen zu treffen:
    a) Der zu verwendende Exchange DAG Server darf nur inaktive Datenbanken halten (1 Server für Backup.
    b) Um einen Clusterschwenk zu vermeiden, müssen a
    lle Datenbanken auf dem zu sichernden Server im DAG als nicht aktiv gehalten werden.
    c) Der Server wird mit einem Skript (Windows Taskplaner) kurz vor dem Backup neu gestartet. Dies führt in der Regel dazu, dass der Exchange VSS Writer deutlich weniger Zeit für die Konsistenz benötig.
    c) Wird der Server dann erfolgreich gesichert, werden automatisch auch die Logs der anderen Datenbankserver truncated. (Im Windows Ereignislog der Exchange Server gegenprüfen, wenn Sie keine Veeam Backup Server einsetzten)
  5. Mehr RAM/CPU Ressourcen am Exchange DAG Server
  6. Oftmals müssen auch mehr Disk Ressourcen für ALLE Volumes (auch OS) hinzugefügt werden.

Zusammenfassend möchte ich nochmals betonen, dass diese Herausforderungen auf Seiten VMware Snaphshot/Exchange Kombination liegen, dementsprechend sind viele Backuptools, die die VMware Schnittstellen für Backup nutzen, aber auch agentenbasierte Backuptools (20 Sekunden) betroffen.
Unter Hyper-V/Exchange/Veeam gibt es die VSS 20 Sekunden Timeout Herausforderung nur bei grottenschlechter Disk Performance, da ein Volume Snapshot im Storagesystem anstatt eines VM Snapshot (mit Snapshot commit Herausforderung) erzeugt wird.

Ich hoffe diese Informationen können helfen, Exchange DAG Cluster und Exchange Server erfolgreich zu sichern um somit auch einen erfolgreichen Restore anzubieten.

Für diejenigen, die Veeam Backupsoftware nicht einsetzten, empfehle ich auch einen Blick auf die kostenfreie Veeam Backup free Edition zu werfen. Mit ihr kann man auch einzelne Exchange Objecte (Mails usw.) aus einer mit einem anderen Backuptool gesicherten Exchange Datenbankdatei exportieren (PST) und in dem Produktions Exchange über Outlook (PST load) restoren. Hierzu müssen lediglich die Datenbank Dateien auf einem Medium liegen, dass die Veeam Software "Veeam Explorer for Exchange" lesen kann.

Happy Backup and Restore... Andy

Donnerstag, 22. November 2012

Neuer Beitrag auf

Hallo Leser,

kurzer Hinweis in eigener Sache.

Auf ist ein Beitrag von mir zum Restore Tiering veröffentlicht worden.

Happy reading....

Donnerstag, 8. November 2012

Veeam Exchange Restore Tools ab Backup & Replication 6.5

Hallo Leser,

da Veeam mit dem Veeam Explorer für Exchange (VEX) eine weitere einfachere Methode anbietet Exchange Objekte wieder herzustellen, treten immer häufiger Fragen auf welches Tools für was geeignet ist. Hier eine Übersicht:

Es gibt 2 Exchange Wiederherstellungstools:

VEX – Veeam Explorer for Exchange U-AIR Exchange Restore

VEX supported Exchange 2010 incl. Öffentliche Ordner auf VMware und Hyper-V

Hierbei wird im Hintergrund das Backup an unseren Veeam Server gemappt und VEX greift darüber auf die Datenbanken zu.

 U-AIR Exchange Restore
Supported Exchange 2003,2007 und 2010 auf VMware.

Der Datenbankserver wird mit einem Frontend hierbei in unserem VirtualLab per SureBackup Job gestartet.

Unser U-AIR Wizard greift darauf zu, vergleicht den angegebenen User bei Bedarf und zeigt die E-Mails für den Restore an. Die selektierte Auswahl wird dann in die Mailbox des angegebenen Benutzers kopiert (eventuell noch in einen anderen Ordner).

Öffentliche Ordner lassen sich nicht über den Wizard herstellen.

Es geht über Export in PST jedoch trotzdem.

Hierzu wird ein Outlook Client virtualisiert und in das Backup eingeschlossen.

Im VirtualLab wird dann der Outlook Client + Exchange Umgebung aus dem Backup gestartet und ich kann über den Outlook Client Objecte (inkl. Öffentliche Ordner) in eine PST exportieren.

Diese PST kann dann über den Veeam Server in die Produktionsumgebung als File exportiert werden und der Admin kann Sie einspielen.

Freitag, 26. Oktober 2012

Veeam Backup Sizing in größeren Enterprise Umgebungen *UPDATE2*

Hallo Leser,

ich werde heufig  von Partnern und Kunden nach dem Sizing in größeren Umgebung von Veeam befragt. Meine Einschätzungen finden Sie hierzu anbei. Bitte beachten Sie, dass dies Expliziet nicht auf kleinere Umgebung unter 100 Server zutrifft. Das hier dargestellte ist für einen Kunden der einige hundert Server am Hauptstandort hat und noch einige weitere Lokationen.

Das hier dargestellte kann nur als Hinweis versehen werden und stellt kein Verbindliches Setup dar.
Die von Veeam zur Verfügung gestellten Dokumente "Release Notes" & "UserGuide" sowie die Veeam Lizenzbedingungen sind maßgebend.

Ich gebe keine Gewähr auf Richtigkeit. Dies ist kein offizielles Veeam Statement. Änderungen und Fehler vorbehalten.

Für das Verständnis dieses Textes ist es erforderlich, dass Sie in den Veeam Produkten geschult sind.

Backup & Replication "Management" Server (je Lokation)
Für die Zentrale 4 virtuelle CPUs  (für kleinere Außenstandorte   2 virtuelle CPUs)
3GB + 350MB für gleichzeitig (current) gestartete Jobs
Disk 40GB + 10 GB per 100 VM (am Standort)
Win2012 recommended (wegen Gastrestore von Win2012 VMs)  ansonsten Win2008R2
(wenn hier der Enterprise Manager  oder Veeam ONE zusätzlich laufen soll, müssen dessen Ressourcen on Top hinzugefügt werden. Siehe unten)

Datenbank Server (Backup & Replication / Enterprise Manager)
Standard Datenbank auf MGMT Server (im B&R Setup enthalten) für bis zu 200 virtuelle Server Backup
Bei Standort größer 200 VMs muss die Datenbank  auf einem normalen MS SQL Server (keine Express Version) angelegt werden.
Es kann auch ein vorhandener Datenbankserver verwendet werden.
Ansonsten 4 (virtuelle) Kerne 4GB RAM
VM (oder Physik)
SQL2008R2  (oder 2005/2012)
Plattenperformance sollte ordentlich sein.

1 Enterprise Manager (1x weltweit)
4-8 Kerne 8GB RAM  (falls mehr)
Disk 40GB + 10 GB per 100 VM (weltweit)
ab 250VM sollte die Datenbank auf einen externen SQL Server (non EXPRESS) gelegt werden.

1 Hat der Kunde die Backup Enterprise Management Suite lizenziert muss ein Veeam ONE Server + Datenbankserver eingerichtet werden.
Das Sizing geht davon aus, dass Sie mehr als 400-1000 VMs im Veeam ONE Server einbinden wollen.
4-8 Cores oder vCPUs + 12GB RAM  (weniger VMs dementsprechend weniger Ressourcen)
100GB Platte auf ordentlichen Platten

Veeam ONE Datenbankserver (bei Backup Management Suite lizenziert)
Bis 200VMs SQL Express vielleicht ausreichend. Über Zeit vielleicht ein Problem aufgrund Datenmenge.
200-400VMs SQL (non EXPRESS) Datenbank > 4-8 Cores oder vCPUs + 12GB RAM 
Ab 400VMs eigener Server/VM mit im SQL Server nur der ONE Datenbank. > 4-8 Cores oder vCPUs + 12GB RAM 
Plattenperformance ist Key. => Schnelldrehende Platten im Raid 10 + separate Platten Raid10/1 für Logs im SQL.
Platten-Platz ergibt sich in der Regel aus den per Performance gesizten Raid 10 Systemen. Fragen Sie einen Veeam SE nach dem Veeam ONE Sizing calculator aus dem Veeam internen Forum für genauere Werte.

Allgemeine Infos Proxy- und Repository-Server
Proxy Server rufen die Daten von VMware ab.
Repository Server speichern die Daten auf Disk ab.

Proxy Server können physikalisch ausgelegt werden wenn die VMware Datastores als SAN oder iSCSI vorliegen. Hierbei werden alle VMware Datastore LUNs nach der Installation von Veeam an den Veeam Server gemappt.

Proxys können immer auch als VM ausgelegt werden. Hier wird mindestens 1 Proxy pro VMware Cluster benötigt (fast Restore).

 Im Schnitt werden 10VMs zu einem Job zusammengefügt => 1000VM => 100 Jobs. Diese können dann über das Backupzeitfenster verteilt werden. Z.B. 10 current Jobs pro halbe Stunde.

Die Backupinfrastruktur könnte dann z.B. für 10-20 gleichzeitig laufende Jobs ausgelegt werden.

 Je gleichzeitig laufendem Job wird folgende Ausstattung an den Proxy/Repository Servern benötigt:
2 Kerne/vCPU 2GB RAM

Es können beide Rollen von einem physischen oder virtuellen Server übernommen werden.
Die Anforderungen summieren sich dementsprechend auf!!!!!
Bei der Verwendung von CIFS Repositories übernehmen die Proxys die Rolle des Veeam Repositories mit. Hier also ebenfalls doppelte Anforderung (4 Kerne 4GB RAM)!!!!
Wird bei der Replikation der gleiche Server als Source- und Target-Proxy eingetragen ergeben sich hier auch doppelte Anforderungen (4 Kerne 4GB RAM)!!!!

Im Gesamten kann später die RAM Anforderung geprüft werden (Veeam ONE z.B.)
Ist die Peak Belastung unterhalb von 85% Gesamtarbeitsspeicher (innerhalb einer Woche gemessen) kann der RAM reduziert werden (15% Reserve überhalb des gemessenen Peaks noch lassen.)


Proxy Server
2virtuelle CPUs oder 2 Kerne je current Job welcher von dem jeweiligen Proxy gehandelt wird
2GB RAM für System + 2GB RAM je current Job welcher von dem jeweiligen Proxy gehandelt wird
40GB Disk (OS)
2x  8Gbps FC HBA oder Dualkarte (4Gbps nur falls kein 8Gbps LAN Netzwerk zur Verfügung steht)
Bei iSCSI - 10Gbe (oder mehrfach 1GBe falls kein 10GB möglich)
Ohne iSCSI (sprich wenn FC-SAN eingesetzt wird) reicht 1Gbe
Wenn als VM möglichst schnelles Netzwerk zwischen Proxy und Repository
Win2008R2 oder Win 2012

Restore Proxy (Optional wenn alle anderen Proxys physikalisch ausgelegt sind)
Falls die Proxy Server pysikalisch ausgelegt werden empfehle ich an größeren Standorten eine weitere VM hinzuzufügen als „Hot-Add Restore Proxy“
Diese VM kann auch ausgeschaltet werden und bei Bedarf dann eingeschaltet werden.
2GB RAM 2 virtuelle CPUs
40GB Disk (OS)
Win2008R2 oder Win2012
Oder mehr wenn mehrere VMs gleichzeitig Wiederhergestellt werden sollen (betrifft nicht Instant VM Recovery)


Repository Server
2virtuelle CPUs oder 2 Kerne je current Job welcher von dem jeweiligen Repository gehandelt wird
4GB RAM + 2GB RAM je current Job
40GB Disk (OS)
100GB Disk (möglichst schnell drehende Platten mit viel IO Performance oder (Desktop-) SSD für vPower NFS Verzeichnis)
Win 2012 bevorzugt (wegen Win2012 globaler dedup Möglichkeiten) ansonsten Win 2008R2  (bei NFS Shares als Backupziel muss Repository OS Linux (inkl.SSH/Pearl) sein)
10Gbe zwischen Repository Server und VMware ESX(i) Server Verwaltungsschnittstelle (oder mehrfach 1Gbe)
Möglichst schnelle Disks auf die gesichert werden können.

Sicherungsdisks (Target)
Block Level (SAN/iSCSI/SAS/LocalDisks) gegenüber CIFS/NFS bevorzugt.
NFS mit Linux Repository Server vor CIFS Share ohne Proxy Server bevorzugt.
Standard Storage vor Deduplication Storage System bevorzugt
Wenn Deduplication Storagesystem dann nach Möglichkeit mit undeduplizierter Cache Zone für aktuelle Backup Files.
Win2012 mit Windows Deduplizierung als Repository gut geeignet da es so eingestellt werden kann, dass nur ältere Dateien dedupliziert werden. (Schneller Restore/SureBackup vom aktuellen Stand)
Raid10 vor Raid5   (Raid 6 meist ungeeignet aber möglich)
15K Disks vor 10k Disks vor 7.2K Disks

Reverse Incremental am besten auf Raid 10 oder auf Storage Virtualisierung mit Raid5 im Hintergrund (4-5x höherer IO als Incremental Modus mit Syntetic Fulls) (Normaler Raid5 auch Möglich aber langsamer)

Incremental mit Syntetic Full für Raid5 Disksysteme und Deduplizierungs-Storagesysteme mit undeduplizierter Cache Landingzone

Incremental mit aktiven Fulls für Deduplizierungs-Storagesysteme die sämtliche Blöcke gleich beim schreiben deduplizieren.

Calculation for Forward Incremental                                                                                                                                  


Backup size = C * (F*Data + R*D*Data)                                                                                                                             



                Data = sum of processed VMs size by the specific job (actually used, not provisioned)                                                                                                              

                C = average compression/dedupe ratio (depends on too many factors, compression and dedupe can be very high, but we use 50% - worst case)                                                                                                                

                F = number of full backups in retention policy (1, unless backup mode with periodic fulls is used)                                                                                                                       

                R = number of rollbacks (or increments) according to retention policy (14 by default)                                                                                                                

                D = average amount of VM disk changes between cycles in percent                                                                                                                  



Calculation for Reverse Incremental                                                                                                                                  


                Backup size = C * (F*Data + R*D*Data)                                                              

                Replica size = Data + C*R*D*Data                                                                                                                        


                Data = sum of processed VMs size by the specific job (actually used, not provisioned)                                                                                                              

                C = average compression/dedupe ratio (depends on too many factors, compression and dedupe can be very high, but we use 50% - worst case)                                                                                                                

                F = number of full backups in retention policy (1, unless backup mode with periodic fulls is used)                                                                                                                       

                R = number of rollbacks (or increments) according to retention policy (14 by default)                                                                                                                

                D = average amount of VM disk changes between cycles in percent                                                                                                                  

Beispiel aus der Praxis:
Kunde 1000VMs 100TB an VMware den VMs zugewiesener Kapazität.
Tägliches Backup von Mo-Fr mit Reverse Incremental und 14 tägiger Aufbewahrungsfrist.
40TB BackupDisk Space (Kunde hat noch Luft zum wachsen)

Kunde hat
4x Proxy mit 2x QC CPU und 24GB RAM  (1 Server kann Ausfallen bzw. für Update zu neuen Versionen in das Testsystem integriert werden) 2x 8Gbps FC HBA
2x Repository Server 2x QC CPU mit 48GB RAM
1VM für Verwaltung und Enterprise Manager  8 virtuelle CPUs mit 32GB RAM
Die 1000VMs sind verteilt auf 120 Jobs

Standard, Enterprise oder Management Suite Version
Ich würde dem Kunden beim Backup immer mindestens Enterprise anbieten wie sämtliche Restore Möglichkeiten enthalten sind. Macht der Kunde ausschließlich Replikation kann auch die Standard Version verwendet werden.
In den Enterprise Projekten würde ich allerdings immer die Management Suite anbieten, da hier Erweitertes Backup Reporting möglich ist. Z.B. Reports wie "Gibt es VMs die noch nicht im Backup hinzugefügt wurden und wer hat Sie wann erstellt" oder "Gibt es VMs die Seit X Tagen kein Erfolgreiches Backup haben" und "Läuft mein Backup Storage in nächster Zeit voll?" + weitere Tools zur Dokumentation, Kapazitätsplanung und Change Management

Gruß Andy

Freitag, 29. Juni 2012

Mein neues Whitepaper zum Thema: Wie integriere ich Veeam Backup & Replication in den IBM Tivoli Storage Manager (TSM)

Hier erfahren Sie wie Sie einer bestehenden IBM TSM Umgebung die erweiterten Vorteile von Veeam Backup & Replication für Virtualisierungs-Backup hinzufügen können.
  • Übersicht über die Veeam Backup & Replication Vorteile in Verbindung mit Ihrer bestehenden IBM TSM Lösung
  • Integration von Veeam Backup & Replication in IBM TSM inkl. der ausführlichen Darstellung aller Einstellungsmöglichkeiten
  • 3 Integrationsbeispiele aus der Praxis

Mittwoch, 23. Mai 2012

Anzeigen welcher Port von welchem Dienst belegt ist (Windows)



netstat -nba

erfährt man welche Netzwerkports bei einem System belegt sind und welche Anwendung dahinter steckt.

Es kommt ja ab und zu vor, dass 2 Webserver installiert werden  (vcenter + IIS) und man kann hiermit eine Fehleranalyse betreiben.

Gruß Andy

Montag, 7. Mai 2012

VMware Performance-Unterschiede vRDM, pRDM und VMDK

Ich werde immer heufig gefragt ob nicht eine pRDM schneller ist als eine vRDM.
Die Performance ist laut VMware fast gleich:

Bei einer vRDM oder VMDK lässt sich ein Snapshot erzeugen und ich kann somit ein Virtualisierungsbackuptool wie Veeam Backup & Replication incl. dem Anstarten im Fehlerfall direkt aus dem Backup (1 Minute + Serverboot dann ist Applikation für User wieder da) nutzen.

Das spricht eindeutig für die Nutzung von VMDKs oder VRDM.

Max. 2TB je Laufwerk

Microsoft Qorum Cluster Disks (enthalten keine Daten) müssen pRDM bleiben.

Gruß Andy

Dienstag, 24. April 2012

1TB Cloud Space für Veeam Kunden (Amazon Cloud)


falls jemand kein Problem damit hat, die Daten bei Amazon US liegen zu haben kann man hier 1TB Platz in der Cloud kostenfrei erhalten.

Freitag, 20. April 2012

Unterschied VMware VSS und Veeam VSS beim Backup

Hallo :-)

Ich werde bei meinen Präsentationen immer heufiger gefragt was an Veeam Backup & Replikation eigener VSS Backup Funktion besser sein soll als bei VMware eigenem VMware Tools VSS.

Für ältere Betriebssysteme nur Filekonsistenz.
Für neuere Betriebssysteme auch Datenbank und Applikationskonsistenz.

Datenbank-, Applikations- und Filekonsistenz
+ Log File Behandlung der Datenbanken
+ Setzten der VSS Writer Applikationseigenen Schalter die nach dem Neustart (Restore) des Servers nach Microsoft Best Practices greifen. Z.B. Nach dem Restore wird die Datenbank automatisch in den Restore Modus versetzt. Bei Active Directory => Non-Authorative Restore Modus.
Veeam kümmert sich also auch um die Applikationen und Datenbanken wie ein Backuptool das eben so tut. Alle anderen die das Standard VSS von VMware nutzen brauchen noch Agenten für die jeweiligen Applikationen (Restoremodus + Log-File Behandlung).

Eine echt gute Erklärung findet Ihr auch hier:

CU Andy

Sonntag, 4. März 2012

IBM uses Veeam Backup & Replication 5 - Replication feature for a SONAS + VMware DR Solution

Hello everybody!If you need a realy huge Network Attached Storage System for VMware Environments have a look at the IBM Scale Out Network Attached Storage System - SONAS (up to 21 petabytes). SONAS is a hardware grid based storage system and is a advancement of the IBM Scale out file services (service offering of IBM - grid based with a maximum filesystem capacity of 33554432 Yobibytes).
IBM released a whitepaper that uses Veeam Backup & Replication 5 - Replication feature for a SONAS + VMware DR Solution. (Public link)

CU Andy

Mittwoch, 1. Februar 2012

Einrichtung Veeam Backup & Replication VirtualLab

Hi zusammen,

in der Regel legen Ihnen unsere Partner bei der Installation von Backup & Replication Enterprise mindestens ein VirtualLab in Ihrer Umgebung an.
Falls Sie dieses jedoch selbst ausführen wollen, habe ich hier ein paar Hintergrundinformationen auf deutsch zusammengetragen. (Screenshots folgen)

Das VirtualLab ist eine Sandboxumgebung in der Server getrennt von Ihrer produktiven Umgebung zusätzlich gestartet werden können.

Auf diese wollen Sie ja eventuell von einem Adminrechner aus zugreifen um Tests auszuführen oder um z.B. eine E-Mail wieder herzustellen.

Wir benötigen also vom Admin Rechner aus einen Zugriff.

Ebenfalls benötigt der Veeam Server für die Wiederherstellungsprüfung (SureBackup) Zugriff auf die im Lab gestarteten VMs. Der Veeam Server hängt jedoch auch im produktiven Netzwerk.

Da die Systeme wenn Sie im VirtualLab gestartet werden ebenfalls die gleichen Netzwerkeinstellungen besitzen wie im produktiven Bereich, können diese nicht einfach in das produktive Netz zusätzlich gehängt werden.

Wir richten also ein VirtualLab ein das eine abgeschottete Sandboxumgebung darstellt.

Im VirtualLab Wizard kann angegeben werden, dass wenn eine VM eine Netzwerkkarte im Netzwerkswitch „VMnetwork“ besitzt, automatisch wenn Sie im VirtualLab gestartet wird (im neu angelegten) „VMnetwork_VirtualLab1“ Switch umgehängt wird.


Produktiver Server gestartet mit Netzwerkkarte im virtual Switch „VMnetwork“
Vom Backup gestarteter gleicher Server mit Netzwerkkarte im virtual Switch „VMnetwork_VirtualLab1“

Um jetzt eine Netzwerkkommunikation vom Adminrechner/Veeam Backup & Replication zu ermöglichen richten wir eine VM ein die bei Bedarf gestartet wird und sowohl in den produktiven Netzen als auch in allen VirtualLab Netzwerken eine Netzwerkkarte besitzt. Diese VM wird automatisch von dem VirtualLab Wizard installiert und eingerichtet. => Virtual Lab Appliance.

Um dies einzurichten müssen im VirtualLab Wizard bestimmte angaben gemacht werden.

Z.B. welche IP Adresse unsere Appliance auf der produktiven Seite besitzt...
... und welche IP Adresse auf der jeweiligen VirtualLab Netzwerkkarte müssen eingestellt werden muss. Hier wird zwingend die Gateway Adresse des jeweils zugehörigen (produktiven) Netzwerks gesetzt.

Somit ist die VirtualLab Appliance imm produktiven Netzwerk mit der von Ihnen gesetzten Netzwerkadresse erreichbar und in den VirtualLab Netzwerken mit der jeweiligen Gateway Adresse.

Produktiver Server gestartet mit Netzwerkkarte im virtual Switch „VMnetwork“
Vom Backup gestarteter gleicher Server mit Netzwerkkarte im virtual Switch „VMnetwork_VirtualLab1“
VirtualLab Appliance mit einer IP Adresse im produktiven Bereich erreichbar.
VirtualLab Appliance in den VirtualLab Netzwerken (z.B. „VMnetwork_VirtualLab1“) mit der jeweiligen Gateway Adresse erreichbar.

Damit wir jetzt vom Admin oder Veeam Rechner in die in den VirtualLab Netzwerken gestarteten Server zugreifen können benötigen wir einen Trick.

Wir definieren ein Subnetz, dass Sie normalerweise nicht in Verwendung haben und legen das über Ihr VirtualLab Netzwerk.

Unsere VirtualLab Appliance nimmt für dieses Netzwerk Anfragen entgegen und wandelt diese in Anfragen an die im VirtualLab gestarteten Server um.

Ihr Server hat im produktiven Bereich eine IP Adresse Subnetmask
Sie definieren das spezielle VirtualLab Netzwerk als Subnetmask
Wenn jetzt an der VirtualLab Appliance jemand nach frägt, nimmt die VirtualLab Appliance die Anfrage entgegen und leitet diese an im VirtualLab weiter.

Die VirtualLab Appliance verwendet hier eine Kombination aus verschiedenen Netzwerktechnologien (NAT, Bridging, …).

Damit jedoch die Anfrage überhaupt an die VirtualLab Appliance weitergeleitet wird, stellt unser Wiederherstellungswizard oder der Backup & Replication Server im Rechner temporär einen Routingeintrag ein.

Z.B. Mask ist über die IP Adresse der VirtualLab Appliance im produktiven Netzwerk erreichbar. Um eben Sicherzustellen dass die Anfrage an den nicht an das Gateway weitergeleitet wird, sondern an die VirtualLab Appliance die wiederum die Anfrage in den im Lab gestarteten Server durchreicht. 

Das VirtualLab Setup: (Jeder Punkt eine Konfigurationsseite im Wizard)

-          Name für das virtual Lab auswählen
-          ESX(i) Host auswählen auf dem das VirtualLab eingerichtet wird.
-          (freie) IP Adresse im produktiven Bereich angeben
-          VMware Switche/VLANs auswählen die VMs enthalten und einen entsprechenden Virtual Lab Namen setzten.
               z.B.        „VMNetwork“ => „VMNetwork_VLAB1“
                               „DMZ“                  => „DMZ_VLAB1“
-          Im nächsten Fenster müssen Sie für jedes gewählte Netzwerk eine IP Adresse und Subnetz welches über das jeweilige VLAB Netzwerk gelegt wird.
               Ihre Prdouktiven Netzwerke:      „VMNetwork“  Gateway Router hat die IP
                                                                                „DMZ“          Gateway Router hat die IP

Somit geben Sie hier z.B. an.

               VMNetwork_VLAB1 hat die IP Adresse / und das darüber gelegte Netzwerk hat z.B. 192.168.100 (Eingabemaske lässt nicht mehr Stellen zu)

               DMZ_VLAB1 hat die IP Adresse / und das darüber gelegte Netzwerk hat z.B. 10.100  (Eingabemaske lässt nicht mehr Stellen zu)

-          One-to-One NAT einfach freilassen.
-          Fertig

Dieses Blog durchsuchen