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...
[New Sig: PLEASE get GFS tape support for incrementals!!!]