>I tend to disagree - but I admit you seem to know what you're talking
>about :-)
I tend to disagree with that:) Heh...
>Anyway, my scenario in more detail - I'd be happy to see any hidden
>pitfalls!
>Use a secondary windows /typically PE-based) to boot. Create the
>partitions you originally had on the system in question (I'm aware of
>Server 2k8's service partition...)
>Assign drive letters as before, and format as before.
>Start FD, and restore a complete backup to it's original location.
>Make sure you've got the partitions activated, boot loader in place, etc.
>Reboot the restored system.
Ok, if the server is a dc, once it restarts you just caused a USN Rollback.
Don't do that this way, use the method I outlined, and use OE provided tools
like dcpromo and ntdsutil to cleanup after yourself.
If the server was an Exchange server, you probably just casued other AD related
issues, things aren't always simple, exchange is tied to ad heavily. It's not
a postfix daemon with 3-4 text files.
>Both theory and my experience tell me that you'll end up with a
>complete windows, happily running where it was backed up.
>For sanity#s sake, you next apply the system state backup you -
>hopefully - captured during your regular backups, following
>Microsoft's procedures.
>
>After three reboots, you should have your system in a consistent,
>mostly up-to-date state.
Maybe, depends on what it was doing before... Remember, hardly anything
in Windows (unlike Linux) is just a txt file:) Windows networks in the
simplest form are fairly complex with the "complexity" hidden from the
casual admin. A single server setup at a company of 4 users probably
_is_ simple. A multi DC infrastructure w/ Exchange, Sharepoint and other
application servers distributed or not, is _not_ simple.
>Be aware that some applications - typically everything based on
>databases - may require additional steps, for example to replay
>transaction logs written and backed up after the last regular back up.
Well some errors can't be fixed after easily.
>That alone can be a problem - only identifying everything you had
>before requires a full-blown configuration and deployment management
>system, in my experience :-(
Well, now we digress. Hypothetically speaking, this said admin is incharge
of the Enterprise's DR without this knowledge? Huh...
>> then add in only
>> applicable data.
>
>This is even worse (though getting better at least with Microsoft's
>applications) as it's really hard to determine wat is "applicable data".
Well, what can I say, you gotta know what you're doing:) technet/msdn are
great resources, and nothing beats lab'ing up a procedure to validate!
>> You are *will* break all sorts of things pulling the rug
>> out from under complicated applications like AD/Exchange etc...
>
>True, but with the combination of VSS and system state backup /
>restore plus the things you (should) know about managing AD you get to
>an up-to-date, restored, system quite quickly - much faster than
>reinstalling tons of applications, updates, patches, service packs,
>bug fixes and the like one by one.
Well, wrt to AD, you just can't do some things that way w/o breaking it
all, severely! Remember, FOSS isn't the only software you get to keep the
pieces if you break it:) The OP would be most inclined to read technet,
document, then validate. DR w/o validation is barely any better than no
DR at all IMHO.
>Thanks for your insight!
And yours!
jlc
------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
