One-stop DR solution for SBS 2003
Hi,
I have been wrestling with this issue for a while now and I still don't seem to be nearer a complete solution. I simply want a reliable DR solution for our SBS server, which allows us to restore to same or different hardware reliably and quickly, with no fallback. However it's not the only DC on the network, we have three.
I have looked into ASR recovery - this seems to be fine when running a backup/restore of a test server with a simple disk config but our server has disk mirroring for the system partition (windows software RAID), and has an external RAID unit running Exchange. For some reason, there are Exchange installation files on this RAID unit, so ASR deems all three disks as system disks and backups them all up, making life slooooow, and the restore process is very fussy. I'd rather not rely on this in a real situation. Plus the floppy disk issue isn't ideal.
We also have Symantec backup exec backing our data up - we could use this to effectively restore a system using a fresh install, plus system backup, but this won't work on the SBS server as you need to rejoin the new machine to the domain with the same name as the failed one. Not possible with our DC. We've also looked at the built-in backup for SBS, but the process of restoring to different hardware seems laborious.
We have also looked at imaging software - fine if we only had one DC, but we have three, on two sites. Using an image based backup means possible USN rollbacks and RID master issues (as it holds all 5 FSMOs). Acronis do an SBS edition of their True Image Echo, but I'm unsure as to whether this is suitable in a multi DC environment, as SBS is typically a one-DC setup.
Is there someone in a similar situation to us with a tried and tested answer for this? Am I missing something? We would prefer to use an imaging product, but want to avoid the issues relating to imaging of domain controllers.
Thanks in advance.
I have been wrestling with this issue for a while now and I still don't seem to be nearer a complete solution. I simply want a reliable DR solution for our SBS server, which allows us to restore to same or different hardware reliably and quickly, with no fallback. However it's not the only DC on the network, we have three.
I have looked into ASR recovery - this seems to be fine when running a backup/restore of a test server with a simple disk config but our server has disk mirroring for the system partition (windows software RAID), and has an external RAID unit running Exchange. For some reason, there are Exchange installation files on this RAID unit, so ASR deems all three disks as system disks and backups them all up, making life slooooow, and the restore process is very fussy. I'd rather not rely on this in a real situation. Plus the floppy disk issue isn't ideal.
We also have Symantec backup exec backing our data up - we could use this to effectively restore a system using a fresh install, plus system backup, but this won't work on the SBS server as you need to rejoin the new machine to the domain with the same name as the failed one. Not possible with our DC. We've also looked at the built-in backup for SBS, but the process of restoring to different hardware seems laborious.
We have also looked at imaging software - fine if we only had one DC, but we have three, on two sites. Using an image based backup means possible USN rollbacks and RID master issues (as it holds all 5 FSMOs). Acronis do an SBS edition of their True Image Echo, but I'm unsure as to whether this is suitable in a multi DC environment, as SBS is typically a one-DC setup.
Is there someone in a similar situation to us with a tried and tested answer for this? Am I missing something? We would prefer to use an imaging product, but want to avoid the issues relating to imaging of domain controllers.
Thanks in advance.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Sorry for delay in response - Easter hols and all...
Raj-GT - thanks for the link - I'm downloading a trial version of this to test.
Mestha - would you mind elaborating on the issues involved with restoring an Exchange/DC combination? I think I have quite a good knowledge of Server 2003/AD, but Exchange and it's exact reliances on AD are probably my weak point... (either that or point me in the right direction).
Any help would be appreciated...
Raj-GT - thanks for the link - I'm downloading a trial version of this to test.
Mestha - would you mind elaborating on the issues involved with restoring an Exchange/DC combination? I think I have quite a good knowledge of Server 2003/AD, but Exchange and it's exact reliances on AD are probably my weak point... (either that or point me in the right direction).
Any help would be appreciated...
When Exchange is on a DC, you have to restore the DC functionality first. Then you have to restore Exchange using that DC.
If Exchange and the DC were separate, then all you have to do is build a replacement machine with the same name and run the setup with the DR options. Exchange then pulls the information out of the domain.
Restoring a DC is painful, anyone who has done it will tell you that.
Simon.
If Exchange and the DC were separate, then all you have to do is build a replacement machine with the same name and run the setup with the DR options. Exchange then pulls the information out of the domain.
Restoring a DC is painful, anyone who has done it will tell you that.
Simon.
ASKER
Thanks for the quick reply. I agree - if it were just a DC, I might not even worry about restoring a failed server. Just cleanup, install a new one and DCPROMO. The fact that it's an SBS means it's also an Exchange server and basically the linchpin of our network. I've actually came across a tip which avoids USN rollbacks after an image restore:
1. Restore the machine image.
2. Boot straight into DSRM mode.
3. Perform an additional system state restore so the server 'knows' it's been non-auth restored and checks with it's replication partners on next boot (there also a reg hack which will do the same).
4. Boot into normal mode.
5. Perform a restore of Exchange Information store from most recent backup (in my case this would be using the Backup Exec Exchange agent).
Considering this method, what issues would I have with Exchange? Would this be OK or are there any obvious pitfalls that you can see to this method? I know the best way to find out is to test myself and I'm about to start to do so, but any pointers would be appreciated.
Thanks again.
1. Restore the machine image.
2. Boot straight into DSRM mode.
3. Perform an additional system state restore so the server 'knows' it's been non-auth restored and checks with it's replication partners on next boot (there also a reg hack which will do the same).
4. Boot into normal mode.
5. Perform a restore of Exchange Information store from most recent backup (in my case this would be using the Backup Exec Exchange agent).
Considering this method, what issues would I have with Exchange? Would this be OK or are there any obvious pitfalls that you can see to this method? I know the best way to find out is to test myself and I'm about to start to do so, but any pointers would be appreciated.
Thanks again.
If the domain is intact, then restoring Exchange should be a matter of running the installation of Exchange with the DR switch. Once complete, the relevant wizards are run in SBS to ensure everything is correct.
Simon.
Simon.
ASKER
Thanks, but if you could just clarify one more point:
If I was to restore SBS from an image, perform a non-auth restore and boot the server back up, all I would require would be an Info Store restore of the data (that is providing I lost this as well). Correct?
If I was to perform a fresh install of SBS to the point before the SBS wizards, would this not try to create a new domain, and therefore not allow me to perform a DR install of Exchange back into the existing Domain?
Sorry if these questions are simplistic...
If I was to restore SBS from an image, perform a non-auth restore and boot the server back up, all I would require would be an Info Store restore of the data (that is providing I lost this as well). Correct?
If I was to perform a fresh install of SBS to the point before the SBS wizards, would this not try to create a new domain, and therefore not allow me to perform a DR install of Exchange back into the existing Domain?
Sorry if these questions are simplistic...
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks for the info. I'll look up the SBS migration method.
My thinking was that the image would only be used in the event of a server hardware failure, probably taking an image of just the system partition once a week. Then I would be using Backup Exec to supplement this using a daily system backups and weekly full/daily incremental Exchange backups. I wouldn't be using images to backup Exchange data.
I know SBS by default uses circular logging, but I have disabled this in order to allow me to perform incremental backups and also allow me to restore 'up to the minute' in the case of a DB loss.
My logic is that in the event of a hardware loss with no identical replacement, I would restore the most recent image to different hardware (looking at Acronis Universal Restore for this), booting the 'new' SBS server into DSRM and restoring the most recent system state non-authoritatively. When this server boots back up, it'll pull from it's replication partners preventing a USN rollback. Then I would restore the Exchange DB if I needed to. The Exchange DB/Log files are on external storage so this may or may not be necessary. Is this logic flawed?
One more thing, if all of our users are running Outlook cached with local ost files, and I do lose the Exchange DB (or only restore to a much earlier point), what happens when the clients sync with the server - do they lose the emails from their .ost or does the server re-build it's DB, or neither?
I know I'm starting to stray now so this is my last lot of questions and then I'll close as answered. Thanks in advance....
My thinking was that the image would only be used in the event of a server hardware failure, probably taking an image of just the system partition once a week. Then I would be using Backup Exec to supplement this using a daily system backups and weekly full/daily incremental Exchange backups. I wouldn't be using images to backup Exchange data.
I know SBS by default uses circular logging, but I have disabled this in order to allow me to perform incremental backups and also allow me to restore 'up to the minute' in the case of a DB loss.
My logic is that in the event of a hardware loss with no identical replacement, I would restore the most recent image to different hardware (looking at Acronis Universal Restore for this), booting the 'new' SBS server into DSRM and restoring the most recent system state non-authoritatively. When this server boots back up, it'll pull from it's replication partners preventing a USN rollback. Then I would restore the Exchange DB if I needed to. The Exchange DB/Log files are on external storage so this may or may not be necessary. Is this logic flawed?
One more thing, if all of our users are running Outlook cached with local ost files, and I do lose the Exchange DB (or only restore to a much earlier point), what happens when the clients sync with the server - do they lose the emails from their .ost or does the server re-build it's DB, or neither?
I know I'm starting to stray now so this is my last lot of questions and then I'll close as answered. Thanks in advance....
This line: "I know SBS by default uses circular logging" is wrong. SBS does not use circular logging by default. If circular logging was enabled then someone has set that.
Even if the database is on separate storage, you still have to bring things up to date. If you are looking at a "bang" failure, then the transaction logs would probably need to be discarded because it is a new system where you have done the restore on. You would need to run a repair on the database to get the database accepted by the new (DR) install of Exchange, and a repair makes the logs invalid.
In theory, if the clients are in cached mode they should repopulate the database. I have always said that for safety, do an export of the client to a PST file before bringing exchange back on line, then you have a second set of data - just in case.
Simon.
Even if the database is on separate storage, you still have to bring things up to date. If you are looking at a "bang" failure, then the transaction logs would probably need to be discarded because it is a new system where you have done the restore on. You would need to run a repair on the database to get the database accepted by the new (DR) install of Exchange, and a repair makes the logs invalid.
In theory, if the clients are in cached mode they should repopulate the database. I have always said that for safety, do an export of the client to a PST file before bringing exchange back on line, then you have a second set of data - just in case.
Simon.
ASKER
I think the reason it was enabled was because we have never configured SBS backup - apparently it's enabled until you do this. We have always used third party backup software so I guess this is why.
Thanks for the pointers. It's given me something to chew on whilst testing.
Many thanks....
Thanks for the pointers. It's given me something to chew on whilst testing.
Many thanks....
ASKER
Thanks again...
Imaging tools I don't think are going to cut it in this scenario.
You need to backup the key data - Exchange information store for example.
Then you would need to reset the computer name so that SBS can be installed fresh. Once it has been installed, Exchange can be restored using the standard process for restoring Exchange.
Painful, I have to say.
Simon.