So you want to have 2 different retention times. Then it makes sense to use 2 different pools. This makes it also easier to identify the backups on the volumes. So I suggest you stay with 2 clone pools. You can even run two clone jobs on the same backup simultaneously. This would reduce the number of workflows. I cannot say why the default number of concurrent max sessions on a ddboost device has changed (with the programmer of the day?) but I just verified with NW 19.3 that you still can increase it to 120.
The reason to have two clone actions is that the backup data is kept for different purposes with different retention times. Normally the two clone actions have different schedules. But by chance on some specific dates, both clone actions should be run one after another. I tested such a workflow with one backup action followed by two clone actions. If the destination clone pool is the same, the second clone action keeps running forever and the workflow never finishes. If the two clone actions have different destination clone pools, it worked. Why? We try to use only one clone pool as it seems this is a best practice for Data Domain DDBoost device, as DD Boost support a large number of concurrent sessions. I don’t know whether using more clone pools has any impact on performance. BTW, according to Networker documentation, with an old version of Networker like 8.1, a DD Boost devices supported 60 concurrent sessions or save streams. With Networker 18.2, the concurrent session number is increased to 120. But with Network 19.2, the number becomes 60 again. Does somebody know why?
Is it possible to run two clone actions towards one clone pool in a workflow?