Not really a Question, just sharing and curious if anyone else has thoughts on it.
In my experience Veeam’s Support asks for incredibly excessive data, asking for the same logs over and over, asking for logs that don’t seem at all related, and asking for copies of databases on VBR servers.
Some other people have shared privacy concerns with me about the behavior. Personally, I’m not fond of it, but accept it as a cost of using Veeam.
From my perspective none of this should be necessary if the software itself was:
A, less buggy to begin with.
B, had actual useful error messages so I could tell what the problem was without involving support.
C, had actual useful error messages so that Veeam’s support could tell what was wrong.
Noting B and C are different because I can accept that Veeam’s support may know more than me about what an error message means. Though if B and C are different, then it’s a good time for me to mention that Veeam needs to publish their “internal documentation” publicly. Keeping secrets about how to fix things just adds to my following negative impression of Veeam’s support…
It really seems Veeam’s software is designed to be unreliable and hard to fix on purpose, so that people need to contact support regularly, so that people need to pay for support, and so that Veeam can get their user data collected.
It does generally seem like it’s a corporate decision made by some upper management level, not the actual development team or support team that’s causing the problems, but I’ve had bad experiences with Veeam’s Support from my first week, and not much improvement anywhere.
Even me doing something as simple as asking what an error message means apparently requires log files from the agent, relevant VCC infrastructure, and additionally the VCC database. Which tells me the development team failed to have an actual useful error message, if it’s so vague that all that is actually needed, then that’s a serious failure on the development team’s part.
My experience with literally every other application or service I’ve literally ever used in all my years with IT services is that error messages either state what the problem is, or at least have enough information to find a relevant KB article or something about it, better even a link to said KB article.
I understand not every possible issue can be accounted for, but I open support cases and/or forum posts every week with Veeam, often more than once a week, for new problems. Whereas with other software I’ve used things for years and never contacted support once.
From my perspective every support case starts with the development team, not because I contact the development team first, but because the development team failed to release working software and/or include useful error messages.
I have plenty of issues for which no error message is given anywhere at all except buried in the log files.
I do also find it incredibly annoying when support reps ask me to upload logs that I already uploaded again and again. Especially troubling when they claim they need me to upload logs again because they can’t see the logs I already uploaded. Like, I can see them, they’re there. I can download them, I can view them fine. So unless someone tells me a different way to collect it or upload it from what I already did I just ignore them now. No reason for me to do the same thing over and over again just so Veeam can spy on me and my customers.
And generally I disapprove of this behavior of gathering user data for spying on customers via support cases. I am thoroughly convinced that’s why logs are required for all support cases, and why support reps are always asking for the same logs over and over again.
Again, not alone in these thoughts, I’ve had discussions with other users in my company and at other companies about this. Thought I’d ask in a slightly more public place if anyone else has thoughts on it, particularly the “spying on users via support cases” part. Which seems like a generally shady business practice, and seems to directly cause issues where I spend days providing support information that should in no way be required to answer simple questions.
Excess Support Data Collection for Analytics and User Data Collection
+7
- Ask the Veeam Community, there are lots of experts and Veeam employees for helping you here.
- Ask R&D forum as well.
- Ask the Veeam support to escalate yours case if he can’t solve your issue more than 3 days.
- You also can contact with support manager in the support ticket portal if the Veeam support engineer cannot solve your issue.
Btw, I believe if you have any concerns about logs, you can send the basic support logs or ask for scheduling remote session to help you.
Most of Veeam support engineers are very good but, maybe they are too busy sometimes.
Hope these information helpful.
I can appreciate some of the concerns you’re having, though a few points.
- For sure, there is no directive for excess logs for data mining purposes. The data policy is outlined here: https://www.veeam.com/privacy-notice.html Logs are collected for troubleshooting purposes only within Support
- Log requests may be repeated or Support may sometimes ask to recollect logs after a specific change is requested in order to review either why the change didn’t have the intended effect, or sometimes to capture the behavior in question with extended logging, etc
There are times when as per our data processing policy the logs may get expired (e.g., logs are purged as soon as a case closes automatically, logs can’t be “moved” from one case to another, etc), but as long as a case is active it should be accessible. If you could DM me case numbers where such an explanation was given, we can look into it.
Regarding the errors, I do understand the frustration and the desire to be able to solve the issues more readily yourself; we do publish as many KBs for common issues as we can for Veeam specific issues/errors. What often is the case though is that for the most difficult to troubleshoot errors, the failure isn’t coming necessarily from Veeam code, but from non-veeam infrastructure elements (e.g., network, OS permissions, fw/av, etc) and the errors are not always the best. A classic example of this (and this is not throwing shade on our partner) are VDDK errors -- if you’ve dealt with VMware backups, probably you’ve seen VDDK 13 at least once and there are _dozens_ of potential solutions that any backup vendor will list for VDDK 13, and each one _might_ be valid depending on the circumstances leading up to the error.
Log requests are never meant to frustrate and they’re never meant as busy work; if there’s ever a question on why we’re collecting additional logs, there’s no harm in just asking a bit on if there’s a specific goal for the troubleshooting process, the Support Engineer will be happy to explain.
But it’s not for anything else except troubleshooting.
> I have plenty of issues for which no error message is given anywhere at all except buried in the log files.
Share some examples please -- I can understand where you’re coming from, and as noted we’re not shy to request KBs or even try to improve the error handling on specific events if it’s wide enough spread.
Replying to some points one at a time…
1 and 2. I’ll admit I haven’t been terribly active on these forums, I’ve been quite active on the R&D Technical Forums, typically opening a new topic or appending an existing topic with every case I open. In my experience, while they don’t really do much “troubleshooting”, the Veeam staff there are much more helpful than support in knowing how things work and explaining it to me, which has on plenty of occasions enabled me to resolve an issue by myself before support ever finished reviewing the logs.
- In my experience an escalation basically starts the case over, asking for new logs, asking me to try any of the same steps again, and while it did help one time, often takes too long and I get the issue fixed myself separately by the time anyone does anything. But I supposed I can try doing that more often, maybe I’ve just had bad luck with it the few times I’ve manually escalated a case. Typically when I request a case be escalated the support engineer wont’ escalated it right away, they ask me to test some things and gather some extra logs first because the R&D team is busy and they want to be sure it should be escalated first. Which has literally happened when the R&D team on the forums directed me to escalate it. Unfortunately this behavior added to my impression that support and R&D are essentially two separate companies, who don’t really work together and don’t have the same policies or procedures for things.
4. Wouldn’t that be the same as requesting the case be escalated? That’s the only time I’ve ever done that.@ddomask
- Well, maybe they are collected only as needed for support, but per Gostev on the R&D forums they are definitely also used for user data mining for analytics, so…
- Someone on the R&D forums, who I do not remember now, explained that every request for logs should be explained by the support engineer requesting it. Which only seems to happen maybe 10% of the time. Again, makes me think the support and R&D teams are completely separate and don’t communicate with each, so neither side really knows what the other is doing or how things work. But regardless, I definitely do not get explanations for the requests the vast majority of the time. And except for cases I mark as Severity 1 I don’t typically have the patience to wait around for another back and forth exchange to ask why they’re needed before I just go ahead and send them. So typically I just go ahead and send them. Except for the last few cases where I’ve just had basically no patience because of how many things are broken right now that I’m working on fixing.
As for the rest, here’s the last case where I just gave up trying to provide the logs. I provided everything I could think of, including the VCC logs. Those I uploaded via the SFTP server, and indicated such in the case. Not sure if that’s still accessible at this point, or if the other logs are still accessible, but regardless… after uploading everything the support engineer indicated more was needed. No reason given, just more was needed. Specifying the “Service Provider’s Veeam Cloud Connect console” logs, which I thought I uploaded. I mentioned what I collected for the logs, “all components”, including the “target repository”, which was specifically requested by the engineer. After that the engineer started referring to the “target agent”, which I’ve never heard of, so I assumed that was supposed to be “target repository”, if I’m completely misunderstanding something and there is some sort of “target agent” that I’m not aware of, let me know, cause that was definitely not explained to me at any point. The engineer gave a link to a KB article with specific directions on how to collect logs, which is exactly what I did. So, again, lacking any directions on how to do it differently than what I did, I saw no point in redoing the exact same steps again just because the engineer claimed the logs weren’t there.
Case #06352810
As for KB articles, it’s been mentioned to me that Veeam has separate (non-public) documentation/KB articles on problems and what can be done to solve them, which sounds to me like something that would only be done to force customers to rely on support. Which as an IT professional, especially as a service provider these days, I disapprove strongly of. I’ve literally never contacted any company’s support as much as Veeam, ever, like all my non-Veeam support cases combined do not even come close to how many times I’ve had to contact Veeam for things.
And I do understand some error messages being recorded in Veeam’s logs that are not generated by Veeam’s software, but in my recent specific instance of a “corrupted file”, it definitely appears to be coming from Veeam. The first occurrence I sent to support was here: #06387894 though my latest support case seems like it may be the same issue, though with some slightly different behavior. I’m thinking the main issue with not showing an error is because the VSPC doesn’t seem to actually monitor cache sync jobs, though I’ve had at least one computer where the backup job showed as “Running” when the cache sync was running, but gave no errors from the cache sync job, so I’m thinking that’s a fluke, the other jobs with cache syncs that aren’t completing are not showing anything in the VSPC, not even that they’re running at the time when the VCC console shows they’re running. But I’m thinking the main issue is the error occurred in the cache sync job, which is like being treated as a completely separate thing by the agent and so the VSPC isn’t even aware it’s happening.
This sort of disparate separation of different aspects continues to add to my impression that different Veeam components are developed by different teams that only do the bare minimum to make their things work together, so it’s hardly one unified “Veeam suite” it’s more like “a bunch of different products with the Veeam name on them that may or may not work together”.
Admittedly, while I have a good deal of knowledge of VMWare’s software, I actually have only worked with it very little. The majority of the customers at any of the service providers I’ve been with use primarily Windows Server and Hyper-V. But I do understand what you mean about there being multiple potential solutions, it can be challenging sometimes to know exactly what the issue is when it involves another company’s software that you can’t see the code for. However, the majority of my current customers, and all of the ones with this issue, are just using Windows Agents, so I’m thinking there’s very little involved that could be a non-Veeam issue, there’s no hypervisor, no VBR servers (except the VCC server), most of them don’t even have enterprise firewall hardware (a few do, but I don’t believe that to be related to the current cache issues I’m experiencing).
I’ll admit, I can accept the “we don’t collect logs except as needed for support purposes” even though they are used for analytics, but based on past behavior of unexplained repeated log requests (not just after trying something new to see what happens, even just right after I open a case, upload logs, the first thing I get from support is another request for logs, and I don’t mean the automated message), it seemed a good assumption to make.
Comment
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.