Restore point is located in backup file not mapped to any backup job

[Zew]

Case # 04444672

I had this issue when trying to create replicas after mapping them to exiting VMs in this post. post387449.html#p387449

So I created the replicas from a DR Veeam server at the DR site as best practices, and all the VMs created just fine.

Veeam Production - Backup job (fine - regular incremental) - BCJ (uses linux managed server at DR site, added NFS source as repo) Job runs fine Dataexists at DR site.
DR Veeam - Replication Job (Source DR repo, same linux managed server and repo production Veeam uses for BCJ, all jobs show under Disk (Imported)) - Source: DR site and replica seeding enabled.

All jobs run fine with the final step warning with source has no newer points than seed (perfect no problem).

This one VM just refuses to finish properly with instead the error in the title "Restore point is located in backup file not mapped to any backup job".

I've looked through the forms mostly all leads to dead ends... what gives? This issue is starting to really irritate me...

[soncscy]

Heya Aemilanus,

I've not seen this message before, but I know of the scenario, and I wonder if you this situation here

The backup job to which you map the imported backup file on another backup server must run periodically and produce new restore points. You cannot create a job, map the imported backup to it and never run this job.

I've tried to do this with clients and they ultimately opened a support case, and this was the answer we got.

So I think maybe it's not a long term stable solution. I ended up convincing out clients to rearchitect to have just a single VBR server controlling, or pulling from production.

[Zew]

OK Foggy, probably going to be upset with me and state the obvious which he's stated many times about the "dummy jobs" I need to configure (since now any jobs after the initial job fail with the same error) so all jobs show this.

However from here veeam-backup-replication-f2/how-do-i-re ... ml#p137169:

"Post by alanbolte » Feb 18, 2015 5:03 pm 2 people like this post

I just want to clarify that the dummy job workaround is not a supported configuration - some customers have had success with it, but known caveats include several possible problems if the backup and replication jobs run at the same time, needing to remap the dummy job after certain configuration changes on the source backup server, and needing to script repository rescan if you want to replicate more often than the default rescan rate.

For replicating from backup when both jobs run on the same server, here are my thoughts on three methods that allow failover with Re-IP:

1. Run all jobs from production side, with encrypted configuration backups to offsite (recommended):

Pros: Easy restore from backup, fast and easy backup of Veeam server.
Cons: More steps to failover replicas in DR scenario, because you must first restore configuration to DR-side Veeam server. Configuration backup cannot be configured more often than daily, but configuration restore will automatically rescan for replicas so that shouldn't be a problem.

2. Run all jobs from production side, with replication of Veeam server to offsite:

Pros: Easy restore from backup
Cons: Replication of Veeam server is likely to be slow due to lack of CBT (also can't hotadd itself) and will only occur when Veeam server is not being used as a proxy for other jobs, so it may be impractical to replicate frequently (e.g. hourly). In DR scenario, you have to power on the replica of the Veeam server manually (and change its IP) before failing over the other replicas. If the replica content isn't up to date, you have to remember to rescan the replicas before failing over.

3. Run all jobs from DR side:

Pros: Fastest and easiest replica failover in DR scenario.
Cons: Must import backups to production-side backup server (or rescan repository) to perform Windows FLR. Explorers (AD, Exchange, etc) must be launched from FLR instead of in one step. Somewhat greater chance for job failures involving AAIP, depending on your WAN connection."

I don't really like any of these solutions... my main question now are as follows:

1) WHY do I need to map dummy jobs to even having something close to a smoother "proper" failover setup with a Veeam server at the DR site?

2) If this is technically not supported... what is? How do you setup a DR site with proper failover/failback?

[Zew]

THanks for the post Harvey, did you by chacne ever manually create this dummy job and run it? or did you have to like import the entire veeam config from the Veeam primary site to the Veeam DR site?

[foggy]

1) WHY do I need to map dummy jobs to even having something close to a smoother "proper" failover setup with a Veeam server at the DR site?

2) If this is technically not supported... what is? How do you setup a DR site with proper failover/failback?

