Thanks and continue to share Rasmus. 

Can’t wait for the rest of this series.

Thanks Rasmus.

Awesome, Keep the good work !

Keep going, awesome 

I spent some time over the weekend catching up on these and this is the only one that bugged me.  If the window is shortened why would you choose increasing the repository resources over more bandwidth?  Because 40Gbps is more than adequate?  If the bandwidth were significantly lower would you opt for more bandwidth over repo-power at that point?

Thank you for these!

Thank you so much for taking the time to ask the question @StephenM. The question has two challenges to solve:

1. Complete backups in two hours less
2. Add one extra year of retention

To produce backups in less time, we will need to increase the number of tasks on the backup proxies, which in turn means we need more CPU and memory = option 4.

However, those additional proxy tasks need tasks on the repository to send data to, so we also need additional tasks on the repositories which, like on the proxies, mean we need additional CPU and memory on the repositories = option 1

To solve the second challenge of additional retention, more data to be stored = more storage capacity needed = option 2.

I didn’t pick option 3 because we are not using a repository type that requires a gateway server.

To finally come back to what you actually asked me, why didn’t I select option 5 “Increase bandwidth between sites”, well because keeping backups for a longer time doesn’t mean I need more bandwidth to move them. The volume of data being produced per day is the same so I don’t suddenly need more bandwidth to complete the task at hand.

Do let me know if anything is unclear.

Now there is a great explanation.

The problem was my thinking!  I was thinking backup plus copy to offsite time and not just “backup” time. 

Thank you for the explanation.

If you could design some sort of Veeam obstacle course involving a squirrel and incorparate that into the videos we could get those YouTube views up highter. (-: