Jobs failing - local disks in storage group

[MoopereM]

Hello All,

BE v15 with FP2 applied.

I've been struggling with this problem for a while and have reached the end of my ideas on what to try next.

I'm habitually finding an exchange GRT job failing which is being directed at a 2 disk Storage Group.  Whats happening is that the job chooses (at random?) one of the two disks in the storage group, starts the backup, finds that there isn't enough space left and then fails.  If you restart the job the next day it then chooses the other disk in the storage group and completes successfully.

Whats going on here?  Surely there must be a graceful way to handle storage media filling up?

[VJware]

Do ensure the option to "preallocate disk space incrementally..." isn't enabled in the Disk Storage properties.

Also, GRT enabled backups do not span across disk storages.

[MoopereM]

Thanks - appreciate your super quick response and ideas.

Preallocate isn't enabled.

Looks like the quick answer, well worth a try, is to stop directing this job to the disk storage Group but instead directly to a disk inside the storage pool thats 'most likely' to have enough space on any given day.

I assumed that BE would take a look at the destination disk and use some sort of algorithm to estimate if there was suitable space left.  

The problem I'm going to have I suspect is that I don't directly control the Storage Group members and who gets what job wise versus storage member disk wise, I was happy to leave that up to BE.  I have one small disk and one large disk included in the group.  The idea from my end was to just add disk as required to the group and let the available storage space for backups increase seamlessly.  

The smaller disk is constantly full, BE seems to preferrentially choose this disk first, fill it, then move its focus to the larger disk.  Not that this matters, even the big disk could fill up and I'll have the same issue.  Sounds like I need to create a completely seperate disk media storage specifically for this one GRT job and manage the retention settings so that this media never fills up.

[pkh]

By default, the first available disk storage in the device pool would be used.

You can change this behaviour by using the BEMCLI cmdlet, Set-BEStorageDevicePool with the SelectionMethod parameter.  You can choose LeastFreeSpaceFirst or MostFreeSpaceFirst,

[VJware]

With BE 2014 onwards when using a Disk Storage Pool, BE by default uses a round-robin fashion. That is, firsr job goes to first disk created, second job goes to second disk created and so on.

This default behavior can be changed and you can set BE to either choose Disk based on Most Free Space or Least Free Space.

The changes are done via BEMCLI and not the UI. Have a look @ the New-BEStorageDevicePool Cmdlet with the-SelectionMethod parameter.

[pkh · Accepted solution]

For existing device pools, the Set-BEStorageDevicePool can be used to set the selection method.

[Colin_Weaver]

As well as the setting the disk selection order that VJware and pkh have been discussing please be aware that GRT enabled backup sets cannot span from one disk storage device to another , as such if the first disk fills up then it cannot continue on the second disk

As such when a GRT jobs run they do have to start on a disk with enough space - which means using the Most Disk Space Free setting against a pool  is the best option but you still have to capacity plan (and review your backup set retention periods vs disk space) as on the odd occasion even the disk with most free space will not have enough for your GRT backup.

[MoopereM]

Thanks a lot for the replies.

Yes, this "Most Disk Space Free" might work. 

I've run the Set-BEStorageDevicePool command, no errors came up but I can't tell if the command has 'stuck'.  How can I get a reading of the pools current state?

[VJware]

You should be able to check via Get-BEStorageDevicePool Cmdlet .

[MoopereM]

No, its doesnt seem to.  Just gives me truncated data like this:

BEMCLI> get-bestoragedevicepool *

Name                Description         StorageType         MemberDevices
----                -----------         -----------         -------------
Any disk storage                        DiskStorageDevic... {Big Data, Small...
Any tape cartrid...                     TapeStorageDevic... {Tape drive 0001}
Fixed - Level 1     Critical Storage    DiskStorageDevic... {Big Data, Small...
Removable - Level 2 USB Drives          DiskStorageDevic... {}

BEMCLI>

[VJware]

Not front of a system, but see if adding Format-List * -Force helps or not.

[pkh]

Try

Get-BEStorageDevicePool | Select-Object Name, SelectionMethod

[MoopereM]

pkh - yes, thats it thanks. I ended up with a good output of all the storage pools by using: 

get-bestoragedevicepool | select-object *

Which gives a nice formatted output with descriptions for each variable shown.

Thanks a lot to all who assisted, I'm on the right track, I'm sure this will work.