DC per Acronis sichern - Wie?

[Darksun777 10]

http://support.microsoft.com/?kbid=875495

 

Oder mit anderen Worten: Der ohne Systemstate wiederhergestellte DC weiss nichts davon, dass er wiederhergestellt wurde, und schlimmer, die anderen DCs wissen es auch nicht. So weiss keiner der Replikations-Parteien über die "fehlenden Informationen" bescheid. Bei einem Systemstate Restore wird dem DC aber mitgeteilt, das er veraltet ist. Das ist der Unterschied...

 

 

 

P.S.: Wenn ein DC für längere Zeit ausgeschaltet wird, bekommen die anderen DCs das mit (Eventlog Einträge auf den anderen DCs). Das Wiederherstellen eines DCs bleibt ihnen jedoch verborgen :wink2:

 

 

Eine sehr verzwickte Sache ! :)

 

Es ist doch aber auch so, daß wenn mein zweiter DC abraucht (also AUS ist), daß die restlichen DCs das auch mitbekommen ! (Eventlog)

 

Ich sehe da immer noch keinen rechten Unterschied zwischen "nur ausgeschaltet" oder "ausgeschaltet + Imagerestore".

 

Ich bezweifle ja gar nicht das ihr Recht habt, also das es dann zu diesem USN-Rollback kommt .. aber ich kann es mir nicht so recht erklären wieso.

 

Nochmal zur Überlegung:

 

Situation 1:

 

 

DC1 ---> Online

 

DC2 ---> wird heruntergefahren, ist zwei Tage offline.

 

Der erste DC merkt ja gleich das der zweite weg ist (Eventlog). Passiert nichts weiter.

2 Tage später fahre ich DC2 wieder hoch --> DC1 bekommt es mit, die Replikation wird wieder hergestellt und alles ist gut. (DC2 wird geupdatet)

 

Dieses Szenario habe ich selbst schon mehrmals so gehabt.

 

 

Situation 2:

 

DC1 ---> Online

 

DC2 ---> Systemplatte stirbt. Image von vor 3 Stunden ist vorhanden.

 

Image wiederherstellen ,DC2 neu booten.

 

Müsste es JETZT nicht so sein, als ob DC2 nur 3 Stunden ausgeschaltet gewesen wäre ?

 

Ihr sagt jetzt mit Sicherheit NEIN, aber wieso ? :suspect: :)

 

Viele Grüße!

[traced82 10]

Ich denke, dass der erste DC weiss was er NACH dem Image noch so alles auf den zweiten DC repliziert hat. Diese Änderungen sind aber dann plötzlich weg wenn das Image wieder eingespielt wird. Wenn Du ihn nur aus und wieder an machst (den zweiten), dann sind diese Änderungen ja noch vorhanden.

Denke hier liegt der Hund begraben?!

 

vg

Basti

[Velius 10]

Eigentlich ist es doch ganz einfach:

 

Alle DC sind über Ihre Replikationspartner informiert, und versuchen die auch regelmäsig, jedenfalls bei Änderungen, auch wenn nur der beispielsweise der Display Name eines Benutzers geändert wird, sich zu replizieren.

 

Davon wird ausgegangen, dass alle DCs die selben Informationen haben.

 

Sagen wir mal DC1 hat die Änderung erhalten und versucht jetzt seinen Replikationspartner wie sie im in Sites uns Services zugeteilt sind Verbindung aufzunehmen. Das könnte etwa so aussehen:

 

- Vor der Replikation

DC1

-->DC2

-->DC3

 

- Nach der Replikation

DC1

DC2

DC3 Funktioniert auch bei einem ausgeschalteten/nicht erreichbaren DC, da sich die Replikationspartner erinnern wann dieser zuletzt erfolgreich repliziert hat

 

 

Alle haben schlussendlich wieder denselben Stand. Nun kommt aber ein geclonter Controller zurück in's Verzeichnis:

 

- Vor der Replikation

DC1

-->DC2

-->DC3

 

- Nach der Replikation

DC1

DC2

