Offsite Backup Copy jobs in Ver 12

[stevehughes]

Hi,

With Ver 11 and previous our standard strategy has been to run hourly backups to a 'Daytime' repo, a nightly 'Retention' Backup copy job which pulls from the 'Daytime' repo and saves to a separate local 'Retention' repo, and finally a nightly 'Offsite ' Backup copy job which pulls from the 'Retention' repo. By doing this we can avoid having the offsite job, which might take some time, from being interrupted by the hourly Daytime backups.

Backup jobs in Ver 11 could be configured to pull from a selected repo using the 'Source' options, but this is missing from Ver 12.

What's the recommended way of handling thsi in Ver 12?

Thanks,
Steve

[HannesK]

Hello,
correct, in V12 the backup copy job from backup copy job (BCJ from BCJ) is missing.

I see two options:
1) keep the environment on V11 until the functionality is back
2) copy from the original source

Best regards,
Hannes

[stevehughes]

Thanks. Is there a plan or a timeline for this functionality to be returned? Finding that to be missing is quite a problem.

[stevehughes]

Does nobody else find this a problem? If so then perhaps I am going about the offsite backups the wrong way.

[Gostev]

@Dima P. was this change intentional?

[Dima P.]

Hello folks,

Steve, we plan to add this functionality to new backup copy engine in one of the upcoming versions.

Legacy backup copy processes VM as a source while new engine processes jobs. Currently it cannot process more than one level of job hierarchy: primary job 1 > backup copy job 1 ( primary job 1 a source ) is possible, but backup copy job 1 > backup copy job 2 (backup copy job 1 [ primary job 1 a source ]) is not.

[archambeaud]

Yes impatient for the feature to be back.

I'm in the same case

[BackupSlacker]

Since you are keeping 2 full backups in one location (the backup job + the backup copy) and then offsiting it with another backup copy job, can you not do the following instead?

Backup job 1, every hour except for 1 hour of your choosing (example not 12:00am)

Backup job 2, daily 12:00am

Backup copy job, daily after Backup job 2 finishes.

only caveat is you will have a delay on the initial backup in job 2 because it has to create a full backup for the first run but after that its essentially the same as backup job 1.

[stevehughes]

Yes that would be a workaround - thanks for the suggestion.

An additional full backup would grab about 50TB of additional storage - not a good outcome. Perhaps we could avoid the consumption of additional space if we map the new backup job to the folder containing the existing backup copy, but that's not something I've tried before. I'm also not sure whether running 2 backups jobs would correctly handle CBT. Perhaps Veeam can advise.

The unexpected removal of existing useful features is something I associate with Microsoft, not with Veeam. I'd be very grateful to see this functionality restored 'ASAP, as a matter of priority', not 'in one of the upcoming versions'.

As far as I can see this issue prevents us from rolling out Ver 12 to our client sites.

[Taroking1]

This is unwanted but not unexpected.

It is in the documentation that this is going and I doublechecked with Veeam and they confirmed that this feature was not going to be in the initial release of V12. Although there are other features I am really wanting from V12, this issue is a showstopper for us and we have to wait for it to be implemented before we upgrade.

[DE&C]

This is a big issue for many of our clients. At the moment, there are even public tenders asking for exactly that (only 1xbackup from source, many copies)

Veeam has many features to minimise the load on the source (Direct SAN, from Storage Snapshot Backup etc.). There is a reason why customers use them and copy the data from a backup copy job multiple times: Backup window requirements and/or heavy load on production.

[stevehughes]

Yes. Recently we have been trialling a new strategy at a couple of key sites to guard against loss of backups due to a repository failure.
Hourly VM Backup -> Repo 1
Immediate copy of hourly backup -> Repo 2
Nightly Retention backup with GFS -> Repo 1
Nightly Retention backup with GFS -> Repo 2
Nightly offisite -> CloudConnect.

This is completely dead in the water with Ver 12.

[ITP-Stan]

Just FYI, multiple back-up jobs for the same VM is no problem with CBT.

[stevehughes]

Hi Hannes,

Is there a planned timeframe for these features to be made available?

Thanks,
Steve

[HannesK]

Hello,
we cannot provide a timeframe right now. The answer of my colleague from above applies (backup copy jobs are "his" feature).

Best regards,
Hannes

[Patrick_Gruber]

Case # 05908977

Hi!

In VBR11 I had some copy-jobs sourcing from copies.
That is because I have a couple of locations I do backups to on-site repos, then copy them to HQ for archiving-purposes.
After that I do a copy to an immutable Linux Repo. This repo resides on HQ-site.

