DisasterRecovery / Imaging von DCs

[Daim 12]

Nur bringt der 2.DC (Uralt-PC) bei einem Ausfall des SBS überhaupt nichts, denn die Anwendungen, auf die die MA zugreifen, sind ja auch nicht da, weil sie in der Regel auf dem SBS (oder 1.DC) installiert sind, als da wären:

Exchange, ERP/CRM/etc (meist über SQL-Server), Companyweb, Files

 

Und wenn du dich noch so oft wiederholst ändert es nichts an der Tatsache, dass beim Crash des SBS ein etwas betagter zweiter DC immer noch besser ist, als garnichts zu haben.

Was ist daran so schwer zu verstehen?

 

Besteht in einer kleinen Domäne NUR ein SBS der ALLE Dienste die du aufgezählt hast samt Daten hält, können nach einem Crash des SBS die Mitarbeiter aufhören zu arbeiten.

Existiert hingegen ein auf einer ausgemusterten Workstation weiterer DC, können auf diesem die Daten von der Sicherung wiederhergestellt und zumindest ein "Notbetrieb" aufrecht gehalten werden. Dabei kann man das clever aufbauen, so das sich dann der SBS und der andere DC die Daten mehrmals am Tag die Daten synchronisieren.

 

Auch wenn kein E-Mal funktioniert oder was auch immer nicht, ist der Notbetrieb besser als ein Stillstand!

 

 

Die User können sich an der Domäne anmelden, bekommen aber Fehlermeldungen wegen fehlender Netzlaufwerke-> ganz toll [ironie]

Sie können Drucker nutzen (was sollen sie denn drucken?)

 

Der weitere DC braucht nicht nur DC sein, er kann schon etwas mehr zur Verfügung stellen als die Domänendienste. Das habe ich aber bereits oben und in meiner ersten Antwort erwähnt. Abgesehen davon, ein Login-Skript habe ich schnell umgeschrieben, so dass die Netzlaufwerke dann wieder passen (natürlich nach vorherigem erstellen der Freigaben auf dem weiteren DC).

 

 

Ihre eigentliche Arbeit können sie aber erst wieder machen, wenn der Anwendungsserver wieder restored ist

 

Das gilt für JEDE Umgebung, egal wie klein oder groß die Umgebung ist!

 

 

-> ergo sind sie mit 2.DC in dieser Zeit genauso unproduktiv, wie wenn dieser fehlen würde.

 

Nie und nimmer.

 

 

Somit verkaufe ich dieser kleinen Firma lieber eine vernünftige Sicherungsstrategie, als ihnen weißmachen zu müssen, sie benötigten dringendst eine weiter W2K3-Lizenz und einen Computer/Server als DC.

 

Deine Sicherungsstrategie die du hier aufführst ist das Imagen. Das kann zwar jeder sehen wie es mag, aber unter "vernünftige Sicherungsstrategie" verstehe ich ein Backup-Konzept, dass vollkommen von den Herstellern unterstützt wird.

So das ich dem Kunden klar kommunizieren kann, dass bei später aufkommenden Problemen, der Support der Hersteller weiterhin gegeben ist.

 

Eine vernünftige Sicherungsstrategie sollte sich jedes Unternehmen zulegen.

Das kann aber auch bedeuten, dass eben ein weiterer DC dazu zählt und dieser DC, darf ruhig weitere Aufgaben wahrnehmen, z.B. File- und Printservices.

 

 

Wichig ist einzig eine vernünftige Wiederherstellungsstrategie. Dies wurde sehr oft in diesem Thread erwähnt.

Diese Strategie muss dann natürlich auf die Gegebenheiten der Firma abgestimmt sein.

 

Und zu einer Strategie, kann ein weiterer DC dazu zählen.

[Gulp 254]

@gulp

hast du einen Link zu einer MS-Site, in welcher drin steht, dass man nach einem Image keinen Systemstate via ntbackup mehr einspielen darf, da diese Reihenfolge bei der Wiederherstellung eines DC's den "Supportbedingungen" widerspricht ?

... snip

 