-->DC3. Es tretten inkonsitenzen auf, da der Controller nicht denselben USN Stand bei einigen Attributen und Objekten vor der Replikation hatte. Keiner der Controller weiss aber, welcher Datenstand der Richtige ist. Für beide müssen es wie Änderungen aussehen.

 

 

Jetzt kommt ein Dc mit Systemstate Restore dazu:

 

- Vor der Replikation

DC1

DC2

<--DC3

 

- Nach der Replikation

DC1

DC2

DC3 Der mit dem Systemstate wiederhergestellte DC weiss darüber bescheid, dass sein gesammter Datenstand veraltet ist, und kontaktiert deshalb seine Partner und bezieht die Änderungen

 

 

Kann sein, dass nicht alle Details richtig sind, aber so etwa muss das aussehen. Logisch wäre es jedenfalls zumindest ;)

 

 

Legende:

*Dunkelrot = Änderungen am Verzeichnis

*Dunkelblau = Wiederhergestellter Controller von einem Image

*Lila = Wiederhergestellter Controller vom Systemstate Backup

--> Änderungen werden vom Quell-Controller gepushed

<-- Änderungen werden vom Quell-Controller gepulled

 

 

 

Situation 2:

 

DC1 ---> Online

 

DC2 ---> Systemplatte stirbt. Image von vor 3 Stunden ist vorhanden.

 

Image wiederherstellen ,DC2 neu booten.

 

Müsste es JETZT nicht so sein, als ob DC2 nur 3 Stunden ausgeschaltet gewesen wäre ?

 

!

 

Kann sein das du Glück hattest. Solange keine Veränderungen am Verzeichnis seit dem letzten Image gemacht wurden.... In einem grossen Forest würde ich aber nicht auf 3 Stunden wetten. :wink2:

[traced82 10]

:jau: Das ja mal ausfürlich genug, Danke!!

 

vg

Basti

[TheSpawn 11]

Jetzt muss ich doch auch mal ne frage dazu stellen.

 

Was passiert wenn ich ein Image eines DC´s zurücksichere, von diesem dann ein Backup des systemstate mache, einen Reboot und den sysstate dann wiede einspiele?

 

Damit müsste der DC doch wissen das die Daten veraltet sind.

 

Dies ganze ist natürlich rein Theoretisch zu verstehen, ich sichere meine Server immer auf Band.

 

Gruß

TheSpawn

[TheSpawn 11]

Habe das ganze heute mal in einer Testumgebung ausprobiert.

 

2 DC´s W2K3

 

Ghostimage gezogen ( Im Dos Modus), am 1 DC der durchlief neue User angelegt GPO geändert etc.

 

4 Std den 2ten DC aus gelassen bzw. das Ghostimage zurück kopiert und die Kiste einfach nicht wieder eingeschaltet. (Musste eh noch was anderes machen)

 

2ter DC an, in den Replmon & die Protokolle geschaut, Fahler sind da, Rep. Partner nicht gefunden, Rep. nicht erfolgreich etc.

NTBackup aufgerufen Sysstate gesichert. Server im Abgesicherten Modus für die Verzeichniss rep. gestartet, sysstate zurück gesichert.

 

Nach dem Neustart Replmon gestartet, re. Mt. auf die jeweiligen Einträge und manuel die Replikation angeworfen.

 

Siehe da, alle Roten Kreuze verschwinden, und er läuft wieder einwandfrei.

 

Ist dies nun eine Möglichkeit für den Fall das man nix anderes mehr zur Verfügung hat, oder habe ich in diesem Fall einfach glück gehabt?

 

Gruß

TheSpawn

[varnik 10]

Habe das ganze heute mal in einer Testumgebung ausprobiert.

 

2 DC´s W2K3

 

Ghostimage gezogen ( Im Dos Modus), am 1 DC der durchlief neue User angelegt GPO geändert etc.

 

4 Std den 2ten DC aus gelassen bzw. das Ghostimage zurück kopiert und die Kiste einfach nicht wieder eingeschaltet. (Musste eh noch was anderes machen)

 

