Drive Imaging and AD

[jas0n]

Are there any specific problems with regards to drive imaging and active
directory?

I am thinking of having a regular drive image taken of my servers system
drives for quick recovery purposes. This is likely to be once per month
plus an image prior to any major hardware/software change. Im choosing
once per month due to not wanting to be near the AD tombstone 60 day
period as well as not being too onerous a job that will become a pain in
itself!

I take tape backups daily and as well as system drives and data they
include the system state so I was thinking a restored image + restore of
most recent system state should get me back to the most workable
position unless there are major hardware changes.

That be about right?

 

[Herb Martin]

Are there any specific problems with regards to drive imaging and active

directory?

As long as you can get a consistent (file and record locking etc.)
image that is fine.

I am thinking of having a regular drive image taken of my servers system
drives for quick recovery purposes. This is likely to be once per month
plus an image prior to any major hardware/software change.

Fine, just realize that they are only good for about 2 months
(on DCs the tombstone lifetime defaults to 60 days.)

Im choosing
once per month due to not wanting to be near the AD tombstone 60 day
period as well as not being too onerous a job that will become a pain in
itself!

And that 30 days is a pretty long interval if you make AD
changes so you might consider system state backups on
a much more frequent basis.

I take tape backups daily and as well as system drives and data they
include the system state so I was thinking a restored image + restore of
most recent system state should get me back to the most workable
position unless there are major hardware changes.

Then it can't hurt. BTW, most people never TEST their backups
and are then disappointed to find that they are worthless, more
often than one would expect.

 

[Dean Wells [MVP]]

Drive imaging is a solution for AD backup purposes under only three very
constrained situations -

1. You have only 1 DC
2. You have drive imaged all DCs in all domains in the entire forest at
precisely the same time and will restore all DCs from those images
simultaneously
3. You have imaged a DC representing each partition within the forest
and are prepared to forcibly demote, metadata clean and re-introduce ALL
other DCs

It seems that this question is haunting me at the moment as I've been
asked it more times than I count over the past 2 weeks or so (TechEd
being the primary source). Restoring an imaged DC outside of the
constrained scenarios above causes an issue known as USN rollback and
will almost certainly leave your forest in an inconsistent state
....worse, the forest will believe itself to _be_ consistent. It is
neither supported nor recommended.

Note that this also applies to any form of backup that does not inform
the Directory Service that it has been restored (this requires a GUID
known as the Invocation ID to be regenerated).

 

[Chris Salter]

Drive imaging is a solution for AD backup purposes under only three very
constrained situations -

1. You have only 1 DC
2. You have drive imaged all DCs in all domains in the entire forest at
precisely the same time and will restore all DCs from those images
simultaneously
3. You have imaged a DC representing each partition within the forest
and are prepared to forcibly demote, metadata clean and re-introduce ALL

How about restoring the server from the ghost image(unplugged from
network). Then doing a non-authoritative system state restore from
backup then replugging it back into network? Is this likely to work?

(obviously dependent on taking nightly backups, and regular ghosts)

 

[Dean Wells [MVP]]

Why use Ghost to restore it if you already have a System-State backup to
hand?

 

[Herb Martin]

It seems that this question is haunting me at the moment as I've been

asked it more times than I count over the past 2 weeks or so (TechEd
being the primary source). Restoring an imaged DC outside of the
constrained scenarios above causes an issue known as USN rollback and
will almost certainly leave your forest in an inconsistent state
...worse, the forest will believe itself to _be_ consistent. It is
neither supported nor recommended.

How does a normal (tape/disk) backup work differently?

 

[Dean Wells [MVP]]

They alter the Invocation ID within the DIT during the restore ...

 

[Dean Wells [MVP]]

As an aside, the Invocation ID is also altered on a 2003 DC when an app.
NC is added, removed and later re-added. This is the motivation for the
existence of the msDS-RetiredReplNCsignatures (or something along the
lines of that name), it records the NCs held by a particular DC for its
lifetime (maintained by a DC's NTDSDSA instance I believe).

 

[jas0n]

How about restoring the server from the ghost image(unplugged from
network). Then doing a non-authoritative system state restore from
backup then replugging it back into network? Is this likely to work?

(obviously dependent on taking nightly backups, and regular ghosts)

Yes, thats how I would have tackled it ....

 

[jas0n]

Why use Ghost to restore it if you already have a System-State backup to
hand?

my thinking for an image is if the file system is toasted it would be
quick to restore the image and then a non authorative restore of the
system state whilst the system was off the network ... at which point
plug it back in

would that work?

..... i am soon to have a test server to start doing some thorough DC and
exchange server restore testing from existing ultrium backups

 

[Dean Wells [MVP]]

Yes.