Nein, einen Systemstate nachträglich einzuspielen ist zwingend, will man keinen USN Rollback riskieren (was aber nicht heisst, dass das supported wäre), siehe zum Beispiel folgende Aussage:

 

To roll back the contents of Active Directory to a previous point in time, restore a valid system state backup. A system state backup can be restored up to the tombstone lifetime number of days after the backup was performed. The backup must have also been made on the same operating system installation as the operating system that you are restoring.

 

Active Directory does not support other methods to roll back the contents of Active Directory. In particular, Active Directory does not support any method that restores a snapshot of the operating system or the volume the operating system resides on. This kind of method causes an update sequence number (USN) rollback. When a USN rollback occurs, the replication partners of the incorrectly restored domain controller may have inconsistent objects in their Active Directory databases. In this situation, you cannot make these objects consistent.

 

Quelle: Considerations when hosting Active Directory domain controller in virtual hosting environments

 

Allerdings hat man mit dem Erstellen des Images bereits den supporteten Weg verlassen und damit ist alles was danach kommt uninteressant.

 

[Weiter in Teil 2]

[Gulp 254]

Auf den oben genannten Artikel wird ebenfalls in folgendem KB Artikel hingewiesen der den Satz enthält:

 

Software and methodologies that cause USN rollbacks

 

When the following environments, programs, or subsystems are used, administrators can bypass the checks and validations that Microsoft has designed to occur when the domain controller system state is restored:

 

.... snip

 

Starting an Active Directory domain controller that is located on a volume where the disk subsystem loads by using previously saved images of the operating system without requiring a system state restoration of Active Directory.

 

.... snip

 

Even if not intended, each of these scenarios can cause domain controllers to roll back to an older version of the Active Directory database by unsupported methods. The only supported way to roll back the contents of Active Directory or the local state of an Active Directory domain controller is to use an Active Directory-aware backup and restoration utility to restore a system state backup that originated from the same operating system installation and the same physical or virtual computer that is being restored.

 

Microsoft does not support any other process that takes a snapshot of the elements of an Active Directory domain controller's system state and copies elements of that system state to an operating system image. Unless an administrator intervenes, such processes cause a USN rollback. This USN rollback causes the direct and transitive replication partners of an incorrectly restored domain controller to have inconsistent objects in their Active Directory databases.

 

Quelle: How to detect and recover from a USN rollback in Windows Server 2003

 

Es gibt noch weitere KB Artikel (schon zu Windows NT und 2000) mit anderen Gründen (unter anderem die SID bei NT und auch das AD bei 2000) warum Disk Images nicht ohne weiteres von Microsoft supported werden.

 

Aus den Dokumenten geht ebenfalls hervor, dass man durchaus mit einem aktuellen Systemstate die meisten eventuellen Schwierigkeiten umschiffen/vermeiden kann.

 

Eine definitive Antwort wird man dazu aber von Microsoft auf Anfrage sicherlich auch erhalten können.

 

Die neueren TrueImage Versionen nutzen laut Acronis selbst die vorgesehenen API's zum Sichern des AD und könnten somit weitgehend auch als eine geeignete Backup Methode angesehen werden, da könnte ein Statement seitens Microsoft oder Acronis tatsächlich interessant sein.

 

Grüsse

 

Gulp

[motzel 10]

@gulp

 

ja, dieses Thema ist wirklich interessant, wobei ich mir nicht so recht vorstellen mag, dass bereits das Erstellen eines Images einen Support von MS ausschließt ?! Außerdem schreibst du oben ja selbst, dass das Problem im AD liegt, welches nur über eine nicht authorisierte Wiederherstellung zurückgesetzt werden sollte, was anderes sag ich auch nicht ;)

 

s.h. Link zu Symantec (Oktober 2007 Best_Practices_--_BESR_7.0_and_Active_Directory_Domain_Controllers.pdf)

http://seer.entsupport.symantec.com/downloads/export.asp?file=1177709655010.Best_Practices_--_BESR_7.0_and_Active_Directory_Domain_Controllers.pdf&source=1&url=/pub/support/products/tfile/&id=1544