This is only the case when you're seeding replication with the backups created by a different Veem B&R instance, which your Veeam B&R instance responsible for replication jobs is not aware of. In other cases no dummy jobs or whatever are required, you just get the failover setup automatically.

[Zew]

That didn't explain the why.

There's still no support solution provided here.

I'm not the first to complain about this type of a problem, and I feel it's the lack of understanding the issue based on the infra.
Seriously though others have asked about how to make Veeam HA veeam-backup-replication-f2/what-is-the ... 1-270.html

Like seriously understand something, 1) My DR site is routeable in my internal network via IPSec tunnel, 2) Systems at the DR site are cold and offline, and any running systems (like Veeam) use DNS from the primary site.

In the constant answer of: Well just copy your config to the DR Veeam and start restoring. It doesn't work that way as the recoveries rely on both DNS (it's down) and vCenter (It's down). How do you officially support a failover in this infra?!
So like seriously even IF I did that, the Veeam service probably wouldn't come up due to DNS issues, even if it did the Veeam infrastructer area would be broken as the main vCenter server is not accessible. There's only the Veeam server, a backup copy datasets in a local repo and a single standalone host.

Doing manual restores and powering up the VM's would break all my chains (backups at primary site) if I ever tried a manual failback (if it's even possible).

Now what am I suppose to write up in my DRP/RTO's well we have higher than expected RTOs cause in the event of a failure at the primary site I have to manually spin up all the replicas, and Veeam has NO idea about the replicas state for failback operations....
My boss and even my expectations are like... what is this?

[foggy]

Like seriously understand something, 1) My DR site is routeable in my internal network via IPSec tunnel, 2) Systems at the DR site are cold and offline, and any running systems (like Veeam) use DNS from the primary site.

In the constant answer of: Well just copy your config to the DR Veeam and start restoring. It doesn't work that way as the recoveries rely on both DNS (it's down) and vCenter (It's down). How do you officially support a failover in this infra?!

Well, you need DNS for your DR environment to work anyway, so you should take care of that prior to starting the restoration. At least some supporting infrastructure supposed to be already in place to start the process (DNS, routing, etc.).

[Zew]

My Goal was to have the Veeam at the DR site have the ESXi host added to it only via IP, hence it could start the DNS servers in proper order to bring everything else required up in sequence, but since this is somehow not possible cause I don't have "linked backups" the whole desiign implications Veeam offers are missing a lot of information to make it actually feasible.

Also vCenter is still down, so how does that work? you can't expect someone to restore vCEnter at their DR site when almost all the host it manages are down at the primary site.

[foggy]

The issue in your case is the fact you're trying to use backups produced by another Veeam B&R instance - this is the only case where this 'dummy' job workaround is required. In case you did regular "pull" remote replication (not replication from backups), that wouldn't be required.

[Zew]

Thank foggy, that explains the why to the question mainly asked in this thread, and the thread title, however that kind of sucks, cause the only way to "pull" would mean the entire VM data would have to go over the low bandwidth WAN... So seeding would be terrible... so guess I'd have to seed an alternative way, maybe the way I asked about and tested earlier in these forms.

[foggy]

...the only way to "pull" would mean the entire VM data would have to go over the low bandwidth WAN...

Actually, no, as replication would transfer the same amount of data the backup copy does. Besides, you could seed the replica from a backup to avoid a massive initial transfer.

[Zew]

Gotcha, Veeam at production runs primary backups, and BCJ to storage at DR, Veeam at DR site runs replication job which seed replica from backups at DR storage (from the BCJ pending rescans to ensure sync), but source production VM (do not source from a backup repo).
You mean like this?

Could test that, I was kind of already sticking with all jobs at production site Veeam, and manual spin up of VMs at DR in case a full production site outage and have the service infrastructure in place to host the services those servers provide, then when it came to failback when main production site I create replication jobs on the Veeam server to replicate back mapping them to the original VMs at production side. With estimated and simulated failover/failback downtimes.

[foggy]

Right, you can use the backup already available at DR for initial replication seeding.

[Zew]

Meh, case was closed with unsatisfactory results. Can't win them all. I hope others reading these post learn and understand the limitations of Veeam B&R and what Veeam expects in a full DR scenario.