Immediate copy job 'RPO' question

[ChrisGundry]

Hi

We liked the new immediate copy/mirroring option and also the new RPO option. However, we have an issue with it. All of the individual VM backups within the job copy within 3hrs, but the overall job takes 6 hours. To us that means that any VM in the job has been copied offsite within 4hrs, so our 4hr 'RPO' is met. The fact that the overall job took 6hrs is not important.

Unfortunately the RPO setting of the job doesn't care about how long it took for an individual VM backup to copy offsite, it only cares about the overall job. So in our case we can't use the RPO feature/warning because the overall job takes 6hrs.

Can you confirm that this logic is intended please and explain why it is so? I asked support and I just got "working as intended", which to us doesn't make any real sense given that the overall job length doesn't seem very important, vs the VMs actually being copied offsite in a timely manner, which does. If the RPO was set to 1hr and the overall job ran for a total or 5hrs, but every VM in the job was copied offsite within 1hr of the new restore point being available then the 'RPO' of 1hr is still met as far as the admin and business is concerned. The fact the overall job ran for 5hrs is not important.

Thanks

Chris

[Dima P.]

Hello ChrisGundry,

RPO monitor starts the count down as soon as the restore point is created at source and should not somehow be affected by entire source job state. Can you share your case ID please?

[ChrisGundry]

Well that would make more sense than what we were told on the case, but it doesn't seem to be that way in practice for us...

Case ID was 04375602.

Quote from the case/engineer was: "The warning about RPO comes from the fact that the whole job duration was 6h"

The source job starts at 2000 and finishes at 2245. There are 46 VMs in the job, so some finish very early and some finish towards the end.
There is one larger VM in the job which takes longer than most of the others and is the largest/longest in the source or copy job. Source started at 2019 finished at 2241. Copy started at 2242 finished at 0117, so about 2.5hrs, give or take to do the copy once it was there in the source repo. Well under the 4hr RPO we would like to have, but we actually have the RPO on the job set to 6hrs, and it still triggered, because the overall job is taking 6:26 and warning us "Offsite RPO violation: some backups were not copied within 6 hours". If we set the RPO to 7hrs the warning goes away. If the job takes less than 6hrs then the warning goes away. It is pretty clear to us that it is the overall job length that is being used for the warning, NOT the individual VM copy duration.

[Dima P.]

Thanks Chris! Checking your logs with RnD folks, stay tuned.

[Dima P.]

Chris,

Thanks for your post! We've found a bug: looks like the timestamp is incorrectly applied to the restore point (somehow it's still partially dependent from the job completion state). We plan to fix it in the upcoming update.

[ChrisGundry]

Thanks for confirming. Frustrating that this has taken so long to be confirmed though!

[ChrisGundry]

Is there any update on this issue? We are currently having to set our job RPO to 7hrs as the overall job takes 6hrs 30mins. Each individual backup point is actually copied in under 15 mins, except for one, which takes 1hr 50mins. So if we had the RPO set to 3hrs (our real RPO is 4hrs) we would actually be fine if not for this bug. Having to now have it set to 7hrs is a real pain because it means that by the time it alerts we have no time to resolve the problem because it is the end of the day already. Setting it to 3hrs when our real RPO is 4hrs means we have 1hr to fix things before we breach our RPO.

[Dima P.]

Hello Chris,

The fix is planned for the upcoming update. Unfortunately the only workaround for now is to keep the RPO time value increased.

[ChrisGundry]

As in update 11a?

[Dima P.]

Yes.

[ChrisGundry]

Thanks. Is there still no ETA for 11a? (That rhymes)

[Gostev]

Based on the current progress, it should be out next month.