hier schreibt der Hersteller auf Seite 3-5, dass aufgrund der Art und Weise (VSS bzw. API's) des Backups der offizielle Backupweg beschritten wird.

 

(Anmerkung laut Symantec ist bei W2K3 im Gegensatz zu W2K durch die Verwendung von VSS kein nachträglicher Restore via ntbackup des Systemstate notwendig.)

 

Gruß

 

motzel

[Gulp 254]

Das behebt aber nicht die anderen generellen Probleme beim Imagen ..... zB inkonsistente relationale Datenbanken beim Rücksichern (Exchange oder SQL zB - auch da hat Acronis mittlerweile ein AddIn für SQL im Angebot) oder die SID Problematik einer geklonten Maschine und die der dortigen lokalen Accounts. Auch treten nicht alle Problembedingungen einzeln auf, sondern können sich auch gemeinsam äussern oder auch nicht existent sein, je nach Szenario.

 

Das AD ist hier nur ein Teil eines möglichen Problems bei Diskimages, betrifft allerdings dann das gesamte Netz und zieht dies in Mitleidenschaft, denn zB bei einem USN Rollback darfst Du je nachdem das gesamte AD neu aufbauen.

 

Alle Links zu MS KB Artikeln oder TechNet Einträgen über Imaging heraus zu suchen dürfte ein recht intensives Unterfangen sein und den Rahmen hier ein wenig sprengen. ;)

 

Solange eine seperate Sicherung eines aktuellen Systemstate vorliegt und die enteprechenden API's genutzt werden können (aber müssen nicht), wie bereits gesagt, die Image Programme durchaus in die Kategorie von unterstützter Backup Software fallen, das will ich auch gar nicht kategorisch abstreiten.

 

Trotzdem bleibe ich, zumindest bis ich etwas fundiertes von MS schriftlich vorliegen habe, bei meinen Aussagen in den vorigen Posts.

 

Grüsse

 

Gulp

[substyle 20]

Also in aller Regel geht es doch um folgendes:

 

Wenn beim kleinen Kunden der einzige SBS ausfällt, habe ich drei Möglichkeiten:

 

A: Ein Ersatzteil bestellen und hoffen das es das einzige defekte Teil war. (Nicht sehr professionell)

 

B: Den Support des Serverherstellers in Anspruch nehmen. Das bedeutet 4 Stunden Ausfall. In der Regel auch gerne auch 6-8 Stunden bis ein Techniker eintrifft. Schnelleren Support lohnt sich nicht zu verkaufen denn:

 

C: Der Kunde hat einen 2. DC neben dem SBS. Dann habe ich die Bandsicherung und ein funktionierendes AD nebst DNS, DHCP, WINS etc. Das kostet in etwa das gleiche wie ein schnelles SLA.

 

Vorteil:

 

Ich kann sofort loslegen eine Restore zu machen, die nötigsten Dienste wieder online bringen.

 

Mail realisiere ich temporär für alle Schlüsselstellen per IMAP.

 

Files und Loginscripte habe ich binnen ca. 1 Stunde sicher wieder am laufen, schließlich brauche ich nichtmal die Rechte auf den Dateien und Freigaben anpassen.

 

Imaging ist an dem Punkt sicher eine Alternative, jedoch verspricht mir keiner das ich ein Image auch zu 100% wieder auf einer 2. Hardware zurücksichern kann.

 

Tritt dan ein Problem auf, bin ich ganz alleine. Was das bedeutet wird schnell klar wenn der "Hersteller" sich aus der Misere zieht oder dort ein überfülltes Callcenter arbeitet.

 

Ich habe das selbst schon bei Acronis erlebt. Man wollte mir einfach nicht helfen, weil das Produkt auf dem Betriebssystem noch nicht verifiziert war. = Persönliches Pech.

 

Ein Call beim PSS (MS Paid Support)

 

"Tja, also wenn Sie das per Image zurückgesichert haben können Sie noch mal das probieren, ansonsten ist es nicht supportet"

 

