Exchange Copy Job and tranfer to Tape Restore problem after Migration to V12 and no more Legacy Copy Job

[maregg]

) The root cause of the issue

Version 12 introduced a significant change in the structure of backups format and metadata. Previously there was a single metadata file for all VMs in job, which had some restrictions. In version 12 VBR started to create separate metadata files for each VM in job, which allowed adding other new features - possibility to move VMs between jobs and repositories, detaching backups of separate VMs and more.

That also introduced "Legacy" jobs, which use backup chain format from earlier versions, basically are jobs that work exactly as in version 11 and do not allow usage of new features I mentioned.

All jobs created in version 12 are "default" (non-legacy) and work according to the new principles.


2) The change history. I'm not aware of a special announcement of this particular behavior, but there are differences in documentation between versions 11 and 12 that reflect the change.

In version 11:

https://helpcenter.veeam.com/archive/ba ... store.html

"When you copy failover cluster backups, consider the following:

If you copy a failover cluster backup in the immediate mode, the job ignores the Use per-machine backup files option enabled for the backup repository and creates a single backup copy file for each cluster. If you copy a failover cluster backup in the periodic mode, the job will create backup copy files as set for the backup repository."

If we compare that with the exactly same page for version 12, we can see that the phrase "If you copy a failover cluster backup in the periodic mode, the job will create backup copy files as set for the backup repository." is no longer there:

https://helpcenter.veeam.com/docs/backu ... ml?ver=120

"When you copy failover cluster backups, consider the following:

If you copy a failover cluster backup, the job ignores the Use per-machine backup files option enabled for the backup repository and creates a single backup copy file for each failover cluster."



So Legacy Copy Job is the workaround !!!


That we have to restore a restore from tape for a mailbox with a few kb under circumstances of 4.7 Tb now more than 27 TB.



Therefore we have to set up a restore repository of at least 27 TB.



This is simply not acceptable. And I don't think we are the only Veeam customers in the world with this problem.



Otherwise, Veeam as a software manufacturer should announce that they cannot recommend a backup of Veeam DAG servers. And reach their limits in terms of tape processing.



We can write mails back and forth for hours, they have all the logs, mail and printscreens.



Personally, it seems to me that Veeam Support is reaching its limits with this call.



I will now probably contact our sales representative from Veeam Switzerland and make our displeasure known.



Hence my last question in this case,



what we Veeam now do with this call, will it be closed, will an escalation be made, will a patch be created or will we simply be left alone with our problem.



I am looking forward to your feedback so that I have to confront the Exchange administrators with this problem, because they are not satisfied with this solution either.

[maregg]

This must be a feature request !!!

[david.domask]

Hi maregg,

Thank you for the detailed post and the case number, and sorry to hear about the challenges here.

First, the situation is understood; reviewing the case, I can see that the changes in v12 had a negative impact on your workflow and we'll discuss how this can be handled better (perhaps allowing FLR/Application restore from tape may help as ultimately the goal is to get the EDB and/or mailboxes themselves restored from tape in a timely fashion and without needing excessive space)

Support's statements are correct; at this time, the only solutions would be to continue with the Legacy Jobs as you have settled on or consider a solution where the EDBs are backed up directly to tape from a File Level Restore (FLR) session / disk publishing session, though I'm not eager on these options as it would require scripting, though it would help meet your needs more directly.

FLR / Application restore from tape would be a feature request and will discuss internally; if you're willing to consider the scripting option, would be happy to discuss it with you.

[maregg]

ello David,

i am pleased with your post on this matter.

To understand a little about our situation,
We do a backup from a DAG cluster to a hardening repository with about 35 days retention time.
Then a legacy copy job to a second repository and from there with a tape backup job and this data is written once a week to a virtual tape library with a retention time of about 370 days.

This allows us to start a restore from tape in the event of a restore request from our Exchange department.

However, there are a few points to bear in mind.

Up to V11, we were able to start the restore from the individual DAG clusters and we only had to export approx. 4.5 TB from tape to our CS8800 VTL from Fujitus.

We can use a prefetch job to load the restore of the virtual tapes required by Veeam in parallel into the cache of the CS8800 VTL. This speeds up the restore from tape enormously.

However, we usually only had to have one free disk space on a repository of more than 4.5 TB.

Now with the V12 we have to restore 27 TB from the VTL without the workarand with the legacy job and also have 27 TB of free space on a repository.

So with more than 3000 mail boxes it can happen that several restore from tape jobs can be done in parallel.

This means that 27 TB restore x restore jobs also require more repository capacity for the restore.

So a restore direct from tape would of course be an incredibly great function in Veeam.

Also for the prefetch job on our CS8800 Eternus ,

A prefetch job that could automatically start the prefetch job during the restore from tape would be a great enhancement.
Since our external administrators have to be on our "proactive" action during a restore, so that we have to generate the prefetch job ourselves in a script.

prefetch is integrated into the restore from tape at Networker from Dell and also at Comvault, unfortunately Veeam is not competitive here.

[david.domask]

Happy to try to assist here maregg, and thank you for the details.

There are a few items not so clear for me on your workflow so let us continue temporarily in private message, and will post the conclusion to the thread at a later moment.

[montriconet]

Hello,

I would like to know if this also affects SQL Backups (Always On Availability Groups (AGs)), on Tape.

Has anyone ever tried it?

Regards.

[david.domask]

Hi montriconet, welcome to the forums.

Just to avoid confusion, the above situation is related specifically to a change in the Backup Copy file format in Veeam v12 for Backup Copies of Veeam Agent for Windows backups of Exchange clusters; can you tell a bit more about the SQL backups you're making? Are they backups of VMs (Vmware/HyperV) or are you using Veeam Agent for Windows?

[montriconet]

Hello David, thanks for answer.

SQL backups are of virtual machines in a VMware environment; we are not using agents for this task. Backups are made to a Data Domain, and then a copy job is created to a tape device, with a 10-year retention period due to government regulations.