Backuping up a server

[rocknrollstar]

I am thinking about our backup situation at school. We have a Win2k server with XP Pro clients. Our data is backed up regularly, so I'm not worried about that.

 

My only concern is that if the server went down. How do I backup all the settings like GPO policies, AD, Domain controller settings & IP addresses etc? I guess there isn't a 'save your settings' button, but if I had to rebuild it, what's the best way to do this?

 

Thanks

[SYNACK]

If you are using the built in windows backup it is called 'System State' this backs up the registery, AD and a bunch of the system files. You can restore this by using the DC restore option when rebooting the server after you have reinstalled it if ends up needing to be restored.

[srochford]

Definitely use the system state backup to backup the DC settings (and everything else) but it can be hard work to restore that to different hardware - there are MS KB articles which take you through the process.

 

what you really, really want (!) is a second DC - that way, if one machine fails you do have a copy of the active directory data and you really, really (!!) don't want to lose that!!!!

[dhicks]

but if I had to rebuild it, what's the best way to do this?

 

We've had a couple of threads similar to this recently, so I might as well say the same thing as last time: virtualise your existing Windows 2000 server, so it runs as a virtual machine on top of . Then have that VM system replicate the virtual server in real-time to another machine, so if one goes down (or missing, or whatever) you have another one ready to instantly start up and take over.

 

For a VM system, I favour Xen running on top of CentOS and using DRBD to replicate between machines, although admittedly I haven't yet tried transferring an existing Windows machine to a Xen machine (I'm trying on Monday...). Might be easier to use VMWare as I know that has a utility and documentation for virtualising existing Windows machines.

 

--

David Hicks

[torledo]

I am thinking about our backup situation at school. We have a Win2k server with XP Pro clients. Our data is backed up regularly, so I'm not worried about that.

 

My only concern is that if the server went down. How do I backup all the settings like GPO policies, AD, Domain controller settings & IP addresses etc? I guess there isn't a 'save your settings' button, but if I had to rebuild it, what's the best way to do this?

 

Thanks

 

There's an option to backup all GPO settings within the GPMC. It's in a right-click menu option, google for the specifics. Individual server roles can also be backed up using various command line commands, DHCP backup is done using netsh commands from what i remember. AD-integrated DNS will be backed up along with AD in the system state.

 

Agree about replicas and VM mobility as suggested by steve and dave. But any form of clustering or replication won't do anything about configuration errors or change mgmt cockups. You still want the ability to go back to a previous, working, correctly configured version of a server role. For that i'd also second the option to create a recovery disk in windows backup....that's your baseline should you ever need to do a bare metal restore.

 

I personally don't think enough is written or documented about backup and recover of the core windows server and roles. I don't even think system state backup and recovery is that well understood. I also think a server OS volume is perfect for some sort of system snapshot option similar to windows system restore....if my servers were setup for Boot from SAN i'd defintely take advantage of the SAN arrays snapshotting feature to make scheduled PiT snapshots of the OS volumes. It'd just be so handy although i'd still take basline backups to removable media - there's never any substitute for a backup.

 

You could also take an image of your server using ghost or current flavour of the month wim/imagex. As it involves downtime that would probably also be a baseline image only occasionally updated to keep current. Infact maybe WIM's SIS technology would help with only adding the changes to a baseline image...worth looking into as an efficient way of imaging a server.

[DMcCoy]

We've had a couple of threads similar to this recently, so I might as well say the same thing as last time: virtualise your existing Windows 2000 server, so it runs as a virtual machine on top of . Then have that VM system replicate the virtual server in real-time to another machine, so if one goes down (or missing, or whatever) you have another one ready to instantly start up and take over.

 

For a VM system, I favour Xen running on top of CentOS and using DRBD to replicate between machines, although admittedly I haven't yet tried transferring an existing Windows machine to a Xen machine (I'm trying on Monday...). Might be easier to use VMWare as I know that has a utility and documentation for virtualising existing Windows machines.

 

--

David Hicks

 

This is not a backup though, it's redundancy.

 

Delete them all from one and they go from the other too.

[dhicks]

But any form of clustering or replication won't do anything about configuration errors or change mgmt cockups.

 

But that's half the reason for running your domain controller as a virtual machine - at any point you can simply take a copy of the entire machine's state (if you're using Linux LVM as the underlying block device for your DRBD replicated devices, for instance, you can do a snapshot to take a copy, so you don't even have to stop the VM to do it). This is why I find it a good idea, for servers with user files and such, to use two or three virtual disk images per virtual machine, that way you can have the OS on a small disk volume that it's easy to take a whole-disk copy of.

 

Actually, I bet it would be no real trouble to simply take a snapshot copy of your VM's OS disk every night, just appending the diffs to an incremental backup file, so you could go back to any version you liked in an instant.

 

