So, copy mode is set and extent is not in sealed mode and still veeam does not copy my data to S3... I've also tried to force offload manually, no result. Just now, under history -> storage mangement, I see the following:
What could be wrong / where can I see some hints?
BTW: When using the new "immediate copy" mode of a BCJ, why can't I add vm's per tag? I always used tags to select my vm's which should be copied and now I have to again pick jobs - that's not that convenient anymore if you're vm's are spread across multiple jobs...
Oh, interesting. I think I've found the answer by looking at the screenshot: There it says "incomplete" at the FULL. Why did this happen and how can I fix it? It does not really make sense to me: If the full is incomplete, why would it copy the increments after that incomplete full?? I've checked the vbk on the source and to me it looks ok - SureBackup jobs run fine as well... I'm sure there's a reason for that...
It means that backup copy job was not able to sync data for all source VMs, but it managed to catch up during next runs. The chain is not corrupted and completely restorable.
This "incomplete" factor should not affect copy mode, though. So, do you mind opening a support ticket and sharing its number here? In the meantime I will double check few things internally.
Confirmed as a bug, will be fixed in one of the next product updates. To make copy mode work initate new full backup. Once it's created successfully created, offload process will start working as expected. Thanks!
Hi Vladimir, what a great support - thanks very much!!! Just to not get you wrong: If you say I should create a full backup, you're talking about copy job and not about the (source) backup job?
I can confirm that triggering a full has resolved the issue on my side, thanks again!
One final request: Could you please answer my second question:
BTW: When using the new "immediate copy" mode of a BCJ, why can't I add vm's per tag? I always used tags to select my vm's which should be copied and now I have to again pick jobs - that's not that convenient anymore if you're vm's are spread across multiple jobs...
It's not a very typical scenario to copy only some VMs from the single job, but it significantly complicates the logic and the user interface. So, we decided not to implement this functionality. Typically, our customers use jobs to group VMs with similar protection needs together.
Having said that, the required granularity can be easily achieved by creating the dedicated SOBR without a Capacity Tier, and use that SOBR as a target for jobs containing those "less important" VMs which don't need a second copy in S3. Think of the Job + SOBR combination as a backup policy.
Needless to say, this dedicated SOBR can still use the same physical storage as the "main" SOBR.