Ich und meine Kunden haben aber keine Zeit und kein Geld für solche "Wenn und Aber Spiele". Es geht schlicht darum zu garantieren das ein Recoveryplan vom Hersteller der Software im SBS Fall eben Microsoft auch unterstützt wird.

 

Dies ist mir besonders eingänglich geworden, da ich seit mehreren Jahre im gesundheitswesen tätig bin. Es geht einerseits immer um das Budget. Hochverfügbarkeit kann sich hier / will sie hier niemand leisten. Andererseits stellt man hohe Anforderungen. "Eine nicht dokumentierte medizinische Leistung ist eine nicht erbrachte Leistung" = man verdient kein Geld. Und dokumentiert wird heute fast ausschließlich elektronisch.

 

Es geht mir nicht darum Imaging zu "verdammen". Es hat seine Berechtigung auf Workstations und im Depoly von WS.

 

Im Serverbereich gehört Imaging für mich jedenfalls nicht zu einem Datensicherungskonzept. Genausowenig wie der VM-Hype.

 

Recovery per 2.DC & Datensicherung alter Schule geht einfach schneller, ist flexiebler und wird supportet.

 

Recovery per Image geht gleich schnell (optimalfall) hat den Pferdefuß der Hardwarekompatibilität und keinen Support.

 

Da wähle ich im Sinne meiner Kunden die erstere Option.

 

subby

[motzel 10]

Hallo,

 

anbei ein Link zu MS: How to detect and recover from a USN rollback in Windows Server 2003

The following are supported methods that you can use to roll back the contents of Active Directory:

 

• Use an Active Directory-aware backup and restoration utility that uses Microsoft-provided and Microsoft-tested APIs. These APIs non-authoritatively or authoritatively restore a system state backup. The backup that is restored should originate from the same operating system installation and from the same physical or virtual computer that is being restored.

 

• Use an Active Directory-aware backup and restoration utility that uses Microsoft Volume Shadow Copy Service APIs. These APIs back up and restore the domain controller system state. The Volume Shadow Copy Service supports creating single point-in-time shadow copies of single or multiple volumes on Windows Server 2003 computers. Single point-in-time shadow copies are also known as snapshots. For more information, visit the following Microsoft Web site and search for "Volume Shadow Copy Service":

 

 

diese Aussagen von MS BITTE zusammen mit den Aussagen von Symantec im Bezug auf BESR 7.0 auf den Seiten 3-5

Symantec's BESR is Volume Shadow Copy Service (VSS) Aware

http://seer.entsupport.symantec.com/downloads/export.asp?file=1177709655010.Best_Practices_--_BESR_7.0_and_Active_Directory_Domain_Controllers.pdf&source=1&url=/pub/support/products/tfile/&id=1544

 

nachlesen.

 

Dies sind die hier mehrfach zurecht geforderten offiziellen Aussagen von Microsoft und Symantec, und so wie ich diese Info's verstehe, ist zumindest via BESR 7.0, ein von MS unterstütztes imagen und restoren, mit und ohne ntbackup, von DC's möglich.

 

Gruß

 

motzel

[GerhardG 10]

Also in aller Regel geht es doch um folgendes:

 

Wenn beim kleinen Kunden der einzige SBS ausfällt, habe ich drei Möglichkeiten:

 

A: Ein Ersatzteil bestellen und hoffen das es das einzige defekte Teil war. (Nicht sehr professionell)

 

B: Den Support des Serverherstellers in Anspruch nehmen. Das bedeutet 4 Stunden Ausfall. In der Regel auch gerne auch 6-8 Stunden bis ein Techniker eintrifft. Schnelleren Support lohnt sich nicht zu verkaufen denn:

 

du hast den kunden also nicht wirklich aufgeklärt was eine sla ist? wenn 4 stunden zuviel sind, dann muss man eben einen entsprechenden support vertrag oder reserve hardware beschaffen.

 

 

 

C: Der Kunde hat einen 2. DC neben dem SBS. Dann habe ich die Bandsicherung und ein funktionierendes AD nebst DNS, DHCP, WINS etc. Das kostet in etwa das gleiche wie ein schnelles SLA.

 