That's a point - does anyone know how encryption would affect the above? If I have a virtual disk image that I encrypt with something like dm-crypt, would that encrypted disk volume be completely different every day (i.e. a diff algorithm wouldn't be able to spot just the bits of the disk that had changed, and would require you to store a copy of the whole volume again)? Or do whole-disk encryption systems encrypt sector by sector or something? They can't rewrite the whole drive every day, that would take too much time, wouldn't it?

 

--

David Hicks

[DMcCoy]

Minimal HDD size for 2003 server is around 8GB, 2008 20GB.

 

The system state when backed up is 600MB.

 

A local backup agent is still a good solution, VMs are not always the easiest way as you need lots of space for frequent disk images. I copy mine to a nas, occasionally but still use agents on the VMs for daily backup.

[dhicks]

Minimal HDD size for 2003 server is around 8GB, 2008 20GB.

 

Thanks, that's good to know - I have to set a couple up come Monday.

 

The system state when backed up is 600MB.

 

But, day-to-day, only small sections of that whole state change, surely? You can take a snapshot of the virtual disk image, then just write the differences to your backup file.

 

--

David Hicks

[DMcCoy]

Thanks, that's good to know - I have to set a couple up come Monday.

 

 

 

But, day-to-day, only small sections of that whole state change, surely? You can take a snapshot of the virtual disk image, then just write the differences to your backup file.

 

--

David Hicks

 

The problem with backing up at disk image level is it only works with that VM disk, the system state can be restored to anything (sometimes a little work required with drivers). It's going to be much easier to have many instances of system state backups than VM snapshots.

[dhicks]

The problem with backing up at disk image level is it only works with that VM disk, the system state can be restored to anything (sometimes a little work required with drivers).

 

True, although I figure the point of using a VM system on one server is that you can then run the same VM system on another server and run any VM images you like on that second server.

 

It's going to be much easier to have many instances of system state backups than VM snapshots.

 

From a storage size point of view, I don't think it will make any difference. From a portability point of view I think the two solutions are about the same, too - sure, mounting a VM disk volume and extracting data from it is a bit fiddly on Windows (although stunningly easy on Linux), but I figure you don't really need to as you can run your VM system on a different server anyway. From an automation point of view I'd prefer VM disk images - you can back up multiple machines in exactly the same way.

 

Hmm, I wonder if we're both simply looking at this from different terms of reference? I'm trying to keep my terms and such neutral, but of course when I think "virtual machine system" I'm thinking Xen on a Linux system. You're likely thinking of Windows-based servers of some kind. It seems natural to me to think of backing up data by storing diffs of VM disk images gathered by some cron job on a central server because that's the way you'd go about it on Linux. I guess Windows has a different way of looking at things.

 

--

David Hicks

[rocknrollstar]

Awesome, thanks for your help on this. A very useful discussion.

 

I'll do a NTBackup System State backup on Monday (to a file- I hate tapes!).

 

Great to have positive and helpful posters

[kmount]

It's all very well and good doing the back up to file, just make sure the file is backed up to tape as the hard disk may fail

[dhicks]

Awesome, thanks for your help on this. A very useful discussion.

 

You'd better just quickly check out the other thread about backing up a domain controller - seems there's whole whitepapers and such about how to do so in a VM environment when you have multiple DCs. Should still be pretty simple if you just have a small network with one DC, though.

 

I'll do a NTBackup System State backup on Monday (to a file- I hate tapes!)/QUOTE]

 

Copying the file to some sort of media that's removable off-site in case the place burns down, naturally.

 

--

David Hicks

[rocknrollstar]

Yep, I've got a few attached USB drives that I back up to...

 

David - I thought that if I did the system state backup, that was effectively backing up the domain controller? We only have 1 Win2k server on the network. I'm not really sure about VM stuff to be honest. BTW- I see you a lot on the TES ICT threads- very helpful! There are some real idiots on there, so nice to have some genuinely helpful people

[Midget]

i use a tape style backup regieme with HDDs and a hotswap eSATA caddy. hdds for mon-thur and 4 for fridays

[dhicks]

I thought that if I did the system state backup, that was effectively backing up the domain controller?

 

Yes, should be. I was just saying in that other thread that I'd find it easier to run the domain controller as a virtual machine and use the VM system's method of backing up, but it was pointed out that there's some potential pitfalls when running DCs as VMs, generally when you have multiple DCs around the place. You have one DC and no VM system, therefore a system state backup would seem to be just the ticket.

 

I see you a lot on the TES ICT threads- very helpful! There are some real idiots on there, so nice to have some genuinely helpful people

 

Well, it must be annoying for ICT teaching staff to be expected to be the ones with the technical knowledge to sort every other teacher's problem out. Most times I'm tempted to say "Ah, technical question - ask on EduGeek instead!"

 

--

David Hicks

[srochford]

It's all very well and good doing the back up to file, just make sure the file is backed up to tape as the hard disk may fail

 