WAN-links to overseas and to smaller locations are not that fast, so a second copy over them is not possible (and shouldn't be!)

In VBR11 it was possible to select a source repo for a copy job. So I configured a second copy job for the main backup job.
Selected the HQ-repo as Source and all further copying to immu repo happened in HQ.

Unfortunately I upgraded to VBR12. The option to select a source repo is gone. Completely.

Support told me that the solution I used in VBR11 was a not supported workaround.

Am I the only one having this issue? Are there any "new" workarounds known?

Thanks,
Patrick

[Mildur]

Hello Patrick

Welcome to the forum.
Yes, v12 won‘t allow you to create such copy jobs.
Old backup copy jobs created before the upgrade will still work.
We plan to bring the feature back, please see the comments of my colleagues here in this topic.

Best,
Fabian

[Patrick_Gruber]

Thank you, Fabian.

As I've only upgraded one off-site-job to V12, is it somehow possible to create a legacy-backup-job in V12?
The other jobs I upgraded are HQ-jobs not affected by the mentioned restrictions.
It is only one Backup-Job with its two Copy-Jobs that should be converted back to legacy.

Thanks,
Patrick

[Mildur]

Hi Patrick

You can‘t create new legacy jobs. If you still have the old legacy job from the migration, you can use it again for the backup copies.
I expect the next run to be an active full copy. The old chains are updated and attached to a new copy job. They won‘t work with the old legacy job.

Rolling back to V11a with a configuration backup may work, but the upgraded backup format will be an issue. V11a will not be able to use them.

Best,
Fabian

[ITP-Stan]

Would it not be a good idea to warn people by putting this in the issue tracker?
veeam-backup-replication-f2/top-issues- ... 85262.html

[Mildur]

Hi Stan

Thanks for your recommendation.
Technically it's not an issue. Issues in that topic are bugs which will be resolved by hotfixes or cumulative patches.
But we are working on making the changed behavior more visible. We are planning it to add it to the release notes and user guide upgrade checklist.

Best,
Fabian

[stevehughes]

Gostev has advised in the above 'issue tracker' thread that the first cumulative update for V12 is expected sometime in April. Will this update address the missing BCJ from BCJ functionality?

[Gostev]

No, cumulative patches are to address bugs and this is not a bug but a known limitation of the new backup copy engine. Dima will comment which product version this is planned for, once he's back from vacation.

[bhrvi]

You can‘t create new legacy jobs. If you still have the old legacy job from the migration, you can use it again for the backup copies.

So I've got to ask.. Despite this statement, there's really no sneaky back-end way to create a legacy backup-copy job? I find that we've put ourselves in a bit of a pickle with this since we need to have backup-copies of specific VMs and adding an entire backup job and then excluding what we don't want to copy isn't tenable since our environment is very dynamic.

[alexben26]

Hello,
My issues Case #05989350

Since I updated my backup chain on my backups, I had to create a new corresponding copy job because my old legacy copy job no longer worked.
error : "Legacy backup copy jobs do not support new backup chain format of the source backup. Please recreate a backup copy job and map your existing backup files to the new job."

So I recreated a job copy and proceeded to remap the job. I restarted the backup copy and it works...perfect, but on my old copy job, I was using a very useful function, the source backup repository option, which no longer exists?

Let me explain the usefulness of this option:

I have 3 remote sites each with a local repository
I have a 4 -th CENTRAL site containing a large storage volume (dell unity type) + another large storage volume (exagrid type) and an LTO backup robot.



My backup plan was as follows:

The 3 remote sites have a local backup job.
The central site has a local backup.
The 3 remote sites after their local backup perform a backup copy to the central site.


The central site therefore has all the backups of the group.
I backup the central site (containing all the backups and all backup copy) to the LTO robot
I also backup the central site (containing all backups and all backup copy) to exagrid storage.

It is this last job copy that I have a problem with. (the copy job to exagrid)

I can create the task on a new job copy but I can't select the SOURCE. Consequently, it does not take data from the LOCAL central site to the exagrid, but from the REMOTE site to the exagrid.
Which is very restrictive for my case, because my VPN link is therefore very busy, and I already had the data LOCAL on the central site….

Do you have a workaround?

Thanks

[Mildur]

Hello @bhrvi
Unfortunately not. Legacy copy jobs cannot be created.

Hello @alexben26

Welcome to the forum. I moved your question to this topic.

The function you are looking for to copy backups "from a backup copy job" is not available in V12 with the new backup copy job type. Our plan is to reintroduce the feature in a future version. My colleague Dima will comment on this issue as soon as he is back from his vacation.

Best,
Fabian

[stre1026]

I have a secondary datacenter that has a repository and a separate immutable repository of smaller size. I have backup copy jobs that copy backups from the primary site to the secondary site. I also have a backup copy job that copies backups to the immutable backup repository. Prior to the v12 upgrade, I'm almost certain I was able to lock down the VMs that were being copied to the immutable repository to only certain VMs on the secondary repository to save bandwidth. The connection between the datacenters is only 100Mbps so I wanted to save as much traffic as possible. It seems after the v12 upgrade and upgrading the copy jobs to the new format, this option is gone. Am I missing something? Is there a way to copy only certain VMs from a secondary repository to the immutable repository so the traffic stays local to the secondary site?

[Mildur]

Hi Stre1026

Yes, Backup Copy from copies is not available with the new format. We will bring it back in a future version of Veeam Backup & Replication.
There is no workaround available if you have already updated the chains.

Best,
Fabian

[Snoopy354]

Yes Backup Copy is very importend please make this.

Best,
Bruno

[FrankS2]

We need this feature too.
Please tell us when it will be available again.

Best Regards,
Frank