Exchange Backup extrem
Diese Seite beschreibt alternativen Überlegungen zur Sicherung und Wiederherstellung von Exchange. Dies ist eine Kurzfassung ohne Anspruch auf Vollständigkeit und erst recht keine Anleitung. Diese Optionen sind für "Enterprise Kunden" zu evaluieren. Allen "normalen" Exchange Administratoren empfehle ich ein ordentliches Online Backup (Siehe Exchange Backup und Restore und NTBACKUP)
Unterstützung durch
Net at
Work:
Sie können mich gerne mit einer Konzeption für ihre individuelle
Backupanforderungen beauftragen. Speziell wenn es um SAN, Library,
Hochverfügbarkeit und kurze SLAs geht, können aus verschiedenen Bausteinen und natürlich einer entsprechenden Schulung der Mitarbeiter leistungsfähige
Lösungen entstehen.
"virtual machine snapshots aren't application aware,
and using them can have unintended and unexpected consequences für a
server application that maintains state data, such as Exchange. As a
result, making virtual machine snapshots of an Exchange guest virtual
machine isn't supported."
Quelle:
http://technet.microsoft.com/en-us/library/aa996719.aspx
Grundlagen
Ehe ich ihnen ein paar Optionen für Sicherungen vorstelle, sollten wir uns ein paar Dinge klar machen:
- Ein Backup ist immer
erforderlich
Wer nur eine Instanz seiner Daten hat, handelt nicht nur fahrlässig. Und es sollte auch nicht nur eine "Kopie" eines Datenbestandes vorhanden sind. - Intervall des Backups
Klar ist eine regelmäßige Erstellung einer Sicherung. Exchange DAG-Replikationen sind ein Extrembeispiel, weil die Datenbanken quasi kontinuierlich auf andere Server repliziert werden. Relevant ist hier der RPO (Recovery Point Objective), d.h. wie viele Daten im Falle maximal verloren gehen dürften. Dies gibt die maximale Zeit zwischen zwei Sicherungen vor. - Backup mit minimalem
Einfluss auf den Betrieb
Auch Sicherungen belasten das System aber diese Auswirkungen sollten gering sein. Daher muss überlegt werden, ob z. B. jedes Mal die komplette Datenmenge kopiert und damit Disk-IO, PCI-Bus-Belegung, SAN-Belastung und Netzwerkverkehr "kosten" oder ob differenzielle oder inkrementelle Sicherungen eignen. Es gibt verschiedene Optionen um die Wege zu optimieren, verkürzen oder zu umgehen oder die Datenmengen zu reduzieren. - Restore mit maximalem Speed
Sollte dann einmal der Fall eintreten, dass eine Wiederherstellung erforderlich ist, dann muss das Restore natürlich mit maximaler Geschwindigkeit erfolgen können.
Die Datenmengen in Exchange und anderen Systeme wachsen von Tag zu Tag. Zeitgleich werden die Ansprüche an die Wiederherstellung und Verfügbarkeit immer höher, so dass das klassische "Vollbackup auf Tape" selbst mit einem dedizierten BackupServer nicht immer zu erreichen ist.
Das Wunder der Replikation
Für die meisten Lösungen wie ist die Replikation ein Hilfsmittel zur Erhöhung der Verfügbarkeit, da die erste Kopie zugleich auch als produktive Instanz im Fehlerfall genutzt werden kann. Zugleich ist es natürlich eine erste "Kopie" und damit eine Sicherung der Daten. Möchte man weitere Kopien (sprich Backups) anfertigen, dann kann dies von dieser Kopie erfolgen und belastet den Hauptserver nicht. Zudem der Abstand zwischen zwei Sicherungen bei einer synchronen Replikation 0 Sekunden so dass im Fehlerfall kein Datenverlust (RPO) zu befürchten ist. Weiterhin ist die Kopie ebenfalls in sehr kurzer Zeit (z.B. Sekunden) wieder verfügbar, so dass auch die Wiederherstellungszeit (RTO) minimal ist. Abgesehen von einer ersten kompletten Kopie werden danach nur noch Differenzen übertragen, so dass auch dies die Systembelastung reduziert.
Es gibt verschiedene Optionen der Replikation.
Datenbestand | Replikation | RPO | RTO | Beschreibung |
---|---|---|---|---|
Exchange Mailbox |
CCR, LCR, DAG |
<5 MB |
<1Min |
Exchange 2007 hat damit angefangen, dass eine EDB-Datei auf einem zweiten Server (CCR) oder einer zweiten Disk (LCR) als Kopie vorgehalten werden konnte. Exchange 2010 hat diese Verfahren verbessert, indem mehr als nur eine Kopie bereitgestellt werden kann und die Replikation auch direkt (statt Log-Shipping) erfolgen, was die RPO weiter reduziert. |
Exchange Public Folder (Bis 2010) |
PF Replikation |
<15 Min |
Min |
Seit es öffentliche Ordner gibt, können Administratoren die Inhalte auf mehrere Server replizieren. Die Latenzzeit ist eher hoch und es ist keine Datenbank sondern eine Inhaltsreplikation. Aber wenn diese gut überwacht und konfiguriert wird, erhält man so eine "Kopie" auf weiteren Servern. Bei Exchange 2013 sind die Public Folder in Mailboxdatenbanken gewändert, so dass Aussagen zur EDB-Replikation anzuwenden sind. |
SQL (ab 2008R2) |
Mirroring |
<Min |
<Min |
Auch SQL 2008 kann analog zu Exchange 2007 eine Datenbank auf einen anderen SQL-Server replizieren und damit eine erste "Kopie" erzeugen, die beim Ausfall sogar live gehen kann. Allerdings muss die Clientanwendung den "Switch" auch unterstützen. |
Hyper-V |
Mirroring |
<Min |
<Min |
Auch hier können mittlerweile VHD Dateien auf zwei Servern (Cluster) repliziert werden. |
Dateisystem |
DFS Replication |
wenige Min |
<Min |
Windows selbst nutzt DFS um z.B. Dateifreigaben SYSVOL und NETLOGON auf allen Domänencontrollern "hochverfügbar" und Synchron bereit zu stellen. FRS kann aber auch Nutzdaten replizieren und damit Daten eines Dateiserver auf einem anderen System synchron halten |
Dateisystem |
XCOPY/Robocopy/Rsync |
Dauer des Scan/Copy-Durchlauf. |
? |
Ich habe auch schon Lösungen gesehen, bei denen ein "XCOPY /MIR" oder "ROBOCOPY" ausgewählte wichtige Daten von einem Quellserver regelmäßig uaf einen Zielserver übertragen haben und damit eine Kopie anlegen, Verbindet man dies mit der Funktion "Vorherige Version" (Schattenkopien) im Ziel, kann dies auch eine Komponente einer Backupstruktur sein. Knifflig wird es nur z.B. bei Access Datenbank etc., da keinerlei Konsistenzsicherung auf der Quelle stattfindet |
Storage + VSS |
RAID1 |
0 |
0 |
Auch RAID-Level stellen streng genommen Replikate der Daten bereit, aber würde ich nicht als Backup ansehen, da eine logische Korruption der Dateistruktur immer beide Disks betrifft. Da hilft dann auch keine "Vorherige Version", die per Schattenkopien erstellt werden könnte |
Storage |
EMC BCV, Snapshot |
0-x Min |
0-x Min |
Anders sieht es aus, wenn die "Snapshots" durch das Storage-System selbst erstellt werden und damit auch eine logische Korruption in der Disk zurückgedreht werden kann.. Verschiedene SAN-und Softwarehersteller bieten auch die Replikation von LUNs auf verschiedene Storage-Systeme an, so dass damit die Daten auch örtlich getrennt sind. Einige dieser Replikationen können sogar zeitlich gesteuert werden. Weitere Kopien der Kopie belasten den Server dann nicht. Selbst eine zeitliche Steuerung ist möglich, wobei bei einem Resync dann idealerweise nur die geänderten Blöcke übertragen werden |
Disk |
DPM |
z.B. 15 Min |
|
Eine Besonderheit beim Backup ist der Microsoft Data Protection Manager. Er sichert die Quelle über Schattenkopien und baut auf dem DPM-Server quasi eine Kopie der Partition auf, die bei weiteren Backups einfach fortgeschrieben wird. per Schattenkopien-Versionierung auf dem DPM-Server werden so mehrere Generationen bereit gestellt. |
Workstation |
SBS2011, Win2012 Essentials |
1-2 Tage |
Stunden |
Der Vollständigkeit wegen sei auch mal das Backup erwähnt, mit dem früher mein Windows Home Server und nun der Windows 2012 Essentials meinen Notebook sichert. Auch hier wird eine konsistente VSS-Instanz erzeugt und dann nur das vergangene Delta gesichert. |
Ich denke es ist nun gut zu verstehen, warum immer mehr Produkte auf Replikation setzen.
Wegewahl
Auf der Seite Backupkonzepte finden Sie eine Beschreibung der unterschiedlichen Wege. Mittlerweile wurde das Bild der Server durch Virtualisierung deutlich erweitert.
Weg | ||
---|---|---|
Lokales Backup |
|
|
Gast via LAN |
|
|
Host via LAN |
|
|
Host via SAN Snapshot |
|
|
Host via SAN auf Tape |
|
|
Option: Sicherung per Schattenkopie (VSS Online)
Exchange 2003 unterstützt Schattenkopien (Siehe auch Windows 2003 Schattenkopien) und da liegt es doch nahe, diese Funktion auch zu nutzen. Leider unterstützt Microsoft NTBACKUP zwar Schattenkopien, aber nicht den Exchange Teil. Sie können also mit Schattenkopien Exchange aktuell nur dann sichern, wenn Sie eine Drittsoftware einsetzen.
Wenn eine Sicherungssoftware nun eine Schattenkopie anfordert, dann wird Exchange über den VSS-Writer so gesteuert, dass es alle offenen Transaktionen abschließt und für bis zu 20 Sekunden keinen Schreibzugriff mehr auf Datenbank und Transaktionsprotokolle durchführt. In dieser Zeit kann ihre Lösung dann die Festplatte irgendwie "sichern". Nun wird es so schnell keine Lösung schaffen, mehrere Gigabyte in weniger als 20 Sekunden physikalisch kopieren kann, aber das ist ja auch erst einmal gar nicht nötigt. Es gibt einfach ein 20 Sekunden Zeitfenster, in der ein Schnappschuss der Partition mit einem Mittel ihrer Wahl durchgeführt werden kann.
- VSS Shadow durchführen
danach benötigen Sie Zugriff auf diese Schattenkopie. Einige Produkte "kopieren" dazu die Schattenkopie mittels "VSS Copy" auf ein eigene Festplatte oder Sie können auch ein Laufwerk mit der Schattenkopie (ReadOnly) verbinden - Prüfen der Datenbank mit ESEUTIL
Eine "Kopie" einer Datei bedeutet nicht, dass diese konsistent und fehlerfrei ist. ESEUTIL erlaubt einen Test und kann auch per Kommandozeile gesteuert werden. - Sicherung der Datenbank
Wenn die Datenbank korrekt durch die Schattenkopie kopiert wurde, dann können Sie diese nun auf das Bandlaufwerk verschieben. - Logfile abschneiden
Über die gleiche VSS-API kann die Sicherung das erfolgreiche "Backup" an Exchange mitteilen, so dass Exchange die Transaktionsprotokolle bis zur Schattenkopie abschneidet
Diese Art der Sicherung ist mittlerweile bei fast allen Backupprodukten verfügbar. Hinderlich ist dabei sicherlich, dass diese API weder per VBScript nicht mit NTBACKUP nutzbar ist, sondern Dritthersteller in ihrem Backupanwendungen diese Funktionen nutzen müssen
Aber auch wenn Backupprodukte eine Sicherung per Schattenkopie anbieten, gilt es die ein oder andere Falle zu umgehen oder Einschränkung zu können.
- VSS und Recovery Storage Group
Exchange 2003 VSS Backups können NICHT in eine Recovery Storage Group (MSXFAQ.DE - Recovery Storage Group) restauriert werden. Das geht erst mit Exchange 2007 - Umleitung
Auch die Umleitung von Backups bei der Wiederherstellung in ein anderes Verzeichnis ist mit Exchange 2003 anscheinend nicht möglich, sondern erst ab Exchange 2007 verfügbar. Der VSS-Requester bietet die Funktion nicht an. Allerdings wird es dann auch wieder einige Zeit dauern, bis die Hersteller diese Funktion anbieten - Ausschluss der EDB
Sichern Sie auch das Dateisystem über Schattenkopien, dann müssen Sie die Exchange Datenbankendateien (EDB/STM) aus der Sicherung ausschließen. BackupExec weist z.B. darauf hin, dass beim Einsatz der AOFO (Advanced Open FileOption) sogar eine Beschädigung der Datenbanken auftreten könnte
Insofern ist die Sicherung per Schattenkopie zwar eine saubere und stabile Lösung, die aber mit Exchange 2003 noch ein paar Einschränkungen hat. Es ist aber speziell für Firmen mit hohen Ansprüchen an eine schnelle Sicherung und besonders eine schnelle Wiederherstellung der beste Weg, dies mit entsprechender Hardware zu erreichen. Schattenkopien können nämlich auch genutzt werden, um in Verbindung mit entsprechender SAN-Hardware auch ein "Serverless Backup und Restore" zu ermöglichen. Hier mal ein paar Screencaptures von BackupExec 11d:
Wenn Sie auf der Karte für "Advanced File Option" die Unterstützung von Schattenkopien oder kompatiblen Funktionen aktiviert haben, dann nutzt BackupExec auf für Exchange diese Funktion. Zusätzlich können Sie auf der Exchange Karteikarte hinterlegen, dass er noch schnelle eine Konsistenzprüfung der Schattenkopie vornimmt. Auch die Unterstützung von Exchange 2007 LCR bzw. CCR Cluster ist vorhanden.
- Best Practices für using Volume Shadow Copy Service with Exchange
Server 2003
http://www.microsoft.com/technet/prodtechnol/exchange/2003/vssbp.mspx - Backups fail due to consistency check failure…
http://blogs.technet.com/b/timmcmic/archive/2012/03/29/backups-fail-due-to-consistency-check-failure.aspx - 822896 Exchange Server 2003 Data Backup and Volume Shadow Copy Services.
- Exchange Server 2007 - Restoring to a Recovery Storage Group
http://msdn2.microsoft.com/en-us/library/aa579367.aspx
The Exchange Server 2007 writer adds the ability to restore data directly to recovery storage group. - Exchange Server 2007 - VSS Frequently Asked Questions
http://msdn2.microsoft.com/en-us/library/aa579091.aspx
Can I restore a shadow copy to the recovery storage group?
Yes. Requestor must restore the files to the correct file paths and specify the location by using SetRestoreOptions() and AddNewTarget(). - Exchange 2003 - VSS Frequently Asked Questions#
http://msdn2.microsoft.com/en-us/library/ms986575.aspx
Can I select an individual database to restore?
Yes. Although only entire storage groups can be backed up, you can select individual databases to be restored
Can I restore a shadow copy to a different location on the same server?
No. Shadow copy backups must be restored to the same drive and directory from which the original backup was made
Can I restore a shadow copy to the Recovery storage group?
No. - BackupExec - What is the intended use of the Open File Option and
the Advanced Open File Option?
http://seer.support.veritas.com/docs/263784.htm
Be sure to clear, from all backup jobs, the data locations für the applications that use a database agent when configuring a backup job, unless the application's services are stopped during the time of the backup.
Microsoft Exchange: Clear all .edb files
Failure to clear these files can cause data corruption - IBM TSM
http://publib.boulder.ibm.com/infocenter/tivihelp/v1r1/index.jsp?topic=/com.ibm.itsmfm.doc/ab5ex00374.htm
VSS-Zurückschreibungen ignorieren die Wiederherstellungsspeichergruppe und werden direkt in die Produktionsdatenbank gestellt. - Best practices when imaging an Exchange Server with Backup Exec
System Recovery or LiveState Recovery
http://entsupport.symantec.com/docs/n2005091309295060 - Symantec Backup Exec System Recovery and Volume Shadow Copy Service
(VSS)
http://entsupport.symantec.com/docs/n2004111916582360 - Storage-Management mit Windows Server 2003 (Gastbeitrag tecCHANNEL)
http://www.microsoft.com/germany/technet/datenbank/articles/600448.mspx - HP StorageWorks Application Recovery Manager Software overview
http://h18006.www1.hp.com/products/storage/software/arm/index.html?jumpid=reg_R1002_USEN
Option VSS + Offline
Aber auch wenn ihre Backuplösung keine Unterstützung ´für Exchange und Schattenkopien bietet, können Schattenkopien vielleicht eine sinnvolle Option sein. Voraussetzung ist aber dass ihre Sicherungssoftware zumindest Schattenkopien anfordern und Sichern kann. Dann könnten Sie folgendes durchführen:
- Exchange Datenbank beenden
Die Exchange Datenbanken können per Skript sehr schnell beendet werden. Wenn Sie dies nachts durchführen, wenn kaum Leute arbeiten und diese z.B.: per Outlook Cached Mode arbeiten, dann ist hier nur eine kurze "Downtime" zu bemerken - Schattenkopie
Da die Datenbank ja nun "offline" ist, ist diese auch nicht mehr im Zugriff und kann über die normale Schattenkopie des Dateisystems quasi gesichert werden. Der Prozess dauert ja auch nur wenige Sekunden. - Exchange Dienste wieder starten
Nun sollten Sie die Datenbanken wieder starten. - Zugriff auf die Schattenkopie
Nun kann ihre Sicherungssoftware einfach die Datei aus der Schattenkopie wegkopieren. Die Datenbank war ja "Clean Shutdown". Das können Sie auch problemlos noch mal mit ESEUTIL prüfen.
Durch dieses Verfahren haben Sie dann eine sehr schnelle "offline-Sicherung" von Exchange, die auch im Desasterfall sehr schnell wieder bereit gestellt werden kann. Allerdings gibt es da noch ein paar kleine aber wichtige Details zu klären:
- Kein automatisches Logfile löschen
Die Transaktionsprotokolle müssen Sie natürlich auch noch löschen. Vielleicht ist ein Differenz-Backup über die API hier der beste Weg. - DB Stop/Start muss geskriptet und überwacht werden
Das Stoppen und Starten der Datenbanken müssen Sie noch realisieren. - kurze Downtime beim User
Auch wenn der Downzeit vielleicht nur ein paar Minuten ist, so ist es eine kurze Ausfallzeit.
Insofern ist dieser Ansatz nur bedingt brauchbar.
Option Remote VSS, Hardware VSS
Ich habe mich hiermit noch nicht weiter beschäftigt, aber es ist nicht vorgeschrieben, dass der VSS-Writer auf die gleiche Festplatte schreibt. Theoretisch könnten über den VSS-Mechanismus die Daten sofort auf einer zweiten Festplatte geschrieben werden und bei der Ausführung eines Snapshot eben dort aktualisiert wird. Technisch sicherlich interessant.
Ebenso soll es mittlerweile SAN-Systeme geben, die einen "VSSCopy" selbständig in Hardware ausführen und das Hostsystem damit nicht mehr belasten
Option SAN Split online oder offline
Schon lange gibt es SAN-Systeme, die herrlich mit Festplatten und Kopien hantieren können. So gibt es von EMC schon viele Jahre die Funktion der "Business continuous Volumes", die, vereinfacht ausgedrückt, nichts anderes besagen, als dass man eine Festplatte auf eine andere Festplatte im laufenden Betrieb kopieren kann, die synchrone Kopie dann wieder abspaltet und die Daten darauf nutzt. Wird die Festplatte dann wieder an den Master angehängt, werden nur die in der Zwischenzeit geänderten Blöcke kopiert.
Windows und Exchange "merken" davon gar nichts. Da aber das SAN-System nicht weiß, ob gerade eine Transaktion stattfindet und in der Regel das SAN dem Server auch nicht sagen kann "halt mal kurz an", entspricht die Kopie in etwa einer Festplatte des Servers, der einfach ausgeschaltet worden wäre. Transaktionsorientierte Dateisysteme wie NTFS und Programme wie SQL und Exchange haben damit eher wenig Probleme. Aber was macht das SAN, wenn ein Block durch zwei Schreibbefehle erst komplett geschrieben wird (z.B. weil ihr Dateisystem eine andere Blocksize verwendet als der Massenspeicher ?), dann ist der Split eventuell unbrauchbar. Auch hier ist also eine "Prüfung" des Dateisystems und der Daten erforderlich.
Das Risiko können Sie natürlich vermeiden, wenn Sie die Datenbanken von Exchange einfach kurz Offline nehmen. Das geht mit Exchange 2000/2003 ja um einiges schneller als unter Exchange 5.5.
Man könnte die SAN-Split Funktion natürlich auch mit VSS kombinieren, so dass eine Schattenkopie vor dem Split zumindest für eine konsistente Schattenkopie sorgt. Statt des "Livesystem" nutzt man dann einfach die ein paar Sekunden alte Schattenkopie.
- Prüfung der Datenbank muss entwickelt werden
- Kein automatisches löschen der Transaktionsprotokolle
- optionales Stop/Start der Datenbank muss programmiert und überwacht werden
- optionale kurze Downtime beim User
- Restore bedeutet alte Platte "zurückspiegeln" oder live durch Backup
ersetzen
Wenn dann was schief geht, dann ist auch die Kopie weg, eventuell VSS als Hilfe - Kein Rollforward bei "aktivem Check
Wird die Kopie per ESEUTIL z.B.: "konsistent" gebracht, dann kann bei einem Fehler zwar die Datenbank von dem Zeitpunkt bereit gestellt werden, aber nachfolgende Transaktionsprotokolle werden natürlich nicht weiter eingespielt
Option Data-Replication
Die Angst vor dem Ausfall des Servers hat natürlich Dritthersteller schon lange vor der Funktion Local Continuous Replication auf den Gedanken gebracht, mittels Filtersoftware jeden Schreibbefehl auf eine lokale Festplatte auf einen zweiten Server zu kopieren. Da ist es natürlich auch eine Idee, den zweiten Server einfach als Backupquelle zu nutzen. Im Falle eines Ausfalls muss dieser Server ja auch alle Daten haben.
Auch hier muss natürlich hinterfragt werden, wie die Daten auf dem zweiten Server "gültig" sind. Wird dazu die Replikation einfach angehalten oder welche Optionen werden hier angeboten? Auch hier gilt:
- Prüfung muss entwickelt werden
- Kein automatisches löschen der Transaktionsprotokolle
- Zusatzsoftware
- Restore bedeutet Daten zurückkopieren
Aber der Gedanke einen Standby-Cluster weiter zu verwenden hat durchaus seinen Charme. Mit Exchange 2010 hat Microsoft mit der DAG die Funktion dann auch noch besser ausgeführt.
Option "Data Protection Manager"
Dass direkte Sicherungen vom Server zum Bandlaufwerk nicht mehr ausreichend sind, hat sich sicher schon herum gesprochen. Zum einen sind die Bandlaufwerke damit oft nicht ausgelastet während ein Restore oft lange dauert (Bandpositionnierung etc.). Daher sichern viele Firmen mittlerweile ihr Daten auf eine andere Festplatte um diese dann auf ein Bandlaufwerk zu verlagern.
Passend hierzu gibt es natürlich auch von Microsoft den "Data Protection Manager", welcher auf einem eigenen Server mittels Replikation und Schattenkopien die Daten produktiver Dateiserver bei sich aufnimmt und auch wieder schnell restaurieren kann. Die Daten der produktiven Server müssen daher nicht mehr gesichert werden (der SystemState sollte aber weiter gesichert werden), da diese über die Sicherung des DPM automatisch gesichert sind.
Leider kann der DPM 2006 nicht Exchange sichern. Es gibt hier nur den Umweg, dass die Exchange Datenbanken z.B. mit NTBACKUP auf eine Datei gesichert werden, welche ihrerseits dann per DPM gesichert wird. Auch wenn des dazu sogar eine Beschreibung in einem TechNet Artikel gibt (909644 How to use Microsoft System Center Data Protection Manager 2006 to help protect an Exchange Server), so halte ich diesen Ansatz in der heutigen Form für unbrauchbar. Bei einem Restore müsste ein Restore von der Banddatei über LAN erfolgen, was zu langsam ist.
Option Software-RAID und z.B.: iSCSI
Mit den dynamischen Datenträgern kann Windows 2003 auch selbst Daten zwischen Festplatten spiegeln. Da könnte es durchaus eine Option sein, ein "kleines VSS" in der Art zu bauen, dass eine Festplatte per RAID1 an das produktive System angehängt und gespiegelt wird und zum "Backupzeitpunkt" einfach das intakte RAID aufgebrochen wird. Diese losgelöste Platte (Vergleiche "SAN Split") kann dann eigenständig gesichert werden. Dank der Unterstützung von iSCSI kann so eine LUN sogar direkt auf einem anderen Server liegen, z.B.: nahe beim Bandlaufwerk.
Aber auch hier ist wieder das Problem, ob die Daten auf der abgetrennten Festplatte konsistent sind. Insofern ist diese Funktion als Backup weniger geeignet.
Option MS-Cluster mit Disks im SAN
Eine ganz andere Lösung hat Microsoft selbst angeblich implementiert. Ihr Exchange Server mit Postfächern sind alle als Microsoft Cluster ausgelegt. Ein Vorteil von Cluster ist aber nicht nur eine höhere Verfügbarkeit, sondern Sie können mit Clusterressourcen problemlos auch Festplatten zwischen Clusterknoten verlagern. Und da liegt nun der Trick. Neben den "Exchange virtuellen Servern" mit ihren eigenen Disk Ressourcen können Sie weitere virtuelle Server anlegen, die einfach nur eine IP-Adresse, einen Netzwerknamen und eine weitere Disk enthalten. Wenn Sie dann diese Ressource auf den gleichen Knoten verschieben, auf dem auch Exchange läuft, dann kann der Exchange Server auch mittels NTBACKUP von einer "lokalen" Disk auf die ebenfalls "lokale" Disk der Backupgruppe gesichert werden.
Nach dem Backup kann die Gruppe wieder auf einen anderen passive Knoten verschoben werden und von von dort auf das Band übertragen werden.
Weitere Links
- Backup und Restore und Folgeseiten
- Imagebackup als Sicherung
- Schattenkopien
- MSXFAQ.DE -Drivesnapshot - VSS zum Kopieren der Datenbank
- MSXFAQ.DE - -1018 Fehler a never ending story
- Troubleshooting Exchange 2007 VSS Backups
http://blogs.technet.com/b/exchange/archive/2008/08/25/449684.aspx - 822896 Exchange Server 2003 data backup and Volume Shadow Copy services
- 842066 TechNet Support WebCast: Volume Shadow Copy für Exchange Server 2003
- 909644 How to use Microsoft System Center Data Protection Manager 2006 to help protect an Exchange server
- So what is this "shadow copy" Exchange backup that NTBackup can take
http://go.microsoft.com/fwlink/?LinkId=72903 - Exchange 2007 and Windows 2008: Online Exchange Backup
Part 1: Getting a List of Storage Groups in a PowerShell Script
Part 2: Getting a List of Stores in a PowerShell Script
Part 3: Exchange 2007 and Windows 2008: Offline Exchange Backup
Part 4: Volume Shadow Copy Services (VSS) and Exchange - The Basics
Part 5: Exchange 2007 and Windows 2008: using Diskshadow für Online Exchange Backup
Part 6: Exchange-2007-and-windows-2008-online-exchange-backup.aspx
Part 7: xxx -
Using IBM Tivoli Storage Manager to Back up Microsoft Exchange with VSS
http://www.redbooks.ibm.com/abstracts/sg247373.html
http://www.redbooks.ibm.com/redbooks/pdfs/sg247373.pdf -
Simplifying Mailbox-Level Restore für Microsoft Exchange with an iSCSI SAN
http://www.lefthandnetworks.com/news/events.php?&EID=135&cid=9&rid=LFTHND-01&m=1&h=
The process of recovering individual mail items is time consuming and filled with many pitfalls. Join this webinar to see a live demo and hear how combining Recovery Storage Groups with disk-based snapshots make mail item recovery simple. - Backup solutions für Exchange 2007...
http://blogs.msdn.com/douggowans/archive/2007/10/16/backup-solutions-for-exchange-2007.aspx - VShadow Tool and Sample
http://msdn2.microsoft.com/en-us/library/bb530725.aspx - HoboCopy. Nutzt VSS um dann die Dateien zu kopieren Announcement
http://www.pluralsight.com/blogs/craig/archive/2006/09/20/38362.aspx
Projektsite
http://www.pluralsight.com/wiki/default.aspx/Craig/HoboCopy.html Download
http://sourceforge.net/projects/wangdera