Host-based backup of VMware vSphere VMs.
Post Reply
infraerik
Enthusiast
Posts: 28
Liked: 1 time
Joined: Jul 24, 2019 10:04 am
Contact:

Back evacuation failures

Post by infraerik »

I'm seeing an odd one here on a client configuration where I'm trying to evacuate backups from a performance tier and I'm getting the following errors on a significant (but not 100%) of the backups :

Code: Select all

[21.06.2021 08:49:14] <28> Error        Failed to dispatch pending task. SessId: [bf0dd04f-cc5f-46c0-85d6-43234c308772], Task: [000-Infrastructure_clone1D2021-06-11T200029_595E.vib from job "Backups evacuation" (task id:069e22a2-60fe-4245-bcad-a0a78c7de481, task sess id:00000000-0000-0000-0000-000000000000, job sess id:bf0dd04f-cc5f-46c0-85d6-43234c308772)] (System.Exception)
[21.06.2021 08:49:14] <28> Error        Last storage chain does not contain full storage. (System.Exception)
For the full context: This is an older repository Windows physical server with NTFS formatted disks. I added a new Linux repository to be used as swing space and unified this with the existing repository in a SOBR. All of the jobs correctly updated to point to the new SODR. I set the old repository to maintenance mode in order to start active fulls on the new one so that the backup evacuation could be done later with less impact on the backups. The old repository was not using per-VM files so before evacuating the backups, I forced an Active Full to clean that up.

Currently, I see the following options :
- manually copy the remaining files via SSH to the new repository in the correct directory and rescan, hoping that is makes the correct linkages and that there's no conflict with the .vbm files
- manually copy the remaining files elsewhere and then import them so that I have access until they age out of the retention window
foggy
Veeam Software
Posts: 21139
Liked: 2141 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: Back evacuation failures

Post by foggy »

Carefully copying the chains manually should work but I'd also open a case and let our engineers take a closer look at the log files to identify the reason for the failures.
Post Reply

Who is online

Users browsing this forum: Bing [Bot], Semrush [Bot] and 62 guests