Fragensteller
Exchange 2010: Backup auf anderen Server wieder einspielen

Allgemeine Diskussion
-
Hi Community,
welche Voraussetzungen müssen erfüllt sein, damit ein an einem Exchange 2010 erstelltes Backup auf einen anderen Exchange 2010 in der selben Organisation wieder eingespielt werden kann?
Zum einen möchte ich mir damit endlich das Problem vom Hals schaffen, die erstellten Backups nicht auf Funktionalität zu überprüfen zu können, zum anderen hätte ich die Restorezeiten signifikant verkürzt. Wenn ich den Restore der erstellten Backups gleich wieder geskriptet einspiele, bin ich tagesaktuell mit dem StandBy Exchange.
Mein laienhafter Sachverstand hat sich das so vorgestellt, dass ich bei dem StandBy Exchange mit deaktivierten Empfangs- und Sendeconnector arbeite, die dann im Bedarfsfall aktiviert werden. Des Weiteren muss dann noch das interne SMTP Routing auf den neuen Exchange umgebogen werden, dass ist aber nur ein Eintrag im Router. Ob sich die Clients dann automatisch mit den neuen Exchange verbinden oder umkonfiguriert werden müssen weiß ich jetzt nicht und wäre noch zu klären.
Ein Restore im Bedarfsfall inklusive Installation des neuen Exchange bei Totalausfall des derzeit produktiven würde einen ganzen Tag in Anspruch nehmen und deutlich am Nervenkostüm zerren. Datenbanken mit zT über 200GB sind da wiederherzustellen, ich hatte letztes Jahr erst das Vergnügen. Diese Zeit wenn unterboten werden könnte wäre das ein beruhigendes Setup, zumal ich nicht Angst haben muss dass ggf das Backup nicht funktionieren könnte...
Thx & Bye Tom
- Bearbeitet Thomas Pronto Wildgruber Donnerstag, 7. Januar 2016 14:14
- Typ geändert Teodora MilushevaModerator Dienstag, 2. Februar 2016 12:31 Die Threads die keine Aktivität haben, werden als Diskussion geändert. Das machen wir, um die Suche in dem Forum zu verbessern. Sie können den Typ jede Zeit ändern.
Alle Antworten
-
Moin,
zuerst wäre die Frage zu stellen, warum Du kein vernünftiges Hochverfügbarkeits-Konzept hast.
Wenn Du schon Hardware und Lizenzen doppelt hast, dann kannst Du auch eine DAG einrichten. Das ersetzt zwar kein Backup, aber es nimmt Dir den Druck bei einem Ausfall schnell einen zweiten Server hochzuziehen.
Davor gehört am besten ein Load Balancer, es geht notfalls aber auch mit kostenlosen Lösungen (Kemp oder Zen) oder mit manuellen DNS-Änderungen, aber das hängt davon ab, wie viel Geld man hat und wie schnell man wieder online sein muss.
Technisch könnte man das zwar auch mit Backup und sofortigem Restore lösen (nennt sich "Datenbankmobilität"), das brauch aber im Fehlerfall deutlich mehr Zeit und bringt mehr Fehlerquellen mit, als eine saubere DAG.
Gruesse aus Berlin schickt Robert - MVP Exchange Server
-
Servus Robert,
> Technisch könnte man das zwar auch mit Backup und sofortigem Restore lösen (nennt sich "Datenbankmobilität"), das brauch aber im Fehlerfall deutlich mehr Zeit und bringt mehr Fehlerquellen mit, als eine saubere DAG.
Die Zeit ist das geringere Problem, die Nerven des Admins sind die größere Problematik. Bei einer DAG befürchten wir zum einen die gestiegene Komplexität des Gesamtsetups und zum anderen haben wir dann immer noch kein Backup getestet. Wir haben halt keinerlei Erfahrung mit Exchange Clustern und ob das dann die Nerven schont weiß ich nicht... ;-)
Mir wäre schon geholfen wenn ich irgendwie die Backups regelmäßig testen könnte, aus dieser Motivation ist die Idee mit dem zweiten Exchange erst entstanden. Dieses Minimalziel sehe ich bei einer DAG nicht erfüllt.
Andere Frage, könnte ich diese "Datenbankmobilität" oder/und DAG auch zwischen Exchange 2010 und 2016 nutzen? Für den 2016er erwarten wir demnächst eine Lizenz im Action Pack.
Thx & Bye Tom
-
Am 07.01.2016 schrieb Thomas Pronto Wildgruber:
Hi,Andere Frage, könnte ich diese "Datenbankmobilität" oder/und DAG auch zwischen Exchange 2010 und 2016 nutzen?
Nein. Das geht immer nur innerhalb der selben Version und sogar selber Patchstand (SP bzw. CU).
Bye
Norbert
Dilbert's words of wisdom #34:
When you don't know what to do, walk fast and look worried.
nntp-bridge Zugriff auf die MS Foren wieder möglich: https://communitybridge.codeplex.com/ -
> Bei einer DAG befürchten wir zum einen die gestiegene Komplexität des Gesamtsetups
Hmmmm. Du vergleichst eine extrem gut laufende Standard-Lösung mit einer gescripteten Bastellösung, die viele fehlerträchtige Schritte braucht (teilweise PowerShell, teilweise ESEUTIL).
Welche Lösung ist wohl komplexer?
> und zum anderen haben wir dann immer noch kein Backup getestet.
Das weißt Du in Deiner Lösung aber auch nur, wenn es mal knallt. Oder Du schwenkst regelmäßig, was dann wieder komplex ist.
Ich habe hier 2 DAG Knoten mit 2000 Usern. Singe Item Recovery ist aktiviert, dass ein Backup läuft, weiß ich nur, weil es der Admin mir regelmäßig bestätigt. Plattenausfällen gab es. Dann wird halt eine DB neugebaut, fertig. Gelöschte Mails kann der User selbst wiederherstellen in Outlook, getrennte Postfächer liegen ein Jahr und warten auf eventuellen Reconnect (die lange Zeit ist intern bedingt).
Ein Recovery habe ich noch nie benötigt, das Backup läuft nur, weil BSI Grundschutz das vorschreibt und unser IT-Sicherheitsbeauftragter darauf Wert legt.
> Für den 2016er erwarten wir demnächst eine Lizenz im Action Pack.
Du weißt, dass Du im Action Pack immer nur eine Lizenz für den gerade aktuellsten Server hast?Gruesse aus Berlin schickt Robert - MVP Exchange Server
-
Servus Robert,
> Hmmmm. Du vergleichst eine extrem gut laufende Standard-Lösung mit einer gescripteten Bastellösung, die viele fehlerträchtige Schritte braucht (teilweise PowerShell, teilweise ESEUTIL).
Das überrascht mich jetzt. Als wir damals das Backup in einen wiederhergestellten Exchange eingespielt haben, mussten wir nur noch die Datenbanken starten, dass wars dann auch. Keine Powershell und auch kein ESEUTIL war notwendig, afair.
> Ich habe hier 2 DAG Knoten mit 2000 Usern. Singe Item Recovery ist aktiviert, dass ein Backup läuft, weiß ich nur, weil es der Admin mir regelmäßig bestätigt.
In diesem Satz stehen schon mal zwei signifikante Unterschiede von uns, euch gegenüber. Wir sind hier grad mal 60 Leute und ich bin der einzige Admin, der da alles macht. Wenn du mal ein Backup brauchst und es funktioniert nicht, bist du ja auch nicht schuld daran. Ich hingegen bin immer schuld, egal wo der Fehler lag... ;-)
Skizzieren wir mal ein anderes Szenario: Kürzlich haben sich die Warnungen und Fehlermeldungen auf unserem Exchange beängstigend gehäuft, es wurde schon laut über eine Neuinstallation nachgedacht, wir wollten jedoch noch abwarten ob sich noch jemand meldet, damit wir die Ursache ggf auch verstanden und zukünftig vermeiden können. Wenn ich jetzt einen zweiten, unabhängigen Exchange hätte, könnte ich diesen schon als die Neuinstallation betrachten. Bei einem HA Cluster, welches im laufenden Betrieb ja immer beide Server benutzt und es kommt gehäuft zu Fehlern, woher weiß ich welcher der beiden Exchanger die Probleme verursacht und wenn man es nicht herausfindet (so wie es derzeit im aktuellen Fall der Fall zu sein scheint) muss ich dann alle zwei neu installieren?
Thx & Bye Tom
-
Am 08.01.2016 schrieb Thomas Pronto Wildgruber:
Moin,
> In diesem Satz stehen schon mal zwei signifikante Unterschiede von uns, euch gegenüber. Wir sind hier grad mal 60 Leute und ich bin der einzige Admin, der da alles macht. Wenn du mal ein Backup brauchst und es funktioniert nicht, bist du ja auch nicht schuld daran. Ich hingegen bin immer schuld, egal wo der Fehler lag... ;-)Wenn du dir den Schuh anziehst...
Und 60 Leute oder 600 ist egal. Definiere wie wichtig einzelne Dienste sind, und budgetiere das.Skizzieren wir mal ein anderes Szenario: Kürzlich haben sich die Warnungen und Fehlermeldungen auf unserem Exchange beängstigend gehäuft, es wurde schon laut über eine Neuinstallation nachgedacht, wir wollten jedoch noch abwarten ob sich noch jemand meldet, damit wir die Ursache ggf auch verstanden und zukünftig vermeiden können. Wenn ich jetzt einen zweiten, unabhängigen Exchange hätte, könnte ich diesen schon als die Neuinstallation betrachten. Bei einem HA Cluster, welches im laufenden Betrieb ja immer beide Server benutzt und es kommt gehäuft zu Fehlern, woher weiß ich welcher der beiden Exchanger die Probleme verursacht und wenn man es nicht herausfindet (so wie es derzeit im aktuellen Fall der Fall zu sein scheint) muss ich dann alle zwei neu installieren?
Wo ist der Unterschied? Du weißt es bei einem Server nicht, und bei zweien auch nicht. Da hilft nur weiterbilden oder externe Unterstützung. Siehst du das anders?
Bye
Norbert
Dilbert's words of wisdom #34:
When you don't know what to do, walk fast and look worried.
nntp-bridge Zugriff auf die MS Foren wieder möglich: https://communitybridge.codeplex.com/ -
Servus,
> Wo ist der Unterschied? Du weißt es bei einem Server nicht, und bei zweien auch nicht.
Aber sicher weiß ich das. Bei dem Setup zweier unabhängiger Server wo nur einer produktiv läuft, kann auch nur dieser Server der sein, der die Probleme hat.
> Da hilft nur weiterbilden oder externe Unterstützung. Siehst du das anders?
Jepp, sehe ich anders. Keep it simple and stupid! Mein Primärziel war das Backup zu testen...
...was ich am Ende habe ist ein Hochverfügbarkeitscluster mit Loadbalancer vorne dran und eine Horde Dienstleister die für xxxxk Euro das ganze System hier aufziehen von dem wir im Anschluss erst mal Null Ahnung haben, lediglich wissend , dass wir dann immer noch kein Backup getestet haben (!) Ganz toll.
Das kann doch nicht die einzige Lösung sein...
Bye Tom
-
Am 08.01.2016 schrieb Thomas Pronto Wildgruber:
Hi,> Wo ist der Unterschied? Du weißt es bei einem Server nicht, und bei zweien auch nicht.
Aber sicher weiß ich das. Bei dem Setup zweier unabhängiger Server wo nur einer produktiv läuft, kann auch nur dieser Server der sein, der die Probleme hat.Naja wenn du meinst.
Jepp, sehe ich anders. Keep it simple and stupid! Mein Primärziel war das Backup zu testen...
Viel Erfolg. :)
...was ich am Ende habe ist ein Hochverfügbarkeitscluster mit Loadbalancer vorne dran und eine Horde Dienstleister die für xxxxk Euro das ganze System hier aufziehen von dem wir im Anschluss erst mal Null Ahnung haben, lediglich wissend , dass wir dann immer noch kein Backup getestet haben (!) Ganz toll.
Wie gesagt, jeder wie er mag und kann. Aber in meinen Augen ist deine Lösung trotzdem kein sinnvoller Weg.
Das kann doch nicht die einzige Lösung sein...
Hat auch niemand behauptet.
Bye
Norbert
Dilbert's words of wisdom #18:
Never argue with an idiot. They drag you down to their level then beat you with experience.
nntp-bridge Zugriff auf die MS Foren wieder möglich: https://communitybridge.codeplex.com/ -
Am 08.01.2016 schrieb Thomas Pronto Wildgruber:
Hi,>> Das kann doch nicht die einzige Lösung sein...
> Hat auch niemand behauptet.
Aber sagen [eine andere Lösung] tust du auch nicht, oder?Welche würdest du denn gern hören? Dann muß ich nicht so lange überlegen. ;)
Backup/Recovery Konzept ist ja nichts so ungewöhnliches. Mir ist wie gesagt nur unklar, wozu man da jetzt soviel Unterstützung braucht. Im Endeffekt tuts eine Testumgebung die identisch heißt. Da spielst du deine DB ein und weißt ob es funktioniert.Bye
Norbert
Dilbert's words of wisdom #10:
I don't have an attitude problem. You have a perception problem.
nntp-bridge Zugriff auf die MS Foren wieder möglich: https://communitybridge.codeplex.com/ -
> Das überrascht mich jetzt. Als wir damals das Backup in einen wiederhergestellten Exchange eingespielt haben, mussten wir nur noch die Datenbanken starten, dass wars dann auch. Keine Powershell und auch kein ESEUTIL war notwendig, afair.
ESEUTIL brauchst Du in Abhängigkeit vom Restore-Programms und den eventuell noch fehlenden Log-Dateien -> Stichwort Hard- und/oder Softrecovery. Das Problem hierbei ist, dass ein Automatisierung nicht so einfach ist, weil der Stand nach dem Restore verschieden sein kann und dann verschiedene Befehl und Reaktionen notwendig sind. Das hängt vom Zustand der Sicherung und vom Prozess des Restores ab.
In der PowerShell brauchst Du Schritte spätestens bei der Aktivierung oder wenn Du testweise Postfächer ausprobieren willst. Und das musst Du ja von Zeit zu Zeit auch tun, sonst weißt Du gar nicht, ob die User überhaupt an die Mailboxen ran kommen. Da Du dies aber im "Live-Betrieb" machst, musst Du basteln, denn DNS kannst Du nicht mal ebene ändern, ohne alle Benutzer zu treffen.
> In diesem Satz stehen schon mal zwei signifikante Unterschiede von uns, euch gegenüber. Wir sind hier grad mal 60 Leute und ich bin der einzige Admin, der da alles macht.
Mal davon abesehen, dass mein Exchange Anteil deutlich unter 10% liegt, sollte das nur zeigen, dass man mit einem guten HA-Konzept gar nicht erst in die Verlegenheit kommt, auf ein Backup zurückzugreifen.
Aber gerade WEIL Du alleine bist, finde ich es um so wichtiger, nicht zu basteln, sondern möglichst nah am Standard zu bleiben. Stell Dir mal vor, Du fällst überraschend aus und Dein Chef organisiert einen Dienstleister. Der steigt da nie oder nur mit hohen Aufwand durch. So viel kannst Du gar nicht dokumentieren.
Ist das aber Standard, dann weiß ein Dienstleister von alleine, was er tun muss (wenn es ein guter ist).
Wir wollen Dir hier ja auch nur Anregungen geben und die wichtigsten Stichwörter hast Du bekommen. Norbert und ich kommen genau aus dem Dienstleisterbereich und kennen daher die vielen Fehler, die gemacht werden.
Den Rest sehe ich wie Norbert. Ich verstehe schon, welche Probleme Du hast, aber Du Du musst probieren, an den Ursachen nicht an den Symptomen zu arbeiten.
Zum Testen von Restores gibt es auch andere Möglichkeiten, z.B. eine Testumgebung.Gruesse aus Berlin schickt Robert - MVP Exchange Server
-
Servus Robert,
> Zum Testen von Restores gibt es auch andere Möglichkeiten, z.B. eine Testumgebung.
Früher zu Exchange 2003 Zeiten hatten wir eine Recovery Domäne, wo wir hin und wieder mal das Backup getestet haben. Dabei galt: "The Organization Name, Administrative Group Name, Storage Group Name, Mailbox Store (Server Name), and the LegacyExchangeDN Attribute on the recovery server must match that of the production machine." [1] Nur der Domänenname war unterschiedlich.
Das scheint aber so, laut diversen Forenpostings bei Exchange 2010 nicht mehr zu funktionieren, der Recovery Server muss demnach im selben Forest wie der produktive Server sein. Gibt es noch eine andere Möglichkeit?
https://www.veritas.com/support/en_US/article.TECH20523
Thx & Bye Tom
-
Moin,
das war aber schon immer so, bei 2003 musst sogar der Server-Name stimmen.
Aber wo ist das Problem, das in einer abgeschotteten Labor-Umgebung nachzustellen?
Im Worst-Case brauchst du einen DC und eine Maschine für Exchange.
;)
Gruß Norbert
-
Servus Norbert,
> das war aber schon immer so, bei 2003 musst sogar der Server-Name stimmen.
Afair aber nur der NetBIOS Name und nicht der FQDN. Wir hatten dieses Setup mit einem unterschiedlichen Domänennamen (RECOVERY.intern) schon am Laufen und hat damals wunderbar funktioniert. Das wäre jetzt halt auch wirklich praktisch.
> Aber wo ist das Problem, das in einer abgeschotteten Labor-Umgebung nachzustellen?
Mit abgeschottet meinst du alles, bis aufs i-Tüpfelchen identisch? Domänen-(DNS)-Name, Exchange-Organisations-Name, IP-Adresse, Daten-Namen und -Pfade, etc?
Das Problem dabei wäre zB den Backupserver in beiden Netzen verfügbar zu machen. Und im Backupserver müsste ich den (Recovery)-Exchange zusätzlich anlegen, was problematisch wird, wenn er genau so heißt wie der produktive.
Das einzige was wirklich abgeschottet funktionieren würde, wäre, wenn ich auch noch einen Backupserver in das Recovery-Netz installiere und da irgendwie die gesicherten Daten hinkopiere (externe Festplatte zB) aber das ist dann schon richtig Aufwand, regelmäßig macht das niemand. Das wäre dann auch wirklich schade ums Geld, zumal die Backupsoftware auch noch zu den benötigten Lizenzen dazu käme. Und die ist mit Exchange-Agent auch richtig teuer...
Thx & Bye Tom
-
...
Das einzige was wirklich abgeschottet funktionieren würde, wäre, wenn ich auch noch einen Backupserver in das Recovery-Netz installiere und da irgendwie die gesicherten Daten hinkopiere (externe Festplatte zB) aber das ist dann schon richtig Aufwand, regelmäßig macht das niemand. Das wäre dann auch wirklich schade ums Geld, zumal die Backupsoftware auch noch zu den benötigten Lizenzen dazu käme. Und die ist mit Exchange-Agent auch richtig teuer...
Thx & Bye Tom
Vielleicht habe ich es in diesem Thread überlesen, aber das was Du gerne möchtest (Backup prüfen, schnelles recovery ohne DAG...) wäre doch mittels Virtualisierung easy umsetzbar.
Ich mache das mit vSphere 6 (mit HyperV ginge das auch), SAN und Veeam. In Veeam kannst Du auch direkt Deine Lab Umgebung bauen und mit den Daten in einer isolierten Umgebung testen.
Und mit Instant Recovery hast Du ne Maschine quasi adhoc aus dem Backup gestartet.
Geschenkt gibt es das aber auch alles nicht. Lizenzen kosten Geld und die Administration lernt man auch nicht über Nacht. Wäre aber als längerfristiges Ziel mal sinnvoll drüber nachzudenken (also über Virtualisierung).
HTH
-
Servus NiceName,
> [Virtualisierung] Ich mache das mit vSphere 6 (mit HyperV ginge das auch), SAN und Veeam. In Veeam kannst Du auch direkt Deine Lab Umgebung bauen und mit den Daten in einer isolierten Umgebung testen.
Jepp diese Methode wäre mir die Liebste aber das Problem war, dass ich keinen Shared Storage habe um den Exchange direkt wandern lassen zu können, auch ein vCenter haben wir nicht. Somit wäre das fehlende SAN wohl der Showstopper...
Wir haben hier aber mehrere vSphere (5.5) Hosts mit Enterprise Lizenz und ich hatte kürzlich das Vergnügen mich eine Zeitlang mit ein paar Leuten von VMWare zu unterhalten. Wir replizieren schon seit einer Weile diverse Windows Server von einem Host zu einem anderen, die Maschine ist am Zielhost dann offline. Wir haben das sogar schon erfolgreich mit einem MSSQL 2008 R2 Server gemacht. Die Maschine ist aber nur Testmaschine aber hat funktioniert. Einen Exchange auf diese Art zu replizieren ist leider auch nicht supportet, wobei die von VMWare da weniger Bedenken hätten. Die meinten, VMWare würde die Replikation erst gar nicht abschliessen wenn es die Maschinen nicht synchron bekommen würde. Die ganze Sache ist mir aber zu heikel, dass läuft zwar auch über die VSS Api aber ich weiß nicht, ob da hinterher noch alles mit den Transaction Logs stimmt. Nicht dass der Snapshot dem eigentlichen Backup irgendwelche Transaction Logs unter Hintern wegzieht (und umgekehrt) und am Ende ist gar nichts mehr vollständig.
Unser Dienstleister in Sachen Exchange sähe das auch eher entspannt und meint das wäre auf alle Fälle mal ein Anfang aber da haben die anderen schon Recht, wenn es nicht supportet ist, ist das auch keine Dauerlösung. Von Veem habe ich schon mal was gehört, die von VMWare haben das auch erwähnt, wir verwenden hier den VMExplorer, das ist was ganz ähnliches und kann auch Backup, Replikation (inkrementell, differentiell etc).
> Geschenkt gibt es das aber auch alles nicht. Lizenzen kosten Geld und die Administration lernt man auch nicht über Nacht. Wäre aber als längerfristiges Ziel mal sinnvoll drüber nachzudenken (also über Virtualisierung).
Die Lizenzen bräuchte ich bei so ziemlich jeder Lösung mit zweiten Exchange bis auf vielleicht eine HyperV Lösung aber davon sind wir weit weg. Also wenn das am Ende 3, 4 oder 5k Euro kostet, geht die Welt auch nicht unter aber ich hätte halt wesentlich mehr Sicherheit. Bei uns ist es auch weniger die Ausfallzeit bis wir wieder online sind, vielmehr sind es die Postfächer selbst, die zu verlieren eine Katastrophe wäre.
Käme deine Lösung am Ende sogar ohne Shared Storage bzw SAN aus, dann würde ich darauf gerne noch mal näher eingehen.
Thx & Bye Tom
-
Bin gerade etwas knapp mit Zeit, aber mal so ganz schnell aus der Hüfte geschossen ohne es genau durch zu denken:
Wenn Du mehrere ESX Enterprise hast: vCenter Foundation (falls es das noch gibt) kann bis zu 3 ESX verwalten und ist recht günstig im Vergleich zur großen Version.
Ohne Storage: Backupserver mit Veeam, direkt mit den ESX verbinden, Backup machen, auf Wunsch mittels application aware snapshot (agentless) die logs abschneiden (per vss), dann hast Du ein sauberes backup. Das kannst Du (auch ohne storage) direkt auf einem der ESX einbinden. Zumindest ist das mein Stand. Habe jetzt keine Zeit das nachzulesen, aber sollte so gehen.
HTH
-
Servus,
> Wenn Du mehrere ESX Enterprise hast: vCenter Foundation (falls es das noch gibt) kann bis zu 3 ESX verwalten und ist recht günstig im Vergleich zur großen Version.
Ja gibts noch und ist in der Tat bezahlbar, jedoch hatte ich diese Variante wieder verworfen, weil mir das imho nichts bringt, wenn Exchange seine Datenbank schrottet, weil die (idR bei Shared Storage) ja auch nur einmal existiert. Diese Variante hilft lediglich einen VMWare Host schmerzfrei zu evakuieren um zB Wartungsarbeiten durchzuführen. Das Problem habe ich in der Tat zwar auch noch aber betrifft alle Gäste auf dem Host.
> Ohne Storage: Backupserver mit Veeam, direkt mit den ESX verbinden, Backup machen, auf Wunsch mittels application aware snapshot (agentless) die logs abschneiden (per vss), dann hast Du ein sauberes backup. Das kannst Du (auch ohne storage) direkt auf einem der ESX einbinden. Zumindest ist das mein Stand. Habe jetzt keine Zeit das nachzulesen, aber sollte so gehen.
Das muss ich mir erst näher anschauen, im Prinzip habe ich die Komponenten bereits, jedoch anstelle von Veeam halt VMWare Explorer, kann aber auch Backups. Ich kenne das halt von wbadmin, dass man zweierlei Möglichkeiten hat ein Backup zu machen, einmal Log Bereinigt und einmal nur Backup ohne die Logs anzufassen. Ich schau mal ob ich dazu Beispielkonfigurationen finde, dieses Szenarion lässt sich ja genauso wie ein DAG derzeit noch immer in das bestehende Setup einfügen.
Die nächsten Tage haben wir wieder jemanden vom Systemhaus im Haus wegen eines Datevupdates, die haben auch unseren Exchange installiert und diskutiere das auch mal mit dem durch. Die Testumgebung scheint derzeit wohl die einzige vernünftige Möglichkeit zu sein ein Backup zu testen, ich glaubte zwar mal irgendwo etwas von einem Tool gelesen zu haben was das auch kann, finde den Artikel momentan aber nicht mehr. Aber im Prinzip schade, denn das kostet alles Geld und ausser ein Backup getestet habe ich dann auch nicht, etwas mehr Mehrwert würde der Sache nicht schaden aber von der Idee einen zweiten Testexchange in die produktive Organisation zu nehmen bin ich zumindest zZ schon wieder abgekommen...
Thx & Bye Tom