I'm administering a single instance of Windows Server 2008 for a small business, which is backing up daily onto a large USB hard drive. For about the past year, this has worked very well, however the drive is finally starting to fill up.
The backup is configured to back up bare metal recovery, system state, and the system volume. There doesn't seem to be any way in the server backup GUI to clear up space, and wbadmin exposes only "wbadmin delete systemstatebackup" which is unable to help me since my backups include system volumes. I'd prefer to avoid fiddling around in the file system on the drive if I can help it, because I doubt that was the intent.
The obvious brute-force solution would seem to be to wipe the drive and reconfigure the backup again, but I'd prefer not to nuke my entire backup store if I don't have to (not to mention it's not terribly elegant).
Anyone familiar with a situation like this?
Get another external HDD? 2TB externals are under $150 USD.
The thing about Windows Server Backup is that it's designed, probably, to do just the bare minimum required to backup your servers. Microsoft has an offering in the form of DPM that allows for granular backup, recovery and management of the backup system. They understandably (understandably from their point of view) would want you to use this versus WSB.
That being said, in your tags you mention incremental, so I'm assuming that's the backup scheme your using. From Technet, we're told that even with the incremental backups, WSB will take a full backup every 14 days to reduce the risk of corruption to the chain. I've looked at all the cmdlets and wizard guides on Technet I could find, and not one mentions backup retention times, or cleanup of old backups. So it sounds like you're going to have to go in and delete the backups from the file system.
I don't have a set of WSB files that I can look at, so I can only hazard a guess as to how it looks on the file system. Either you can tell in the naming convention of the backups, or use the modified date and size to find where you're last full backup occurred. Everything before that is fair game.
If you're really worried about corrupting or losing your backups, backup your backups (wow, this gets redundant quickly), before trying your hand at modifying your primary data set. If you're any good at scripting you should be able to craft something that goes through your backup sets and deletes files older than a set date.
Well, I haven't gotten around to working with this yet, but System Center tells me that this problem has twice now resolved itself away from critical status, back to warning status, and gone back to warning again. It appears as if Backup Services is smart enough to delete old backups in order to make room for new backups when needed. Each time, the free space on the backup drive jumps by a gig or two, yet the backup log shows no failures; I guess this means it's getting the job done, however it's doing it.