ekisner wrote:Well, we don't move our backups often - in this case, I moved the backup to faster storage after adding additional disks to the faster array. Now that it's there, I don't anticipate any further moves. The complexity isn't so much an issue, it does sound fairly straightforward. If I do need to move things again, I will certainly give that one a try.
With regard to the IO load, we throttle our backups already so the production storage does not get hit too hard; the DR storage rarely reaches saturation.
I have an automated script which mounts a restore point (the least recently checked), and launches an AV scan on the FLR volume, then cleans up. Gives me an offline scan that I know can prevent any form of active AV countermeasures<...>
With regard to the IO load, we throttle our backups already so the production storage does not get hit too hard; the DR storage rarely reaches saturation
The rest were already there, the purpose of the move was to put it on faster storage having added more disks to that array.
I'm not 100% sure how it works on the backend with forwards, whether or not it needs to generate a synthetic full point for the restore or whether it just "handles it" or not.
I am currently of the understanding that restore-related tasks start faster with a reverse incremental job.
Would you provide some numbers on how fast does the scan happen minutes/GB/amount of files on average?
I thought that you're not satisfied with the backup job performance
Users browsing this forum: Google Feedfetcher and 1 guest