However that article assumes that the manual copy would be finished between the two backup runs, or that the backup is paused.
The challenge that I have is that we use a forward incremental (always), and the copy of the largest (.vbk) in the repository takes over 24 hours to copy.
So the issue/scenario I run into is:
- Backup job starts
- Creates new .vib, injects oldest .vib into .vbk
- Start initial (robo)copy to new repository location (takes more than 24h)
- Copy not finished when new backup job run begins
- Creates new .vib, injects oldest .vib into .vbk which is now a different file so needs to be copied (again)
Initially using scale-out repositories (https://forums.veeam.com/vmware-vsphere ... 45399.html) seemed like an alternative, until I read the remark:
“keep in mind that backup jobs for chains that are currently located on the extent that is in maintenance mode (being evacuated) will fail (unless you temporarily disable the jobs)”
Now imagine you are a Veeam Cloud Connect provider and need to move the repository, are you going to tell your customer that they cannot backup (copy) for a day (or more) because you need to move the data?
What would be the procedure to move a ‘live’ repository from within Veeam without a long downtime?