Vorteil:

 

Ich kann sofort loslegen eine Restore zu machen, die nötigsten Dienste wieder online bringen.

 

Mail realisiere ich temporär für alle Schlüsselstellen per IMAP.

 

Files und Loginscripte habe ich binnen ca. 1 Stunde sicher wieder am laufen, schließlich brauche ich nichtmal die Rechte auf den Dateien und Freigaben anpassen.

 

deiner beschreibung nach müsste dein kunde also eine 2te hardware mit der selben leistung haben? mit einer ordentlichen restore software ist der server längst wieder online, während du noch mit imap und co bastelst.

 

 

Imaging ist an dem Punkt sicher eine Alternative, jedoch verspricht mir keiner das ich ein Image auch zu 100% wieder auf einer 2. Hardware zurücksichern kann.

 

Tritt dan ein Problem auf, bin ich ganz alleine. Was das bedeutet wird schnell klar wenn der "Hersteller" sich aus der Misere zieht oder dort ein überfülltes Callcenter arbeitet.

 

Ich habe das selbst schon bei Acronis erlebt. Man wollte mir einfach nicht helfen, weil das Produkt auf dem Betriebssystem noch nicht verifiziert war. = Persönliches Pech.

 

wie ich oben schon gepostet habe, aktuelle backup software verwendet die von microsoft freigegebenen schnittstellen und somit hast du vollen support.

 

 

 

 

Es geht mir nicht darum Imaging zu "verdammen". Es hat seine Berechtigung auf Workstations und im Depoly von WS.

 

aktuelle server "image" software arbeitet genauso wie ntbackup, veritas und co - dieser punkt ist dir hoffentlich klar?

 

 

Im Serverbereich gehört Imaging für mich jedenfalls nicht zu einem Datensicherungskonzept. Genausowenig wie der VM-Hype.

 

genau, vmware, citrix, microsoft hypervisor- alles nur hype :p

 

 

 

Recovery per 2.DC & Datensicherung alter Schule geht einfach schneller, ist flexiebler und wird supportet.

 

Recovery per Image geht gleich schnell (optimalfall) hat den Pferdefuß der Hardwarekompatibilität und keinen Support.

 

ich würde dir dringend raten mal wieder einen marktvergleich anzustellen. der it markt bleibt nicht stehen, was vor 3-5 jahren gültigkeit hatte ist heute schnee von gestern. was würden deine kunden wohl meinen wenn ein alternativer betreuer ihm mahl erzählt was moderne backup&restore software möglich macht?

[GerhardG 10]

Und wenn du dich noch so oft wiederholst ändert es nichts an der Tatsache, dass beim Crash des SBS ein etwas betagter zweiter DC immer noch besser ist, als garnichts zu haben.

Was ist daran so schwer zu verstehen?

 

Besteht in einer kleinen Domäne NUR ein SBS der ALLE Dienste die du aufgezählt hast samt Daten hält, können nach einem Crash des SBS die Mitarbeiter aufhören zu arbeiten.

Existiert hingegen ein auf einer ausgemusterten Workstation weiterer DC, können auf diesem die Daten von der Sicherung wiederhergestellt und zumindest ein "Notbetrieb" aufrecht gehalten werden. Dabei kann man das clever aufbauen, so das sich dann der SBS und der andere DC die Daten mehrmals am Tag die Daten synchronisieren.

 

in der zeit wo andere noch am aufbau des notbetriebs basteln, kannst du mit jeder besseren backuplösung gleich den orginal server komplett wiederherstellern. eine ausgemussterte workstation ist ja ganz nett, auf die idee kommen viele. oft wird leider auf kleinigkeiten wie dem nicht übertragbaren onboard scsi controller vergessen ;)

 

gegen einen zusätzlichen dc spricht natürlich nichts. aber ich sehe mir darin heute keinen vorteil mehr wenn alle wichtigen dienste am sbs laufen. die idee mit der ausgemusterten workstation stammt noch aus zeiten wo man zuerstmal ein betriebssystem und backup software von hand installieren musste, bevor man mit dem restore überhaupt beginnen konnte. heute ist sowas jedoch mit cd und band einlegen erledigt.

 

