Fixing: Backup Repo # not found

[Zew]

Just wanted to provide some steps I had to do to fix an erro rI was getting on one of my Backup Copy Jobs.

I had renewed my Original backup Repo, I migrated as much old backup data as I could and decided to just build new chains on some of the less important VM's.

All my other jobs went fine till I did this one, I double checked that teh orginal job had a second job pointing to my BCJ, I checked in the BCJ that it was still pointing to my original offsite repo and source was the primary backup job.

"29/09/2016 5:18:26 PM :: Error: Backup repository 'a44b1452-5096-4a73-a59a-65663eafd341' was not found"

When I first started the job my IPSec tunnel went down "unable to reach backup repo" and I figured this was the initial part of the problem, after I had verified the tunnel was up and the backup repo was reachable I rescanned both my primary and backup repos.

Scans on both completely successfully, but error remained when re-syncing job.

At this point I simply edited the job and re-mapped it. After that the job started working normally.

Anyone what might have caused this? The original offsite repo was not changed, how would the mapping have got messed?

[Shestakov]

Hello Aemilianus,
Have you checked if the connection between source and target repositories of the backup copy jobs is stable?
Do you have other jobs using the repository?
Thanks!

[Zew]

The connection between my source (local Veeam server) and my target off site repo is not the most stable.

I have since moved my connection from a crappy dedicated 5/5 (mbps) to a aDSL 50/5 (mbps) connection, ever since I moved to this service from MTS (using a PACE modem) my IPsec tunnel goes up n down all the time (base don emails I receive from my firewall), also from playing around (couple nights ago the connection was down (like the modem itself wasn't even responding to pings) for almost an hour. I had just finished moving my routes for that zone to go through my primary internet connection provided from another ISP (which is wayyyyyyyyyyyyyy better and reliable), when the POS PACE came back online.

I have been fighting with MTS for months on end to get this resolved, but they have no other hardware for that service, and they wanted over $400 a month for a crappy 5/5 connection and no actual SLA.. it was insane.

[Shestakov]

That`s probably the reason. You may contact Veeam support to find out the exact reason using your logs.
By the way, besides IPsec tunneling you can encrypt the backups in backupcopy job. If the encryption is sufficient, absence of tunnel will speed up the data transferring and make it less complex.

[Zew]

I prefer to use an IPSec tunnel with a known cipher suite connecting my cold site. I prefer this method (even with the overhead) for security reasons. Thanks for the suggestion.

Trust me getting a better secondary ISP has been on my chopping block for a while. The internet provided by MTS is literally unacceptable.

[Shestakov]

I see your point. So let us know if stable connection solves the problem once you have it.
Thanks!

[Zew]

This only occured once, What I get pretty much on every Job is this...

04/10/2016 10:31:55 PM :: Processing VM Error: Reconnectable protocol device was closed.
Unable to retrieve next block transmission command. Number of already processed blocks: [54782].
Failed to download disk.
read: End of file
Failed to upload disk.
Agent failed to process method {DataTransfer.SyncDisk}.

But the job eventually does complete and I will get an email warning with said error, go to check the job and it has indeed eventually completed. I'm hoping I won't have to see that error anymore once I get a good internet connection.

[Shestakov]

Did the job session have retries?
By the way, do you use Surebackup to verify recoverability?
Thanks!

[Zew]

I tried surebackup, don't like it, At first it was marketed as "Instant Sandbox" to which that was a flop cause the about of "re-hydration" (Going through incremental, depending on what point in time you are building your backup test from) which was terrible as soon as you had a couple dependent VMs (AD, SQL, Web Front ends). Went from "Instant" to "Hours" with terrible performance.

So then it just became Surebackup to ensure the backup files could indeed do they job, again generally I find it hard to very a bunch of these VMs that they indeed come up correctly as they have login dependencies on AD for a lot of their services. I have yet to have any of my backups not work, unless the backup job itself clearly failed, other than that I find the amount of resources required to run these isn't that great. Also note I did these tests with an All-in-One Veeam server, which currently resides on one of our production hosts, but have since built a standalone (Not in my production HA Cluster) that I can move this backup VM to, this host also runs our entire test enviro (which is currently made of restored VMs from my backups running on it's own direct storage) this reduces any load on my production hypervisors.

Sorry, just had to get my rant about how much I dislike Surebackup... had nothing but problems with it, and if you cover the fourms many other experience the same type of annoyances I did. Just had to express my dislike for that feature. To top it off it's the ONLY feature you get with enterprise, if you want any of the good stuff (Storage integration (snapshots), WAN accelerators) you have to get Enterprise PLUS. Marketing, phhhhh.

[Shestakov]

Thanks for the feedback, Aemilianus
How many VMs do you verify in Surebackup in the same time? Does they have long backup chains?
By the way Surebackup is not the only Enterprise-level feature.

[Zew]

Thanks for that link. I wasn't aware of the limited functionality of the Exchange and SharePoint explorers with standard Veeam, The standard functionality generally provided me what I needed for most of my restore purposes. So I generally never noticed them from a use case perspective. I just noticed the feature by what was enabled directly in the GUI, never caught those other one as I clearly never used them before.