Selection criteria: it will check storage node affinity and from there any device owned by SU which fits device configuration at that moment is eligible to get data.  That would be backup.  For restore, it is simpler as client just checks against SU where data is and requests it back.  Of course, if that is not possible, it fails back to traditional way over storage node.

I do not think DDBoost will check least busy device as these are just files in SU and from what I know it makes no difference if there is 1 stream of 20 in terms of overload to device (single FS).

Hi Hrvoje,

Thanks for your input. So if I understand you correctly, what you're saying is that aside from pool selection and storage node affinity it is a rather random process which DDBoost device gets picked to backup the data to - as long as the device is not fully loaded with the max sessions (currenltly 60 for DDBoost devices).

Is this documented anywhere as far as you can tell or is this knowledgde from field experience?

Well, it is not just max targets, but also target sessions that will affect how sessions will be distributed (and in 8.1 they may be distributed among different storage nodes if you choose so).