notbetrieb sollte grundsätzlich sofort möglich sein und nicht erst wenn ich beim kunden angekommen bin und vielleicht noch stundenlang gebastelt habe (zb per offline files und cached profiles). beim kunden angekommen sollte man sich um problemlösungen und nicht workarounds beschäfftigen.

[goscho 11]

@GerhardG,

vielen Dank, dass es noch weitere Leute hier an Board gibt, die meiner Meinung bezüglich der schnellen Wiederherstellung von Servern (auch per Image wie mit BESR) in kleinen Umgebungen sind und diesen Kleinfirmen keinen 2.DC als "muss" vorschreiben.

 

n der zeit wo andere noch am aufbau des notbetriebs basteln, kannst du mit jeder besseren backuplösung gleich den orginal server komplett wiederherstellern. eine ausgemussterte workstation ist ja ganz nett, auf die idee kommen viele. oft wird leider auf kleinigkeiten wie dem nicht übertragbaren onboard scsi controller vergessen

Und dann soll darauf eventuell noch ein SQL-2005 laufen, wie auf dem SBS2K3 R2 Premium.:confused:

 

Ich schließe mich deinen Ausführungen voll und ganz an und möchte es dabei belassen.:jau: :jau: :jau:

[Velius 10]

@GerhardG,

vielen Dank, dass es noch weitere Leute hier an Board gibt, die meiner Meinung bezüglich der schnellen Wiederherstellung von Servern (auch per Image wie mit BESR) in kleinen Umgebungen sind und diesen Kleinfirmen keinen 2.DC als "muss" vorschreiben.

 

 

Sag mal hast du 'nen Knoten in der Leitung? Niemand hat gesagt, ein 2. DC sei ein muss, eben nur schwer zu empfehlen. Ich persöhnlich mache bei Branch Lösungen auch immer zwei DCs damit man Zeit hat sich um das eigentliche Problem zu kümmern (siehe GerhardG). Alles bis auf Print und vielleicht noch E-mail (EX 2007 auch kein Thema) lässt sich redundant ausstatten, DHCP, DNS, AD, Files (DFS/DFS-R), usw. Wenn du da noch was am laufen hast wie SQL, na ja, auch das ginge mit Datenbank Spiegelung, usw.

 

Aber der Punkt hierbei ist, das ist (hoch) Verfügbarkeit und nicht Disaster Recovery. Disaster Recovery ist besically wenn alles ein Scherbenhaufen ist und du von 0 anfangen kannst.

 

 

Die ganz Teuren varianten machen sowieso einen mix von beidem - Main Datacenter und Backup Datacenter mit Replikation dazwischen, und da ist die Idee vom 2. Controller nicht fern.

 

 

Also Jungs, lasst stecken und nehmt die Idee die euch idiologisch, Support technisch und finanziell am besten zusagt, ok? Und vor allem dreht dem Kunden keinen Mist an....

[Daim 12]

<tief Luft hol>

 

in der zeit wo andere noch am aufbau des notbetriebs basteln, kannst du mit jeder besseren backuplösung gleich den orginal server komplett wiederherstellern.

 

Was machst du in einem Netz mit nur einem SBS, wenn dir dabei ein Bauteil wegfliegt, dass natürlich - wie soll es in solchen kleinen Unternehmen auch sein - nicht auf Lager liegt? Wie sieht dann deine Backuplösung aus?

 

 

eine ausgemussterte workstation ist ja ganz nett, auf die idee kommen viele.

 

Genau, denn die haben scheinbar - so wie ich auch - eine andere Auffassung.

 

 

oft wird leider auf kleinigkeiten wie dem nicht übertragbaren onboard scsi controller vergessen

 

Es ist ja kaum zu glauben... schreibe ich etwa in einer anderen Sprache?

Habe ich es denn nicht oft und breit genug erklärt?

 

Du sollst nicht die Maschinen umbauen, sondern schneller die Mitarbeiter wieder zum arbeiten bringen in dem du eben - Daten auf der anderen Maschine zur Verfügung stellst.

