Primary veeam server that backs up an exchange server installation of 18 servers.
It runs 5 days a week, has 20 restore points so this server hold 1 month of backups. The full backup is about 2.5TB.
We run a Backup copy job that goes to secondary server for archive, so that runs once a week and has 26 restore points, so that we can store 6 months of weekends on a different server(repository)
When we hit the 26 (6 month) retention, on that day it has to transform, it has to read all 26 vib files that are roughly 400-600GB into the full backup (vbk).
We have yet to hit the 26, but I worry when we do then the transform will never work. It would have to be on an 20TB SSD array to achieve the kind of IO requirements that are needed to process this job.
We are having simular problems already with standard jobs that are smaller with less restore points than these exchange vibs. ( case 00533881 ) - Our offsite/archive repository 12 x 4TB RAID6 with Server 2012 Dedupe doesnt have the IO's and we are getting delayed write failures. The trouble is we can't schedule copy job transforms, they only happen when the retention policy is exceeded, and because all our copy jobs have the same amount of restore points, they are all tranforming at the same time and there's no enough hours in the day limit the jobs so that only 1 transforms at the same time.
Server 2012 dedupe was working great, until we hit those retention limits and it had to transform, so it adds even more IO due to the hydration of the old vibs.
I feel the copy job implimentation is flawed - we were better of with complicated robocopy scripts
