Comprehensive data protection for all workloads
Post Reply
wku
Influencer
Posts: 11
Liked: 4 times
Joined: Nov 07, 2016 1:31 pm
Contact:

Move of old agent backups - all renamed under one old job's name

Post by wku »

TL;DR version:
Old agent backup contents are fine, but their visible names/titles got overwritten during a "copy backup to another repository" operation.
I was stupid and didn't notice until the old repository was gone, so can't re-copy from source. Looking for advice how to rename them.


So I've been retiring an old repository.
Among other things it contained a bunch of old veeamzip backups and agent backups of retired machines.

I've went to "Backups>Disk (Orphaned)", unfolded the "Agents" folder, selected all of the agent backups inside with Shift, then right clicked -> copy backup -> new repository.
("Move backup" is/was not an option for agent jobs).

That laziness bit me.
Veeam created one move job with a name taken from one of the linux agent jobs - "Copy backup (lnxsrv123.corp Backup Xyzapp Server)" - and somehow grouped all of the other backups under that name.

So now under Backups>Disk (Exported) I have an "Agents" folder which contains a lot of rows like
  • "lnxsrv123.corp Backup Xyzapp Server" (contains server lnxsrv123, original agent job name "lnxsrv123.corp Backup Xyzapp Server")
  • "WINSRV10 lnxsrv123.corp Backup Xyzapp Server" (contains server WINSRV10, original agent job name "Backup Job WINSRV10")
  • "WINSRV91 lnxsrv123.corp Backup Xyzapp Server" (contains server WINSRV91, original agent job name "Agent Job WINSRV91 (Application Name Here)")
and so on.

It is a cosmetic issue, but a somewhat confusing / dangerous one, both making it easy for someone years down the road to misread and assume they're all backups of lnxsrv123, and much harder to find a relevant app's backup as the original job titles are lost and only the internal hostnames remain.

I have tried to grab one of these "renamed" backups and copy it again to another temporary repository; I've also repeated my original bad-move and selected multiple such backups to have them appear inside of a single "Copy backup" systemjob. Unfortunately the "lnxsrv123.corp Backup Xyzapp Server" caption remains "stuck" to them.

The on-disk path in the new repo becomes "X:\RepoRootDir\DOMAINNAME_WINSRV91_\lnxsrv123.corp Backup Xyzapp Server".
The original vbk/vib names are there ("Agent_Job_WINSRV91__Application_Name_Here_YYYY-MM-DDTHHMMSS.vbk").
The metadata file lands as "lnxsrv123.corp Backup Xyzapp Server_RANDOMHEX.vbm" and of course contains the "sticky name" in all of the xml paths inside.

I guess the windows based backups had a blank title field in the metadata which, once accidentally filled with the linux job's info, will remain like this.
They were quite old and upgraded over the years - the "Backup Job SERVERNAME" style came from Veeam Agent v3 iirc, which didn't even allow custom names.

So... any ideas how to deal with this mess?

I think it might work to "remove from configuration", manually move the files to correctly-named folders in the destination repo, then rescan the repo.
They might then show up under Imported or somewhere such.

However i'm guessing that if I won't delete the .vbm file (which itself has the wrong name and lists file paths with the wrong-named subfolder) things will error out, and I'm not sure if it's possible to import a set of incrementals without a .vbm.

This is this exact kind of a low-stakes high-frustration thing where it's basically not worth it to open a support case - it would have to be very low severity, which in turn would make me feel like a Karen stereotype trying to push back and escalate against the inevitable "sorry, you have to live with these names" reply from the first line.
david.domask
Veeam Software
Posts: 2607
Liked: 610 times
Joined: Jun 28, 2016 12:12 pm
Contact:

Re: Move of old agent backups - all renamed under one old job's name

Post by david.domask »

Hi wku,

Thanks for the detailed description, and sorry to hear about this challenge.

To the point directly, the rescan strategy will not work -- rescan detects by VBM file, and it's not clear for me if you have a single VBM file for the copy or individual VBMs for each of the copied machines.

However, your idea of moving the backups to a specific folder, removing from configuration and then using Import Backup on the individual VBKs will get the machines separated out into a more intelligent grouping. (if the VBK has incremental backups attached to it, the increments will be imported as well) Similarly, you can automate this process with Powershell
David Domask | Product Management: Principal Analyst
Post Reply

Who is online

Users browsing this forum: Amazon [Bot], Bing [Bot], Heyko and 152 guests