Windows Server Backup Sucks
This article is referring specifically to Windows Server Backup 1.0 that comes with Windows Server 2008 R2.
I recently had the pleasure of another horrid Server 2008 product. This time around it’s the built in backup utility causing my head aches.
What’s the problem with it? It’s slow. I don’t mean takes a few extra hours slow… I mean it takes 18 hours slow.
First let me give a quick over view of the equipment being used… as this is definitely NOT a hardware issue. It’s a poorly-written half-assed software issue.
The server is 2U rackmount HP Proliant DL380, running 2 Intel Xeon E5540 CPU’s at 2.53Ghz. Each CPU has 4 cores with hyper-threading, giving it a total of 16 processing cores. It has 24gb of ram (6gb free when in production). For HD’s it is running 8 300GB 10,000 RPM SAS hot-swappable drives in a RAID 10 configuration. This server is no slouch. The server’s sole purpose is a Hyper-V server. It runs 4 virtual machines, all Server 2003 machines with 4 gb of ram each. In total, the virtual server has 746gb of data that needs backed up.
The server is connected via gigabit ethernet to a switch. The switch is connected via fiber to another switch, where lives our backup server that is also connected at gigabit and has 2tb of storage space for the server backup. Using straight file copying over network shares I have verified full gigabit transfer speeds.
It all sounds good right? Well, it actually all is pretty nice… until you throw Windows Server Backup in to the mix. What a piece of shit program this is. I’ll save you the hours of configuration it took to get it to play nice in setting the backup to go to the network share and to play nice with the Hyper-V virtual machines. Mind you this is a production server, so shutting down the 2003 servers for a couple hours isn’t an option. Luckily volume shadow copy services comes to the rescue here, but again, I’ll spare you the explanation on that as this isn’t the point.
The point is that 746gb of data transferred at gigabit speeds should take just under 2 hours according to my handy dandy file transfer time/speed calculator. The backup was scheduled for 9pm, so imagine my shock and horror when I came in and checked in on it at 8am the next day and see that the transfer was 70-something-% done. WHAT?! The backup did eventually complete around 3pm the next day. That is 18 hours. 18 HOURS. 18 Hours to transfer 746gb of data over a gigabit/fiber connection. This is just insane. How could Microsoft have let a product out the door with such a disgusting, fatal, problematic flaw?! And trust me, I – am – not – alone.
The problem it seems is due to the way it compresses the files in the backup. Apparently Microsoft has decided it is best that each file be compressed to it’s maximum amount. Nevermind the fact that some people might actually have storage space to store backups uncompressed… nevermind the fact that the NTFS file system has built in file compression that works quickly. It’s another one of those things that Microsoft let out the door and obviously never seriously tested, which being a corporate server product, you would THINK Microsoft would actually care about the code and programs going in to it. Apparently this is not the case. I’m about over Microsoft’s bullshit.
Ryan C
Microsoft backup has always been half assed. I was hoping for more. Here is the thing, the server has 8 cores of 45nm Intel fury and is under almost no load. None of the core maxes during the backup. So even though it compresses, it is not utilizing the hardware available. It is just shit, plain and simple.