Showing results for 
Search instead for 
Did you mean: 

Backup Exec consuming disk space

Level 4


I have several servers that are running Backup Exec 15 but one has a peculiar problem. When the job queues because of a tape failure (or more likely when the tapes are not put in), the disk space on one drive is used up - around 150Gb. This of course causes the Hyper-V servers on that drive to go offline. As soon as I cancel the backup the space is released straight away.

Anybody any ideas on how to resolve this ? It sounds like a VSS issue but I can't see how to resolve it (VSS provider is set to Automatic in job settings). Backup server and all guest VMs have been rebooted.

Any clues gratefully received !




Employee Accredited Certified

This sounds like the way snapshots work in Hyper-V


Basically at the start of any backup job BE asks Hyper-V/VSS to create a snapshot of the VM, this snapshot will be initially empty but will slowly use more disk space as data changes inside the VMs during the backup.If the backup takes 2 hours to run then the space used will be proportional to 2 hours worth of changes within the VM at that time of day

Once the backup sucessfully completes the snapshot is removed and any space used recovered. (this is assuming you have not set the Faster Processing method for Hyper-V backups which handles the snapshot differently)


Now what happens if the jobs sits waiting for a tape is:

The snapshot is created at the start of the job, it slowly grows in size whilst the job writes to the initial tape (let's say 1.5 hours into the job as an example).

The job then asks for a tape and waits. The backup admin however only notices this 7 hours later (when he/she arrives at the office the next day). At this point in time instead of the snaphots having reached 2 hours of changes and then been removed, the snapshot has reached 8.5 hours of changes so is significantly larger and will be much larger again if this happens on a Friday night so another 48 hours is added to the mix for Monday morning.

When you cancel the job, the processes will request that snapshots are removed (as long as you don't kill any Backup Exec services when trying to cancel) , which then reclaims the space. Alternatively instead of cancelling the job, inserting another tape and acknowledging the media alert would also reclaim the space but 30mins later (for this example) after the backup finishes on the second tape.

So your options are:

1) Make sure you have enough tape space for your backups to complete. Definitely use a library but also think about starting jobs as overwrites instead of appends (because appends are more likely to need a second tape)

2) Increase the size of the volume Hyper-V is creating the snaphots on for the VMs so that it does not cause issues

3) Backup to disk (or deduplication) instead of tape and then duplicate to tape later - this is actually the best/recommended practice because GRT restores from inside virtual machine backup sets have to be staged back from tape to disk anyway, and if you write to disk in the first place staging is not needed. Basically you need more disk space for the complete GRT backup and restore process whichever device type you write the backups to, but specifically for the GRT restore process a lot of time is saved if you need to get individual files back if the backups remain on disk (or deduplication)