BE 2012 and diskpools

[Flyfish]

Hi

I've to say that I am new to BE 2012, but I have a lot of experience from other backup products. I've been working on this issue for a client for a while.

Issue is:

A backup job (lets call it job1) is set to use a storage diskpool for backup. This diskpool contains 4 disks in total (lets call them disk1-4). The backup job1 will only use disk1 and disk2, even though these disks are full and of course the job is failing with insuffient disk space! Disk3 and 4 are online and present but BE does not use them for job1. Disk3 and 4 are added to the pool recently. I can easily create another new job and then BE will use all the disks where diskspace are available.
But for this specific job1 (which is created before adding disk3 and disk4) BE will only use disk1 and 2. Why does this job1 just not use a disk in the diskpool with enough diskspace?

I have opened a support case at Symantec and here are their suggestions so far:
1. Create a new job and set it to use the diskpool - Success
2. Recreate the problematic job1 with a new jobname, use exact same selections, options, etc - Fail, not enough diskspace
3. Disable GRT options in job1 - Fail, not enough diskspace (why does Sym support suggest this? GRT have nothing to with diskpools!)

Anyone seen this issue before?  IS it something in the SQL db that links this job1 or objects in job1 to use disk1 and 2 only?

 I am stuck here :(

Cheers

[pkh]

When you use a storage pool, BE will use the first AVAILABLE device in the pool regardless of how much space there is on the disk.  BE cannot predict the size of the backup, so it does not check for space.

When you use GRT, BE will allocate enough storage to contain an image of the resource.  For example, if you are backing up a 200GB VM with GRT, then BE will allocate 200GB of space to contain an image of this  VM.  If there is insufficient space on the disk, the job will fail.

[Colin_Weaver]

Whilst your experience of adding devices into a pool that already exists and already has jobs assigned may need further investigation, please be aware that we are already awrae that load balancing with a device pool in BE 2012 needs some enhancements and these are being looked at for next complete release of Backup Exec. Whilst I cannot confirm exactly what might make the final release, we are looking both the way load balancing in a pool worked in BE 2010, and also looking at the possibility to choose which device to use based on available disk space at the time.

[Flyfish]

Hi and thanks for the answers.

What I dont understand is.....

Why does BE not continue on next available disk in pool when first disk is full?
What is the point to have disks in a pool then?

Cheers

[Colin_Weaver]

That is one of the things being looked at - although please note this can only be looked at for non-GRT enabled backups that only create bkf files. GRT enabled backups that create IMG folders can never span as we have to be able to directly  mount the data from one source location  in order to affect a restore of an individual item. (i.e. an e-mail from within an EDB).  As such IMG data not spanning is not a 2012 limitation it is an "all BE versions that support GRT" limitation.

[Flyfish]

That is strange because if I do the same job to tapepool instead of diskpool it completes succesfully...spanning over several tapes ! Does BE2012 treat tapepools and diskpools differently in this matter?
If I do a backup to tape with following duplicate to disk, the backup to tape completes succesfully and the duplicate to disk fails.
 

[pkh]

When you backup to tape, the format is different.  When you restore a GRT backup from tape, it is first staged to disk to get the image so that the individual items can be retrieved.  It is not a straight restoration to the final destination.

[Flyfish]

So there is no solution to this issue at the moment, other than wait for Symantec to release a new version?

[pkh]

As Colin Weaver has pointed out, even if there is a new release, it would not have disk spanning when you are doing GRT backups.

If you want, you can offline the disks in a sequence.  This will ensure that the "correct" disk is used.

[Flyfish]

Ok, I will try to take offline the full disks in pool - we'll see what happens with the full backup this weekend. 

[Flyfish]

I kinda solved this myself. I deleted all diskpools and then configured backup jobs to use "any disk storage" Now BE doesnt try to use a full disk, but use the next disk with available space.
So far, I havn't seen any jobs failing during a backup job because of a disk is running full - over a period of two weeks.
We have 5 storage disks in total, 2 TB each. Disk1 and disk2 are full and BE now started to use disk3 - it even seems like BE don't try start a 100 GB job to a disk which only have 2 GB of available space (which was my initial issue when having a diskpool) ...nice!
BE must somehow do a little "disk-tasting" to determine if there are proper diskspace before starting to write data....yes?
Btw, I don't have pre-allocation enabled and most backups are GRT enabled up against vCenter.

Cheers

 

[Flyfish]

Not a solution !
BE always tries to use the most full disk....why? Even if it have 1 mb free space left, the job start and then hangs when running out of space......allthoug there are a lot of space on the other backup disks...It's so silly! Why are BE starting a job to a disk that is way below all low disk space warnings ??
There are even no options to set...something like "Dont use this disk if it's below warning threshold"

It's actually a shame because my backups are running fast and smooth....when backing up to a disk with proper diskspace.
I've been working with other backup apps over the years and I have never seen an issue like this.

Symantec....please fix this ASAP.