Left to themselves, things tend to go from bad to worse
I was looking for a backup solution for a new computer with Windows 2008 Server. Naturally, first I turned to the built-in Windows Server Backup software. I did not expect wonders, but what I found was way beyond the limits of sanity. Disclaimer: I am not a system administrator, and maybe this article states the obvious. Yet, I feel I must record my experience, so if someone asks me “what’s wrong with Windows Server Backup”, I can quickly point him here.
If you would like to hear the whole story, read on. If you’d rather cut to the chase, go to the “summary” section below.
It started to sound absurd from the very beginning. The options for one-time backup are completely different from scheduled backup. One-time backup allows you to backup to a network share, to a disk drive, or to a DVD writer (which I don’t have on that particular server). Scheduled backup, however, can only backup to a disk drive, and it wants to reformat the whole drive for its own use.
Well, this is annoying, I thought, but I still can schedule multiple one-time backups via the task scheduler and the command line tool wbadmin.exe. So, I proceeded with the one-time manual backup, using my 1TB external hard drive as a destination.
The backup went smoothly and very quickly. They never asked me for the backup location and just put the files in
WindowsImageBackup folder in the root, but hey, this is Microsoft, what did you expect – a config file? 🙂 That was no big deal for me – I could easily let them place the backups wherever they want.
Unfortunately, in Windows Server 2008 Microsoft dropped the support for backing up individual files and folders. You can back up only whole disks. This is bad, but not the end of the world. In line with the tradition, the older version of the backup that supported individual folders cannot be used on Windows Server 2008.
A bigger blow was that the backup file is not compressed. So, if you have 8GBytes of data on your drive, you get a 8GBytes backup file. At this point I had a brilliant idea: why don’t I just mark the
WindowsImageBackup folder as compressed? To my amazement it worked. I could even restore some files from the compressed backup.
But then I made a big mistake – I took another backup! It went all downhill from here.
First, this new backup was put into the compressed
WindowsImageBackup folder, but the backup file was not compressed. A couple of auxilliary 64K files around it were compressed, but the big 8GByte backup file stood proudly in its completely uncompressed glory.
Second, the previous backup disappeared from the face of the Earth, although it was still visible in the backup history, and still accessible for recovery. I also could see it taking up the disk space.
Well, I said, let me just delete this first backup, so it does not take up space. And then I was hit with the biggest absurdity of them all: YOU CANNOT, I repeat, CANNOT DELETE THE OLD BACKUPS!
Apparently, Microsoft thinks that when people run out of disk space, they just buy bigger hard drives.
There is an option in
wbadmin.exe to delete “system state backups”, but it does not apply to full volume backups. There is another, half-documented option to delete the “catalog”, or backup history. This will make all the backups you made, old and new, inaccessible on your computer.
However, even if you do delete the catalog, the backup files don’t go anywhere. So, I went ahead and deleted the
WindowsImageBackup folder manually. The free space on my drive increased by the size of the second backup, but I still had 8GBytes missing!
I ran chkdsk and it showed no problems on the drive.
After scratching my head for a couple of minutes, I started to examine all the folders on the drive one by one, and the hidden
System Volume Information folder caught my attention. The folder was not accessible and I could not calculate its size. Tried to go there – access denied. I updated the permissions and bingo! Two huge files with cryptic GUID-like names: one a few kilobytes shy of 2^32 bytes (4GB), and the other slightly less than that. This is what was eating the disk space, and this is probably where the first backup found its resting place.
Unfortunately, I could not delete these files, nor I could take ownership or adjust permissions, even being an admin on the machine. Access denied all over. These files are fenced really well. In any case, even if I could remove them, I would probably risk the integrity of the disk volume. It’s a good thing I just started playing with the server, so I had almost nothing on that external hard drive, and I could just reformat it. So, here goes the
- You can backup only full disks
- Scheduled backup wants to reformat the destination drive, but manual backup does not
- You cannot compress the backups
- You cannot delete old backups
- Old backups may go into hidden system files that cannot be removed, even by the administrator
The bottom line: Windows Server Backup is not just unusable, it is ridiculously unusable. Either people who created it did not know what they are doing, or this is an intentional diversion.
I’ve just been testing Windows Server 2008 as we may have to start using it soon (due to a software supplier saying they’ll only provide support if we do). I thought I was going mad when I couldn’t select a network shared folder to backup to. I’ve always insisted having off site backup and a physically attached disk just isn’t going to give us that. Maybe it’ll work with an iScsi drive… ho hum, more things to find out.
I could never understand why the biggest software company in the world always skimps on the tools that are included with Windows. Examples include Backup, Notepad, Calculator, Antivirus, etc. Why can’t they build best-in-their-class tools?
Anyway… I’ve found a little more flexibility using network shares on the same server that I’m backing up. For example, back up SERVER1 to \SERVER1Backup2008-08-21, \SERVER1Backup2008-08-22, etc. This also gets around the problem of the WindowsImageBackup at the root of the drive and the hidden Shadow Copy files. I have not tested this with compression. If you need to perform a complete image restore (booting from CD), you’ll have to move the the desired WindowsImageBackup folder to the root of the locally attached drive before Windows Backup will find it. For example,
X:WindowsSystem32> MOVE G:Backup2008-08-21WindowsImageBackup G:
Thanks for the informative writeup!
Actually you CAN schedule backups withour formating the drive.
Just use the Task Scheduler and schedule something like: wbadmin start backup -backupTarget:D: -allcritical -quiet