2ter DC an, in den Replmon & die Protokolle geschaut, Fahler sind da, Rep. Partner nicht gefunden, Rep. nicht erfolgreich etc.

NTBackup aufgerufen Sysstate gesichert. Server im Abgesicherten Modus für die Verzeichniss rep. gestartet, sysstate zurück gesichert.

 

Nach dem Neustart Replmon gestartet, re. Mt. auf die jeweiligen Einträge und manuel die Replikation angeworfen.

 

Siehe da, alle Roten Kreuze verschwinden, und er läuft wieder einwandfrei.

 

Ist dies nun eine Möglichkeit für den Fall das man nix anderes mehr zur Verfügung hat, oder habe ich in diesem Fall einfach glück gehabt?

 

Gruß

TheSpawn

Darüber spricht man doch die ganze Zeit.

Image zurückspielen und sofort Systemstate per ntbackup wiederherstellen.

[TheSpawn 11]

Ja aber ich habe den sysstate erst NACHDEM ich das Image zurückgespielt habe mittels NTBackup überhaupt gesichert.

 

Also quasi nachdem das Kind bereits in den Brunnen gefallen ist.

 

Oben wurde jedoch gesagt, das der sysstate der vor dem zurückspielen gesichert wurde von nöten ist.

 

Gruß

TheSpawn

[varnik 10]

Ähhm.. Hab's überlesen.

Lasse jetzt beide laufen und nimm einige Änderungen vor. Und morgen oder besser nächste Woche bespiele das heute abgezogene Image noch mal...

[TheSpawn 11]

Macht ja nix...... :cool:

 

Werde ich machen, is ja eh ein Testsystem.

 

Berichte wenn ich es getestet habe.

 

Gruß

TheSpawn

[Darkmind 10]

Hi Velius

 

Danke für deine Ausführliche erklärung. :jau:

 

Ist ich sehr hilfreich!

 

Grüsse

 

Darkmind

[Velius 10]

Das steht beim Acronis Forum (mein Post #14 ):

 

Two methods:

 

One: Do a daily scheduled ntbackup of system state to a data disk - if you ever need to restore an image of a DC, reboot in non-authorative domain controller restore mode (F8 at startup) and restore the latest NTbackup system state. DC will think it's non-auth restored, and at reboot will request DC information from the other DC's.

 

Just *never ever* run the restored DC in normal mode before doing this, or you are in USN rollback hell.

 

Method two:

 

Only if your 2003 DC's are running SP1 - you can "fool" a DC in thinking it's non-authoratively restored without actually running ntbackup - again, if you restored a DC and started it normally, you are scr*w*d.

 

To restore a previous image when USN rollback has not occurred

1.Using the previous , start the domain controller in Directory Services Restore mode.

2.In a registry editor, if the entry DSA Previous Restore Count under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters is visible, make a note of the value. If the entry is not visible, assume a value of 0. Do not add the entry.

3.Add the registry entry Database restored from backup under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Data type: REG_DWORD

Value=1

This setting creates a valid system state backup and immediately restores the backup.

4.Restart the domain controller normally.

5.In the registry, check to be sure that the value in DSA Previous Restore Count is equal to its previous value plus 1.

6.In the Directory Service event log, check to see that event ID 1109 appears. This event confirms that the .vhd file has been restored and the invocation ID has been changed. Event ID 1109 places the following information in the log:

Active Directory has been restored from backup media, or has been configured to host an application partition. The invocationID attribute for this directory server has been changed. The highest update sequence number at the time the backup was created is a%n

%nInvocationID attribute (old value):%n%1

%nInvocationID attribute (new value):%n%2

%nUpdate sequence number:%n%3

%n

%nThe invocationID is changed when a directory server is restored from backup media or is configured to host a writeable application directory partition.

 

This works for all imaging based products - the actual text above is from MS, they had to come up with something that works in virtual PC environments, because DC's get "paused" for more than 12 hours in these situations - works for physical as well!

 

 

Es ist gut möglich, dass der Trick mit dem Systemstate nachdem es schon passiert ist funktioniert. Schliesslich ist oben beim W2K3 SP1 auch ein Trick beschrieben, der dem Controller sagt, dass er wiederhergestellt wurde...

Sauberer ist es meiner Meinung nach doch, wenn man den Systemstate vorher oder regelmäsig sichert und dann in DS Restore Mode geht. ;)

