Retry fails when using Immediate Copy

[dbr]

Hi guys,

We're running VBR v11 P20210525, we want to redesign our environment and, on that occasion, switch to immediate copy for some or all our copy jobs. In some tests we noticed that an immediate copy job locks the primary backup chain, so a retry of the primary backup fails. I can't believe that isn't fixed in v11. I have to admit, that I noticed it actually with v11 first, but as immediate copy is a v10 feature I would have expected that somebody noticed it earlier. However, support told me (case# 02357944), that will be fixed in the next major release (v12), which I assume to be only released next year. As you cannot switch between periodic and immediate mode dynamically, we cannot start redesigning our environment or have to re-create all our copy jobs after fixing this. Is there really no workaround or hotfix I missed?

And another question regarding immediate copy: If the immediate copy job locks the backup chain, then a quick backup cannot be created as long as the copy job is running, right? Or does the immediate copy job locks the chain on a per-vm basis only? If first, this has to be considered in case you have long running copy jobs.

Daniel

[HannesK]

Hello,
hmm, with that support case number I cannot find anything useful. Can you please check it?

Thanks,
Hannes

[foggy]

Hi Daniel, you're not using per-VM backup chains on the source, right? This issue is more likely to occur on not per-VM chains. Anyway, the situation should occur only in case there's some failure during the source backup job run and retry is triggered, which shouldn't be frequent. I can confirm this is currently planned to be addressed in v12.

This shouldn't affect Quick Backup as it doesn't have retries (manual operation). The backup copy job locks files on a per-VM basis, right.

[foggy]

hmm, with that support case number I cannot find anything useful. Can you please check it?

The case number is #04784287 (and it is in German, so unlike me, you will be able to make sense out of it ).

[dbr]

Hey foggy,

I'm always amazed about your and your colleagues' response time. You're right, that wasn't the case number, my bad. I was in the wrong line... and most parts of the case are in English. Only initial post and description are in German .

Yes, on primary backup jobs we don't use per-VM backup files (in favour of a better overview on repository and to leverage deduplication). You mean, that wouldn't be a problem if we switch to per-VM files?

Maybe a bit off topic, but are there possibly even benefits e.g. performance when switching to per-VM backup files on a ReFS volume? We already use ReFS with fast clone. If there are benefits and no issues regarding immediate copy locks, we will consider using per-VM files and wouldn't have to wait for addressing the problem in v12. By the way, is it possible to switch between per-VM and normal processing without recreating jobs or anything else?

[Mildur]

Switching to per-vm files needs an active Full Backup of each Job.
Therefore, you will not be able to use the old backup blocks for fast cloning.
New blocks will be generated and used for fastclone

The best benefits for me to use per-VM Chain is, that if I have a problem with one chain, I don‘t loose all of them. Second, if I need to remove all Backups from a single vm, I can simply remove the chain for this vm. This will not work with per job chain.

[dbr]

Hi Fabian,

not loosing the whole chain seems a good point. Loosing the benefits of block cloning due to a need of an active full shouldn't be a big problem. There's enough space for a second full and the chain will be removed after 30 restore points (retention). I will consider it. Thanks for your input.

[dbr]

Regarding QuickBackup I mean, QuickBackup will fail if immediate copy is already running (not using per-VM), right? Should be the same situation as a primary backup retry as the whole chain is locked through immediate copy, isn't it?

[foggy]

Yes, on primary backup jobs we don't use per-VM backup files (in favour of a better overview on repository and to leverage deduplication). You mean, that wouldn't be a problem if we switch to per-VM files?

You would be much less likely to encounter this issue with per-VM chains.

Regarding QuickBackup I mean, QuickBackup will fail if immediate copy is already running (not using per-VM), right? Should be the same situation as a primary backup retry as the whole chain is locked through immediate copy, isn't it?

No, this issue is specific to a retry event.