Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I work for a small business with 25 users and 2 servers.

1 server is the DC running Windows Server 2003/Exchange 2003.

We want a reliable disaster recovery strategy for this server without having to spend a lot of money.

We take regular backups but I have been advised that only an identical server will allow them to be restored easily.

I'm trying to come up with a solution that means we don't have to buy two servers at twice the cost everytime we upgrade. I'm toying with the idea of upgrading our DC more frequently (say every 3 years) and then using the old server as the recovery server (temporarily - until we can source a replacement server). However, I won't know whether the backups will restore on the old server until I try it!

We're planning to upgrade to Server 2008R2 in the near future so I'm hoping the backup tools will give me some success in restoring to different hardware (or perhaps I can use hyper-v if not).

So what I am wondering is whether it is a idea to use old hardware as a disaster recovery strategy (providing we regular test it obviously!).

share|improve this question
2  
?? reliable disaster recovery strategy for this without having to spend a lot of money ?? –  Nifle Mar 6 '11 at 14:07
    
By avoiding spending a lot of money, I mean avoiding having to buy 2 servers at a time! –  user64300 Mar 6 '11 at 14:22
    
Only buy one server each time you upgrade and keep the old one as your emergency replacement. Why make it any more complicated than that? –  John Gardeniers Mar 6 '11 at 20:43

3 Answers 3

Use Acronis to restore your server onto disparate hardware.

share|improve this answer

I would make the jump to Hyper V to begin with. You can make a really effective DR plan using Hyper V, and it will give you more scope for expansion in the future without having to add physical servers with their attendant utility costs and location issues.

In fact I would start by adding a well specified server with at least 12GB RAM and a virtual enabled chip to your inventory. You can download an evaluation copy of Microsoft Virtual Machine Manager (VMM) which will enable you to convert your Exchange Server to a virtual copy. Uninstall VMM and then use the Exchange box for something else, e.g. Hyper V if it is able. And run Exchange as a VM, which is fine.

Once you are running a virtual environment you will enjoy much better flexibility, plus the move virtual machine backups between hardware (NB: there is an option to do this in Hyper V Settings). Backing up a virtual machine is as simple as right-click-copy.

All the while, keep existing physical domain controller. Virtual environments really need a physical DC, plus you can add an additional virtual DC for good measure into your virtual environment. When your physical DC goes down you'll still be running good by it's virtualised counterpart, in addition, you can build up any replacement physical DC by swinging it from the virtual one. It should bother you that you only have one DC - this is dangerous in terms of exposing you to the very time consuming task of restarting a new domain if your single DC goes down. Also, while your DC is down how are you going to recover your DC dependent services like Exchange? Anyone considering DR should have a second DC.

One last thing to consider is your recovery window - how quickly do you want to recover, and how recent do you want your backup. If the answers is minutes not hours, then look at Microsoft Data Protection Manager (which is relatively inexpensive and has an excellent offsite facility). If like most people you can afford hours and a day or two, then you can backup to portable hard drives or LTO tape if you are ambitious, and store this off-site. Whatever you are doing, starting out in Hyper V is going to make your backups truly portable.

To answer your comment below, I regard this as a matter of opportunity. If you are having an offsite server, then assuming you have the means to connect this to your main site via a VPN, then your best bet is going to be to run a spare DC in your offsite. This means that your DC will be replicated without the need for any software backup. If you add a DFSR role on the offsite server (free and out of the box with Windows) and run this in your primary location, then you can use this to automatically replicate your files to an offsite, assuming the DR role here to be about protection from physical disaster as opposed to data corruption (data corruption replicates across the wire as opposed to fire or floods, which don't). A good VPN connection will also allow you to do file level backups including whole hyper v VMs too, but you want something that will do this incrementally, otherwise your bandwidth will get used up. If you don't use a VPN, and don't have a connection between the sites, then you are going to be ferrying USB drives or tapes between sites, which a lot of people do, but the VPN route is easier to manage.

I would always have a physical DC on your primary site. Chris S is right, you can run all DCs as VMs, but to do this without experiencing time-creep you will need to hook up your VM to a physical time-server. To explain in more detail, a virtual DC will begin to guess the time because it is not linked to a physical clock, so your users will be logging in and suddenly the clocks on their computers will start to be 2 hours fast, or out of synch with each other, and this has implications for your backups as well. Also, getting the other settings right so that your virtual DC serves it's own physical host as it starts up is something that requires specific settings and I wouldn't recommend it for a first try.

Looking at SBS 2011, the recommended RAM for this is 10GB, so I wouldn't try to run it on a 2GB machine. I would keep your existing DC and buy a second box and run SBS on that. That way you can focus on transferring your exchange accounts seamlessly from one to the other without p*ssing off your users. It also means that you keep at least 2 DCs in your domain. Then for DR run a virtual DC on your offsite server, benefit from the automatic replication that this has, and also use offsite server as an incremental backup storage target. et Voila!

share|improve this answer
    
+1, Though I'd add that virtualizing all the DCs works fine, there's just caveats to be aware of, for simplicity I'd stick with the physical one in this situation though. –  Chris S Mar 6 '11 at 14:47
    
Thanks for the detailed response. My only concern is that my ultimate aim is to have a server offsite that can be easily rebuilt as our DC/Exchange server in the event of a disaster. Believe it or not our DC/Exchange box currently runs on only 2GB of RAM so I don't think we need particularly beefy hardware. If we purchase SBS 2011, could we stick with the one machine, back it up as an incremental VHD and then have something we can boot with on our backup box within a virtual environment? Or is this not recommended for a DC? –  user64300 Mar 6 '11 at 16:18
    
I've edited my answer to take account of your above question/comment –  Mark Lawrence Mar 6 '11 at 18:11

To answer your comment. If you are having an offsite server, then assuming you have the means to connect this to your main site via a VPN, then your best bet is going to be to run a spare DC in your offsite. This means that your DC will be replicated without the need for any software backup. If you add a DFSR role on the offsite server (free and out of the box with Windows) and run this in your primary location, then you can use this to automatically replicate your files to an offsite, assuming the DR role here to be about protection from physical disaster as opposed to data corruption (data corruption replicates across the wire as opposed to fire or floods, which don't). A good VPN connection will also allow you to do file level backups including whole hyper v VMs too, but you want something that will do this incrementally, otherwise your bandwidth will get used up. If you don't use a VPN, and don't have a connection between the sites, then you are going to be ferrying USB drives or tapes between sites, which a lot of people do, but the VPN route is easier to manage.

I would always have a physical DC on your primary site. Chris S is right, you can run all DCs as VMs, but to do this without experiencing time-creep you will need to hook up your VM to a physical time-server. To explain in more detail, a virtual DC will begin to guess the time because it is not linked to a physical clock, so your users will be logging in and suddenly the clocks on their computers will start to be 2 hours fast, or out of synch with each other, and this has implications for your backups as well. Also, getting the other settings right so that your virtual DC serves it's own physical host as it starts up is something that requires specific settings and I wouldn't recommend it for a first try.

Looking at SBS 2011, the recommended RAM for this is 10GB, so I wouldn't try to run it on a 2GB machine. I would keep your existing DC and buy a second box and run SBS on that. That way you can focus on transferring your exchange accounts seamlessly from one to the other without p*ssing off your users. It also means that you keep at least 2 DCs in your domain. Then for DR run a virtual DC on your offsite server, benefit from the automatic replication that this has, and also use offsite server as an incremental backup storage target. et Voila!

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.