and then copy the tape to something else because the tape might fail :-)

 

Toucing lots of wood, I've never been unable to restore from disc backups (always discs in "other" machines, of course,) but I've had lots of tape failures - I now won't use them because they are inconvenient, unreliable and expensive!)

[torledo]

and then copy the tape to something else because the tape might fail :-)

 

Toucing lots of wood, I've never been unable to restore from disc backups (always discs in "other" machines, of course,) but I've had lots of tape failures - I now won't use them because they are inconvenient, unreliable and expensive!)

 

I'd second that, and it goes back to what i was saying about a D2D solution for backup and restore reducing the reliance on tape as the first port of call for backup. In terms of offsite backup i think tape is still favoured but the eSATA caddies and usb hard disk methods as described by others seems a perfectly good way of eliminating tape from the offsite backup regimen.

 

But this trend of disk for taking offsite is definitely at the lower end for the moment...for middle and large IT depts manufacturers will still sell a lot of tape, and those that are looking at building some sort of disk based removable media backup devices to replace tape tend to try and mimic tape libraries with their products. So disk based libraries that look like and smell like tape except they don't use tapes. Go figure. It's a bit like the VTL trend, VTL's are based on the premise that orgs want to backup to tape but they want to use something that they're familiar with, so a VTL will emulate traditional tape operations. Again, it's a somewhat bizarre idea that uses modern disk based technology but looks back to traditional tape operations, all because it's what depts. are used to, even though most admins don't like traditional backup software and backup operatrions.

 

I just might get one of thoese eSATA caddies (preferably rack mount) and try using them instead of out tape autoloaders. I'm sure they'd work just as fine. Does anyone have any recommendations, preferably something that uses disks that can be read standalone via usb if required. Sorry not familar with what's available.

[SYNACK]

I just might get one of thoese eSATA caddies (preferably rack mount) and try using them instead of out tape autoloaders. I'm sure they'd work just as fine. Does anyone have any recommendations, preferably something that uses disks that can be read standalone via usb if required. Sorry not familar with what's available.

 

We just got a whole bunch of Digitus eSATA/USB enclosures and equiped them with 1TB drives, they are pretty quick when it comes to eSATA operation and alright at USB. eSATA cables are not the most secure things though as they don't lock into place on any of the hardware that I have used them on. The cables are also more suseptable to interfearence than USB is so you want to keep them well clear of power cords.

 

For something a bit more robust you are probably looking at something like this in a server drive bay:

DIGITUS: Accessories

[rocknrollstar]

Thanks for your help. I've now setup NTBackup to do a system state backup to the shared hard drives. Nice to know that it's safer than it was

 

Thanks.

[Joedetic]

@dhicks I never got round to playing with DRBD...I keep meaning to get a small test setup between two machines. It's just a case of getting round to it...maybe I'll get the time now it's summer hols (hah!)

 

I had a quick play with Linux-HA though. Simple Heartbeat setup with Apache. Apache ran on one IP with one machine as the master...that machine failed and the slave machine picked up using the IP the master was running on.

[ChrisP]

Mine is a little unconventional.. no raid for OS drive

 

bfs1=backup-fileserver1

bfs2=backup-fileserver2

bfs3=backup-fileserver3

 

LEVEL1

 

For ghost type recovery I try not to have the main OS on a raid array, just a simple sata will do.

every term I ghost all servers OS HDs

everynight I have every server automate a System state backup to bfs1

everynight most servers have a local dat72 that back up sys state and cherrypicked files

everynight fileservers etc. backup non OS HD's (raid array) to bfs1

all servers shadow copy set to twice a day.

 

LEVEL2

shadow copy on bfs1 set to everyday

so now bfs1 has a local copy of everythig. SYSstates, apps, profiles etc.

bfs1 has a 800gig LTO3 that backs up everything everynight. ( GF,F,S )

 

 

LEVEL3

bfs2 is old PC's with a few 500gig drives in it running basic raid 0 to give prenty of storage.

bfs2 backs up bfs1 everynight and shadowcopy is set to 2days

 

LEVEL4

bfs3 is old PC's with a few 500gig drives in it running basic raid 0 to give prenty of storage.

bfs3 backs up bfs2 everynight and shadowcopy is set to 1 week

 

 

LEVEL5

VMs and select files from bfs3 are backed up every term to a couple of external 500gig drives

Edited July 25, 2008 by ChrisP

[dhicks]

Mine is a little unconventional.. no raid for OS drive

 

We don't, either - we're aiming for a Google-style distributed computing platform on commodity hardware (which translates as "You didn't think the bursar would actually give you money for a real RAID card, did you?"). But that's the nice thing about running everything as virtual machines - all you have to have installed on each machine is your standard VM system, so if a boot drive does fail all I have to do is replace it and re-install our standard (documented, ish) CentOs setup.

 

--

David Hicks