From infrastructure function missing in new backup copy job

[BackupBytesTim]

It probably sounds like I argue Veeam's company structure quite a bit, but I really hate seeing "lack of QA resources" as such a common explanation for things not being developed. I've talked to a lot people (myself, my coworkers, other company's people) and lots of us agree V12 is the buggiest release in a long time, so it seems like the existing "QA resources" are not being used, since so many things seem to slip past, so it's like... unless I'm totally misunderstanding what your "QA resources" do, it seems from my perspective the QA team is not testing everything before it goes out, so it doesn't seem like it would matter if there's QA people available or not since things get released untested anyways. Either that or they're just missing a whole lot things.

Unrelated to that, because that's ultimately more of a company structure and management comment, not a development or technical comment, I do have a more technical question just trying to understand your statement about it being complex.

What's different about copying a copy vs copying the original? Since we can copy the original (creating a first copy) what is so different about being able to make a copy of the copy (a second copy)? It seems like it should be the same logic involved in the actual copying process and so all that's different is the UI for selecting what to use as the source for the copy.

Note, I'm really not trying to say anything negative here, just trying to understand what the reasoning is. As both a developer and system administrator I really can't accept "it's complex" as a explanation for anything.

[Gostev]

Tim, if you don't want to accept "it's complex" as a explanation, then you're more than welcome to do so. We just tell you how it is, however there's really no goal to convince you or anyone else about anything here. It never was, because it's usually impossible no matter how much effort or time we put, especially when it comes to "both developer and system administrator" type of folks who I've met too many in 15 years of leading this community...

Besides, if you really are an experience developer, then you'd agree that providing a detailed reasoning to someone not involved into development of the actual product and thus having zero knowledge of the architecture, dependencies and all other considerations is simply unviable over forum posts. And more importantly, it won't change anything. As such, there's simply no good reason to be "getting to the bottom" of this, regardless of anything else.

Especially since you admitted earlier it does not affect you personally, so clearly your only goal here (and in most other topics lately) is to "not say anything negative here", as the beginning of your previous post clearly demonstrates so really, let's just move on and stop wasting each other's time. And perhaps switch to a more constructive feedback matching the actual purpose of this community, as opposed to rant and demands for detailed explanations of man hours estimations by our R&D.

[Gostev]

just challenging that statement:
why not go for providing optionality between legacy and new backup copy architecture/chain format? That way, the new backup copy architecture can still go forward without infrastructure objects and customers heavily leaning on this ability can agree on limitations legacy chains and copy job architecture will bring.

That would mean having to maintain and test two different "tunnels". This is always a bad idea, as our R&D resources are very finite. More importantly, the very goal of Backup Copy rearchitecture was to get rid of the "legacy" tunnel, which kept generating extremely high support load.

I would not heavily argue that this functionality should be brought to the new copy job architecture, but i would argue for a better way of phasing this functionality out.

I totally agree with you here. Frankly speaking, it was a simple decision to postpone this functionality after we saw R&D estimations on porting it to the new Backup Copy architecture, and how many deployments are actually used this functionality. Now, if support big data instead showed us that it is a heavily used feature, then of course we would approach this very differently.

[Seve CH]

Hi Gostev

Big data is nice, when you have your data. Any company with a decent system administrator blocks internet access from the backup infrastructure and indirectly telemetry. In any case, I always block telemetry anyway.

You may have survivorships bias. https://en.m.wikipedia.org/wiki/Survivorship_bias

Your big data learnt about our setup when Veeam didn't test vSphere Tag to credentials mapping before release, and updating to v12 broke our system. This is a product functionality which should be relatively easy to test and automate.

Now we are running on a private fix, we cannot install the latest patch (the bug is still there) and we have 2PB data in a legacy backup copy job we should somehow migrate without screwing the backup chain.

Had I know what was coming to us with v12, we would have remained on v11. What I know, is that the next Veeam update will deserve a lot more scrutiny and testing on our side before updating. This means that if a test environment must be built to validate every single functionality we use, we may as well evaluate other solutions at the same time.

Best regards
Seve

[Gostev]

Hi, Seve. Actually, our support big data does not require Internet access, it's built by automatically analyzing the debug logs package submitted with support cases. And since almost all users open support cases at least once every few years, it's gives us a very good idea on how popular this or that feature is.

I agree with you that this change should have been communicated better, especially since V12 setup program added new functionality where it checks on very many things impacted by upgrade and warns about them. I'm surprised this particular change was not included there, as it's a trivial check to see if any there are any Backup Copy jobs set up this way - but I guess mistakes happen and things get overlooked...

Thanks

[depps]

Skim read all this and don't understand how our use case works with this new backup copy job.

How do we selectively backup-copy 5 machines only to a cloud repo?

I've just collapsed our jobs into a single job and it would seem I have to now create a new backup just so I can only copy 5 required machines to a cloud repo?

Or can I tag them?

Or can I continue to use the legacy method which is now throwing "04/12/2023 12:31:51 :: Legacy backup copy jobs do not support new backup chain format of the source backup. Please recreate a backup copy job and map your existing backup files to the new job."

[emachabert]

If you update the source backup chain format your backup copy job in legacy mode won't run anymore as per the message you did paste.

For the moment, if you want to copy only 5 VM. In the BCJ Include using the backup job (or the repo) and then exclude all the VM you don't want to copy.
When doing the exclusion, look at the offered options and choose the one that fits best your context.
https://helpcenter.veeam.com/docs/backu ... ml?ver=120

[michele.berardo]

Just a simple update, do you think honestly, this feature will come back again in the future releases? We have a lot of customers based on that and we are trying to re-think about all Backup Copy processes, but it's a very waste of time and not always we are able to obtain a satisfactory result. For example, in pre-v12, selecting VMs by tag, you could select the "source" of the Backup Copy, and that could be a remote Backup Repository that you chose, now you cannot do anymore.

[squebel]

Hello,

It appears that we can no longer set a Backup Copy Job source to just be an individual vm? I'm pretty certain that in previous versions that picking an individual vm was an option but I do not see that any longer. Our only options now seem to be a source backup job or a repository.

I have simple backup copy job that is looking at a source backup job. I want to add a single vm to this copy job that is part of a different larger job. I do not seem to be able to find a simple way to do this.

[Mildur]

Hi Squebel

Please check out this topic where this option is already discussed.

Best,
Fabian