V8 - Mapping Back Copy error

[mcwill]

"Unable to map backup: Backup Copy supports forward incremental backup chains only."

I'm not sure if the above is a fault or behaving as intended so would welcome some advice, I've set up a new V8 server, pointed it to the existing backup repositories and rescanned these to import the existing chains.

I have successfully mapped new backup jobs onto the backup chains, but when attempting to so the same to the "Backup Copy" chains we get the above error. Searching the forums or KB only appears to pick up backup copy seeding articles.

Should we be able to map existing "Backup Copy" chains onto the new copy jobs?

Thanks,
Iain

[veremin]

Are you trying to backup copy job to a chain created by a reversed incremental backup job, by any chance? Thanks.

[mcwill]

Yes, under V7 we used Reversed Incremental for all our backups.

[veremin]

Then, the described behavior is expected. You can map backup copy job to forward incremental backup chains only. Thanks.

[foggy]

You can map to existing backups created by your previous backup copy jobs though (if you have those).

[mcwill]

Maybe I was unclear or didn't understand the question.

The chain I am attempting to map onto the "Backup Copy" job is an existing Forward Incremental "Backup Copy" chain. The Copy chain was produced on V7 as a copy job against a Reverse Incremental Backup job.

[foggy]

Do you have GFS retention enabled on this job?

[mcwill]

Yes, the repository scan has successfully identified W,M,Q,Y against a number of the restore points if I look at the Disk (Imported) properties.

[mcwill]

Support case: 00674524

I've raised the above case as from fogy's response I should be able to map existing Backup Copy chains to a new Backup Copy job.

[foggy]

We've just checked this internally and GFS seems to be the issue here. It somehow affects the regular chain, making mapping impossible. It will be addressed in one of the future updates. Thanks for letting us know!

For now there's a kind of workaround to create a separate backup copy job with existing backup copy chain as a source to get a brand new full backup from it. This full then can be used to map your normal backup copy job to it (you would need to control old backups retention manually though).

[mcwill]

Creating a new Backup Copy chain isn't a problem, our Backup Chains have mapped successfully so we can start the Backup Copy chains anew. The problem is disk space on the Backup Copy repository, we can't afford the luxury of keeping the old Copy chains in full for the next 12 months as the new chains grow. So we will need to prune the old chains on a regular basis to manage the space occupied.

Is there an easier process to do this than deleting the old chain from the Veeam server, working out which backups are excess to the GFS scheme and deleting them before rescanning the repository?

Thanks,
Iain

[foggy]

I cannot think of any other way except scripting the entire process.

[mcwill]

I'll wait for support to advise me, as scripting a GFS retention script which compares 2 copy chains is beyond my meagre talents.

[mcwill]

I'm surprised this isn't available already, we can migrate both Backup and Replication jobs to a new Veeam server but cannot do this for Backup Copy jobs when long term storage (GFS) has been configured.

At the moment, it appears that all you can do is import the old restore points into you new Veeam server to be available as static restore points. Note however that...

• Your GFS expiration rules will no longer be applied.
• You can not manually expire individual Restore Points via Veeam, instead you will need to delete the backup file but Veeam will still show the backup as available.
• If you choose not to manually micromanage the GFS retention of imported archive chains then you will need to double the amount of storage allocated to archive in order to hold both the old static and new backup copy chains.

The automated GFS rotation was a welcome addition to the Veeam feature set, but please don't hobble it by locking us to one Veeam server for life.

Thanks,
Iain

[foggy]

Thanks, Iain. As I've already mentioned earlier, this is already on our radar.

[AlainRussell]

Hi Foggy - we've just hit this rebuilding our Veeam server - do you know if there is a fix coming?

[foggy]

Definitely, but I have no ETA for it currently. Is the workaround mentioned earlier in this thread applicable in your case?

[VladV]

We've hit this issue also with one of our backup copy jobs that had GFS restore points. Do you know if the fix will be included in the next patch (that should be arriving in the near future) or in a later patch?

[veremin]

We've been unable to make it into first patch. It will be available in one of the next patches, though. Thanks.

[migeauxy]

Hi

We face the exact same issue, trying to move Backup Copy files to another repository, and then map the existing Backup Job to these files.

Any update about one upcoming fix or patch ?

Thanks

[foggy]

Patch 2.

[Brad.Morris]

I have the same issue and have just logged a job with support. They want me to send them the VBM file for them to fix.

[veremin]

For now the manual correction of .vbm file might do the trick. So, if you experience similar issue, don't hesitate to open a ticket.

As to fix, according to a plan, it should be included in the patch#2.

Thanks.

[Brad.Morris]

Do you know when Patch#2 will be released?

[veremin]

There is no ETA at the moment. Thanks.

[Brad.Morris]

Any update on this. It is causing me lots of grief as I have to move some data around and worried that I am going to lose my retentions.

Any chance of getting a hotfix for this?

[veremin]

Patch 2 is yet to be released. AFAIK, the solution for the said issue is incorporated in the patch and is not available as a separate hotfix. Thanks.

[Brad.Morris]

Umm not very happy about this.

[veremin]

We're working hard to release the said patch sooner, rather than later. So, stay tuned!

[pchelfer]

Have also the same problem, please fix it in short time.