Merge Backup sets - Backups and maintenance / one offs

[odge]

Hi

I hope my reasoning here comes across clear the first time, but you might end up asking questions. - I might edit the question if that's the case, so that first time readers get the point earlier.

Based on other threads like https://forums.veeam.com/vmware-vsphere ... 23351.html which is all about merging VBMs.
As well as https://forums.veeam.com/post275376.html#p275376 which is about the nightmare of accidentally creating an Active Full.
https://forums.veeam.com/post274807.htm ... up#p274807 - someone trying to change the retention policy on a job using some tricks

To be clear, this question then is more about "general maintenance options".

To me, something that is lacking with large datastores to backup, is a intuitive way to manage that stored data. Things change, and often the two alternatives availalble to me are "the status quo", OR "running long backups" (like a week long), which is usually such a big deterrent to changing things - that you stick with the status quo until it breaks.

Over the past 9 years of using Veeam, with increasingly more customers we manage, and larger datasets, I'm surprised that the need to "suck a backup out of one backup" and use it as a seed somewhere else, or moving its backup chain to a different job isn't something the product has started to deal with. For Clarity sake, we aren't talking about Backup Copy Jobs - just normal backups, and I've seen lots of threads with little tricks for Backup Job jobs- which I wonder why they have to be tricks at all.

Some examples I could think of:
maybe the a client has a single VM that needs to be sucked out of a massive backup chain, and into another massive backup chain, and the original backup chain is removed?
Maybe the client wants to move data between scale out repositories - for whatever reason that may be, but because the data is in the VBMs, he cant.
Maybe the client makes a mistake an accidentally makes a Active Full, why not let them easily undo this without what appears to be a bit of a "hack". Why not be able to see what the job will be when it runs, and be able to override it. One click to this screen without actually modifing the current settings.
Maybe the client has lost data, and still has a copy job data, but wants to use that as a Seed for the original backup (that seems like a strong case).
Maybe the client wants to run a Synthetic Full - while the job isn't even running, for whatever maintenance issue they are dealing with (a job that perhaps missed its synthetic full, and now has too many incrementals) - why not have that has an easy override for "run the job now this way" without having to do all sorts of tricks, like removing VMs or changing settings of the actual job?

Those are a few I can think of, I would imagine other people have similar one-offs, but the combined time of all the users out there, plus their research required to archive things, is probably being overlooked? And once they solve that (with many hours of research or tears, or unprotected VMs) - they don't necessarily harp on about it - but it would have added a lot of pain-free time had there been methods like those above.

Don't get me wrong - I'm not "complaining", I just wish some tasks were easier, or if part of the Dev team starting thinking about "what if" scenarios that people might find themselves in, and providing generic ways to solve some of them.

Keep well!

[odge]

Some extras:

Running a transform on a single VMs chain instead of all VMs.
Running a transform - on demand, without first running the job


No replies from anyone on these?

[foggy]

Hi Matthew, sorry for the late reply - your feedback is appreciated anyway. Your suggestions look reasonable and some of them even have their dedicated "feature request" threads (like standalone synthetic tool or splitting a single VM backup out of the chain, for example), so everything depends on the feature prioritization on our side here.

[odge]

Hi Foggy

Can you link me to the thread for the standalone synthetic tool... wow, that could really save a lot of time.

But in general, I'm sure whats happenining, is people are spending really large amounts of time on such tasks, phoning your support on ways to figure it out, so while it might seem low on the priority list, these kinds of problems use 10s hours of each customers support each year (probably in excess of their entire use of the product the rest of the year), but you guys dont get clear feedback for it.

[foggy]

Seems you've already nailed that thread yourself. I didn't mean there's an utility though, but some sort of a workaround is mentioned there.

[c.schulzejn]

any news on that topic?
I came across that topic bc we want to move a some VMs from one backup job to another.

[veremin]

No, nothing has changed since the last reply. Thanks!