Wenn dieser dann auch noch ein DC ist, stehen die Domänendaten auch zur Verfügung, in der man nach Ressourcen oder Informationen suchen kann, die in den Eigenschaften der Benutzerkonten eingetragen sind, oder was auch immer!

 

 

gegen einen zusätzlichen dc spricht natürlich nichts. aber ich sehe mir darin heute keinen vorteil mehr wenn alle wichtigen dienste am sbs laufen. die idee mit der ausgemusterten workstation stammt noch aus zeiten wo man zuerstmal ein betriebssystem und backup software von hand installieren musste, bevor man mit dem restore überhaupt beginnen konnte. heute ist sowas jedoch mit cd und band einlegen erledigt.

 

Nochmals: Denk an das Szenario eines Hardwareschaden auf dem SBS, wobei nichts auf Lager liegt.

Was machst du dann!?!

 

 

beim kunden angekommen sollte man sich um problemlösungen und nicht workarounds beschäfftigen.

 

Mein Reden!

 

</ausschnaufen>

[Daim 12]

vielen Dank, dass es noch weitere Leute hier an Board gibt, die meiner Meinung bezüglich der schnellen Wiederherstellung von Servern (auch per Image wie mit BESR) in kleinen Umgebungen sind und diesen Kleinfirmen keinen 2.DC als "muss" vorschreiben.

 

Dies ist meine LETZTER Versuch dir es zu erläutern!

 

Im OP ging es um, Zitat:

 

Was für eine Disaster-Recovery-Lösung befürwortet Ihr denn?

 

Darunter gehört aber auch ein Hardware-Schaden des SBS, der alle Dienste sowie Daten hat. Wenn dieser crasht, seht ihr alt aus. Mit einer weiteren Maschine kannst du "schnell" einen Betrieb - und sei es noch so klein - aufrecht erhalten.

 

 

Und dann soll darauf eventuell noch ein SQL-2005 laufen, wie auf dem SBS2K3 R2 Premium.:confused:

 

Ich kann nur hoffen das du diese Art von Brille ablegst und versuchst zu verstehen, von was ich spreche.

Als Tipp, lies dir mal diverse Whitepaper von Microsoft bezgl. Disaster-Recovery durch.

 

 

Ich schließe mich deinen Ausführungen voll und ganz an:jau: :jau: :jau:

 

Da wir in einem freien Land leben, steht das jedem zur Verfügung.

 

 

...und möchte es dabei belassen.

 

EOD for me!

[GerhardG 10]

wir können hier noch lange herumreden, es kommt immer auf die sichtweise und die situation an. vielleicht spricht du von einem alters schwachen pc wo ein dc gerade so noch mitläuft? möglicherweise meinst du auch einem ordentlichen oder sogar baugleichen server?

 

wenn wir von sbs umgebungen sprechen, ist meistens wenig geld im spiel. wie erklärst du einem 20 mann betrieb den sinn eines 2ten dc´s der nichts weiter bringt als die verfügbarkeit von active directory? was genau hat er im notfall davon wenn alle aus kundensicht wichtigen dienste beim ausfall des sbs nicht verfügbar sind?

 

die 700-800 euro für eine zusätzliche server lizenz, würde ich in eine ordentliche backup/restore lösung investieren. diese bringt dem kunden schneller zurück in den normalbetrieb und ich hab weniger stress...

 

 

<tief Luft hol>

Was machst du in einem Netz mit nur einem SBS, wenn dir dabei ein Bauteil wegfliegt, dass natürlich - wie soll es in solchen kleinen Unternehmen auch sein - nicht auf Lager liegt? Wie sieht dann deine Backuplösung aus?

 

 

ich nenn dir mal ein paar möglichkeiten:

 

1. wenn der kunde maximal 4 stunden ausfallszeit haben möchte, ist eine komplette maschine auf lager oder der hersteller liefert in der entsprechenden zeit

2. der kunde ist sparsam, für den restore nehmen wir einen besseren pc - je nach datenmenge ist er 1 bis x stunden wieder komplett online

 

 

 

