What RPs are copied after a copy failure?

[pkelly_sts]

This question has been bugging me for a while but keep forgetting to ask it.

If you have an issue that causes a once daily backup copy job to fail for a number of days, then you resolve the issue & resume the copy job, what RPs then get copied?

Does it catch up with all lost/missed RPs or does it only copy the most recent RP?

Having asked the question I'm thinking it has to at least copy all the data otherwise the copy chain would be broken but does it then create one "super-RP" or just copy all of the missing RPs as-is?

Thanks!

[DGrinev]

Hi Paul,

It is important to understand that BCJ creates a separate backup chain, not just copies restore points.
So when you resume the copy job, it will create the restore point containing the most recent VMs state.


Thanks!

[pkelly_sts]

OK, that makes sense, but will it effectively be a combined version of the RPs that exist in the original job, but with a "state" of the most recent (original) RP?

In other words, if the job fails Mon-Fri but is fixed/resumed on the following Saturday, the number of RPs (at the copy end) would increase by just 1, and that would represent the most recent "version" of those VMs?

In this scenario I'm guessing if a user created a file on Tuesday, then deleted it on Wednesday, then I wouldn't expect this file to be available for restore from the backup copy on Saturday?

The more I think about it the more I feel that a copy job that does indeed effectively copy the RPs would actually be rather useful/desireable, even if it was an option rather than standard behaviour.

My reasoning is that we have a (hopefully!) very robust plan in place that means we have:

Local disk backups
Local tape backups with tapes staying in the 24-slot tape library

Off-site disk copies
Off-site tape copies of the disk copies

The idea is that we can save on the costs of getting & storing the tapes off-site with an outsource provider (in our case, Iron Mountain) but more importantly it means that we no longer rely on human intervention for tape swaps etc. which is the primary cause of (tape) backup failures in our environment.

In our current situation (a number of days of failures) that means that at least some of our data now actually only exists in backups on one site, so if we lose that site (fire/flood etc.) then we'll have a gap in off-site copies.

In this case the issue started on a Saturday so it was Monday before I realised the problem, by the time we log a case with support, they chew on it & then give some instructions for us to follow, that can also easily add another day (for a relatively easily resolvable issue) to the missing RPs, but possibly longer if it's a more complicated issue which I've had in the past...

[DGrinev]

In other words, if the job fails Mon-Fri but is fixed/resumed on the following Saturday, the number of RPs (at the copy end) would increase by just 1, and that would represent the most recent "version" of those VMs?

That's correct.

In this scenario I'm guessing if a user created a file on Tuesday, then deleted it on Wednesday, then I wouldn't expect this file to be available for restore from the backup copy on Saturday?

Right.

Described scenario make sense, we will keep it in mind.
Thank you!

[btmaus]

This raises a good point, as I have run into this scenario before when we needed a file restored but backup copy jobs had failed for a few days for one reason or another. Would be a good feature to be able to select copy those other previous restore points in the chain for copying again instead of just the latest restore point.

[foggy]

Thanks, Glenn. Your point is also clear, thanks for the feedback.