[blub 115]

die Effekte eines USN-Rollbacks sind in diesem Dokument ganz gut beschrieben

 

http://www.microsoft.com/downloads/details.aspx?FamilyID=64DB845D-F7A3-4209-8ED2-E261A117FC6B&displaylang=en

 

--

The following sequence of events illustrates how this inconsistency occurs and its effects on replication:

 

In the hub site, an administrator installs three domain controllers in the same domain:

DC1 is installed on native hardware.

VDC2 is installed in a virtual machine.

DC3 is installed on native hardware.

An administrator creates 100 user accounts on VDC2, corresponding to USNs 101 through 200 on VDC2, all of which replicate to DC1 and DC3.

An operating system image is created of VDC2 that contains knowledge of objects corresponding to local USN 1-200 on VDC1. This image is created by making a copy of the .vhd file. A system state backup is not performed.

On VDC2, 100 passwords for the existing users created in step 2, corresponding to USNs 201 through 300, are reset and replicate to DC1 and DC3.

DC3 is taken offline for a hardware update.

On VDC2, 50 new computer accounts, corresponding to USNs 301 through 350, are created and replicate to DC1 while DC3 is offline.

Prior to replicating changes corresponding to USN 301 through 350 to DC3, VDC2 experiences a catastrophic failure.

Against recommendations, the administrator attempts to restore VDC2 by starting the .vhd image copy that was created in step 3. VDC2 starts with knowledge of local USNs 1 through 200 that existed at the time the .vhd file was copied.

DC3 is brought back online.

When an administrator makes subsequent changes on VDC2, these changes begin at USN 201. Because the operating system image created at an earlier point in time was essentially copied into place, as opposed to the recommended method of restoring system state, VDC2 maintains its original invocation ID. As a result, DC1 and DC3 maintain their up-to-dateness values for VDC2 of USN 350 and USN 300, respectively. Without administrative intervention, DC1 and DC3 request changes from VDC2 according to their current up-to-dateness values, resulting in the following inconsistencies:

DC1 does not receive changes for USNs 201 through 350 because DC1 continues to request changes for USNs that are greater than 350.

DC3 does not receive changes for USNs 201 through 300, but does receive changes for USNs 301 through 350 because DC3 requests changes for USNs that are greater than 300.

Without administrative intervention, DC1 and DC3 continue replicating updates from VDC2 that correspond to changes greater than USN 350.

---

 

Das Starten des virtuellen DCs von einem restorten File entspricht dem Imaging

 

cu

blub

[Gadget 37]

Bin gerade nochmal über nen interessanten Beitrag dazu gestossen, das setzen des Registry-Keys "Database restored from backup" reicht nicht aus u. wird leider in der MSFT Doku zu Virtual Server auch unterschlagen.

 

Restoring DC from image or saved VHD

http://blogs.dirteam.com/blogs/tomek/archive/2006/04/17/790.aspx

 

In short words, using registry entry we are forcing DC to perform backup and restoration directly after start for the first time after restoration time. This changes Invocation ID for DC database, and prevents from USN rollback problem to occur....

 

....what it is missing is need to perform also procedure of restoration for SYSVOL with BurFlags D2 or D4 value depends on the case .....

 

LG Gadget

[TheSpawn 11]

Macht ja nix......

 

Werde ich machen, is ja eh ein Testsystem.

 

Berichte wenn ich es getestet habe.

 

So habe die ganze Sache jetzt mal ne Weile laufen lassen, und auch mal einiges "rumgespielt" an der AD auf den beiden Servern.

 

Bis jetzt schaut das wirklich so aus, als ob das geklappt hätte.

Die DC´s replizieren ordentlich miteinander, es gibt keine Fehlereinträge in den Logfiles...

 

Gruß

TheSpawn