Genau, denn die haben scheinbar - so wie ich auch - eine andere Auffassung.

 

du meinst wie "virtualisierung ist nur hype"? ;)

 

 

Es ist ja kaum zu glauben... schreibe ich etwa in einer anderen Sprache?

Habe ich es denn nicht oft und breit genug erklärt?

 

Du sollst nicht die Maschinen umbauen, sondern schneller die Mitarbeiter wieder zum arbeiten bringen in dem du eben - Daten auf der anderen Maschine zur Verfügung stellst.

Wenn dieser dann auch noch ein DC ist, stehen die Domänendaten auch zur Verfügung, in der man nach Ressourcen oder Informationen suchen kann, die in den Eigenschaften der Benutzerkonten eingetragen sind, oder was auch immer!

 

sorry, aber welche informationen im ad interessieren die endanwender? die brauchen ihre crm/email/file dienste, oder speichert ihr derartige daten im ad? für den endanwender ist active directory nicht sichtbar, sein crm/email/filesystem hingegen schon.

 

natürlich ist active directory einer der ganz besonders kritischen dienste. aber es ist wie sql/exchange/wwi nur ein glied in einer kette die nur als ganzes funktioniert. wenn du den endanwender glücklich machen willst, dann läuft auf der backup maschie eine komplett gespiegelte umgebung und nicht nur ein dc.

 

 

Nochmals: Denk an das Szenario eines Hardwareschaden auf dem SBS, wobei nichts auf Lager liegt.

Was machst du dann!?!

 

ok, nehmen wir mal an der kunde hat keinen servicevertrag und keine backup hardware. ich nehm den nächsten pc mit ausreichend ram/hdd kapazität und fahr einen kompletten restore. die hardware ist bei aktuellen backup/restore produkten mehr oder weniger unbedeutend. ein derartiger restore sollte routine sein, ansonsten hat man sein backup/restore konzept scheinbar nie komplett getestet.

 

was ich nicht verstehe, warum sollte ich mich stundenlang mit dem aufbau eines notbetriebes kümmern? der notbetrieb sollte schon laufen bevor der kunde mich anruft, jeder windows client bringt dazu mehr als genug boardmittel mit.

 

beim kunden angekommen sollte man das problem lösen und keine zeit mit workarounds vergeuden. insbesondere wenn du die GESAMTE umgebung in kürzester zeit wiederherstellen kannst.

 

 

Mein Reden!

 

 

politiker reden, wir handeln ;)

[Deejablo 10]

wenn wir von sbs umgebungen sprechen, ist meistens wenig geld im spiel. wie erklärst du einem 20 mann betrieb den sinn eines 2ten dc´s der nichts weiter bringt als die verfügbarkeit von active directory? was genau hat er im notfall davon wenn alle aus kundensicht wichtigen dienste beim ausfall des sbs nicht verfügbar sind?

 

Berater die mir einen SBS ohne zusätzliche Absicherung der Dienste bieten können auf der Türschwelle umdrehen...

Und ja... Auch einen SBS kann man redundant halten. AD, DHCP, DNS usw. ist klar... 2. DC aufgesetzt auf nem uralt-Rechner, in die Ecke gestellt und gut.

Email synchronisiert man einfach per IMAP auf nen OpenSource Mail-Server und bindet die Postfächer einfach als Backup ein. Webseiten redundant zu halten sollte nun wirklich kein Problem darstellen usw...

 

Das Problem an einem DR ist schlicht der Zeitfaktor. Unter Zeitdruck passieren dann im Normalfall die meißten Fehler. Daher würde ich grundsätzlich erstmal die Arbeitsfähigkeit des Netzwerkes wiederherstellen und mich danach in aller Ruhe um das eigentliche Problem kümmern.

 

Und wenn man mal über den Tellerrand eines SBS hinausschaut, wird man feststellen, dass es da draußen jede Menge guter Ansätze gibt, die einer reinen Imaging Lösung um Lichtjahre vorraus sind. Und dazu noch preislich sehr attraktiv sind; auch für kleine Unternehmen.