number of copy jobs compared to backup jobs

[bjdboyer]

Have a new customer with about 60 VM's with backup jobs spread over several hours during the night. Not just 1 or 2 backup jobs but possibly 6 or more spread over different schedule start times. Would it be better/recommended to have 1 copy job for each or just 1 copy job for the customer? All backups have the same retention settings. And they want GFS processing for the copy jobs. Just monthly. Wiht the GFS would it be better to have several copy jobs? I'm going through the best practices guide but haven't really found anything to answer this.

TIA,
Bill

[foggy]

It's all up to the customer's needs/convenience. If they all come from/go to the same repositories I'd probably go with just a single job. Full backup size can also be a decision maker here (if target repository uses Windows dedupe, for example), but per-VM backup chains can be used to address this.

I'd even switch to a single job approach for the original backup jobs and use proxy/repository max concurrent tasks limits to control the load (if that is the reason for spreading several jobs in time).

[bjdboyer]

Some systems have a requirement to be backed up after a specific time in the evening. Most don't care when, just spread over the window.

For the one or multiple copy jobs I was thinking the procesisng time of the GFS if ti was all 1 big big job. The data could be multiple TB of protected storage. and having to do all of them in a single copy job the 1st of the month might be too much??

[foggy]

Depends on the storage capabilities. Anyway, you test.