Solved

HPE StoreOnce backup copy jobs fails with file session error


Userlevel 1

Hi,

 

We have a lot of backup copy jobs (but far from all) that fails with the error “Failed to dispatch repository file session resource requst. Requested amount of file session (193) is greater than the maximum amount available (192).

According to HPE Veeam should know that this StoreOnce has a internal limit of 192 datastreams and should not try to open number 193. 

 

Anyone with a idea of how to fix this?

icon

Best answer by regnor 28 October 2021, 11:21

View original

10 comments

Userlevel 7
Badge +20

I have not seen anything so far when searching.  Maybe suggest opening a ticket with Support as there could be a registry key that they can give you to help with this that is not public. :smiley:

Userlevel 1

I had already opened a ticket with the very slow Veeam support.

They finaly answered, and the solution was to run a active full backup copy, because the active backup chain on the Storefront consisted of more than 192 restore points. 

 

Userlevel 7
Badge +13

Thanks for getting back with the answer to your problem. I didn’t have that in mind, but there are limitations regarding the length of the backup chain; so you should regularly do active or synthentic fulls (active prefered): https://helpcenter.veeam.com/docs/backup/vsphere/deduplicating_appliance_storeonce.html?ver=110#limitations-for-hpe-storeonce

Userlevel 7
Badge +13

In an enterprise environment, are these limits easy to reach or are they extreme cases?

Userlevel 7
Badge +17

I think a backup chain with 192 restore points and more is rather extreme….

The backup chain is reset with every active or synthetic full.

Userlevel 7
Badge +13

I think a backup chain with 192 restore points and more is rather extreme….

The backup chain is reset with every active or synthetic full.

Thanks @JMeixner , I was hoping for a similar response.

Userlevel 7
Badge +20

I had already opened a ticket with the very slow Veeam support.

They finaly answered, and the solution was to run a active full backup copy, because the active backup chain on the Storefront consisted of more than 192 restore points. 

 

Glad to hear you got a resolution never thought about the chain length.

Userlevel 7
Badge +13

I think a backup chain with 192 restore points and more is rather extreme….

The backup chain is reset with every active or synthetic full.

Thanks @JMeixner , I was hoping for a similar response.

In addition to @JMeixner ‘s answer, you should always configure a full backup when using a StoreOnce as a backup target; endless incremental won't work.

@kitt Which model do you have in place?

Userlevel 1

We have a StoreOnce 3640.

 

All our jobs is configured as forever incremental  with syntethetic full backups every week.

This have been working a long time, but something must have happened since this error came on a lot of backup copy jobs now. 

 

If the chain is increaased by one for every incremental backup we should have 42 after a week, or 192 after about 4,5 weeks. I havent had time to investigate this, but I can not belive the fulls have not ran for over a month. 

 

 

 

 

Userlevel 7
Badge +20

We have a StoreOnce 3640.

 

All our jobs is configured as forever incremental  with syntethetic full backups every week.

This have been working a long time, but something must have happened since this error came on a lot of backup copy jobs now. 

 

If the chain is increaased by one for every incremental backup we should have 42 after a week, or 192 after about 4,5 weeks. I havent had time to investigate this, but I can not belive the fulls have not ran for over a month. 

 

 

 

 

Maybe an Active Full once a month will help too and ensure it won’t happen again.

Comment