Backup of independent disks

[cloudgrid]

I recently had an issue where a customer deleted a vm because he thought that he had a valid backup of the vm. In fact Veeam did report successful backups. However restores did not work. Upon further investigation I found that the vm was inadvertently configured with independent disks. Veeam of course skipped those disk leaving the administrator with an invalid backup.
I would like to see backups of vm's that have independent disk complete with a "warning" instead of "successful". It is misleading to any administrator that is relying on those backups. Granted there are best practices to use to identify this as an issue but generally the administrator won't find out until it's too late.

[Gostev]

Most people specifically use the ability to mark disk as independent to easily exclude them from backup, so I know for sure that as soon as we make this a warning, we will have hundreds of annoyed customers come to the forum demanding to change this back

I am pretty sure though that Veeam ONE infrastructure assessment report already points out all VMs with independent disks. And this report is included in the Free Edition since we want our partners to use it before implementing Veeam Backup & Replication.

[cloudgrid]

Backups are critical wouldn't you agree? Based on that, I don't know anyone that would call it a bug when you are "warned" that your data is not being protected. Backups receive a warning when cbt is not available, I think this is at least as important.
Please re-assess your position and review it with your other engineers.

[Gostev]

Just trust me on that. We've spent last few years removing warnings from the product and reclassifying them into info events based on huge amounts of feedback, because people did not want to see the warning for irrelevant issues and known limitations. There was one event that we accidentally moved back into the warning, and we had a 3 pages long topic in a matter of a few week with demands to fix this. This is true! I can even try and find this topic

Now you are suggesting to change the current product behavior for based on single (sic!) request in 6 years that was caused by "inadvertent configuration" as you yourself put it. Imagine the impact this will cause on 90000+ customer base who do these configurations on purpose.

I do agree the backups are critical. And if your customer don't test their backups, they won't find out about another hundreds of possible recovery issues until it's too late... healing one symptom is okay (as long as this does not impact the user base), but this is still largely useless because instead, what you need to heal is the cause. And the root cause for this issue is that this particular customer has never ever tested the backups, which is totally against standard data protection practices.

Again, I am not saying I disagree that some customer with certain approaches to managing their backups will benefit from this feature. I am just trying to show you the bigger picture, and what other things I need to consider. We are working on v8 product with the largest customer install base in the world as it comes to VMware backup, not some v1 version with a few beta users... this severely limits us in what we can change without getting 10000 support cases the next morning.

[cloudgrid]

I fully realize the scope of the impact which only strengthens my point. Any time a customer's data is potentially not being protected they should be warned. It is just that simple. All the rest is just not relevant. Please review this request with your managers.

[Gostev]

Consider the last part done, as I am the Vice President of Product Management, ultimately responsible for the feature set and behavior

I did some digging, and found that we have specifically converted warnings on skipping unsupported disk types (such as physical RDM disks) into the informational events a few years ago based on the multiple requests from our users. The reason was that they realize we do not back those up as per System Requirements, so they take care of them differently, and do not want Veeam jobs throwing the warnings every day when all supported disks are backed successfully. So obviously, we cannot enable warnings back based on the single request for the opposite behavior.

I am still open for any other ideas on how we can address your request without introducing the behavior that major part of our user base specifically requested to be removed.

Perhaps we can find some middle ground, for example the warning is only displayed when the VM is backed up for the very first time (first full backup). This way, the change will not affect any existing jobs.

Thank you.

[tsightler]

I remember back when this was a warning and I think the reason it was an issue is that there was no method to disable the warning, so for VMs that had disks configured this way intentionally (for example perhaps with databases that are backed up via other methods) then you'd get the warning forever which was not good.

If it were up to me I'd probably make it a warning until the administrator explicitly excludes that disk from the job. This forces an administrative decision to get rid of the warning and thus hopefully make the correct choice of whether the disk should actually be excluded or not, but then will still catch new VMs that are added later that were perhaps configured this way my mistake. I understand users might not like that, but they also don't like it when they unexpectedly don't have a backup, and that second scenario is far worse because at that point you can't do anything about it. Then again, I'm exceptionally conservative when it comes to this because I used to be an admin.

[dellock6]

As a data protection admin with more than 1000 VMs, I was happy when the warning was converted into an info message. There is no way inside Veeam to workaround the limitations of VADP about backing up independent or pRDM disks, so imho there is no point in getting a warning about it.

To, me there are two things we could do: first, obviously is reading the manuals, and understand the limits of any product we use

In addition, I remember there was a small discussion sometime ago about a possible feature, that is DRY RUN. When a user creates a new backup, it would be nice to have a way to simulate the backup operation without moving any data. In this way we could have a nice report of the expected result of a backup job, with informations like number of VMs, used space, and another info in the report could be the disks that cannot be saved. A good place to insert this report execution would be at the end of the creation wizard, alongside with the "run now" option.

I already know there is a flaw here: if the job uses dynamic containers (like datastores, resource pools or the like) a new VM added at a second time would not be included in the report...

Oh, and obviously there are the Veeam ONE reports...

Luca.

[Gostev]

My proposed solution will solve the dynamic container issue. Each time the new VM falls into the job's scope, we will warn ONCE (during the very first full backup) that it has some unsupported disk types. And you will never see this warning again for that particular VM, at least until it has a change in virtual disks configuration.

This also means you will not get any warnings on your existing jobs after upgrade, because all those VMs already have full backups created at least once.

[dellock6]

What about users not enabling email reports? It will appear as a warning inside the console on the first run, and then it will switch to an information event, correct? Well, it could be fair. If you are the backup admin, you are supposed to check your backups, either via email reporting or by opening the console every morning.

[Gostev]

Correct.

[veremin]

Additionally, I've written previously a script that gets list of VMs included in the job and check in vCenter whether or not these VMs have independent disks; might be useful. Currently, it works only if the VMs are added as individual objects, though, it can be modified easily, if need be.

Thanks.

[vMO]

got the same request recently. what about adding a RegKey for enabling that warning?

[Vitaliy S.]

Just to re-iterate what Anton has said above - why not to use VM configuration assessment report in Veeam ONE that would give this info even now and out-of-the-box? I believe it should address this issue.

[masonit]

Hi!

Just tried to backup a vm where i got this error. Veeam skipped backup of the entire drive. I understand why it doesn't work but I don't understand why Veeam says that the backup is successful! This can potentially be a really big issue where you think that the backup is fine when it really isen't. Is this expected behaivour?

\Masonit

[veremin]

Hi, Magnus,

Please, see explanations provided above about the reasons why backup of VM with independent virtual disks outputs warning, instead of error.

Thanks.

[masonit]

Hi, Magnus,

Please, see explanations provided above about the reasons why backup of VM with independent virtual disks outputs warning, instead of error.

Thanks.

Thank you v.Eremin! Veeam doesn't output a warning. It says OK..!

Well this is a no brainer. Anyone that has ever been responsible for a backup system knows that these kind of "bugs" are the worst. I just found out that Veeam didn't backup a 1 TB disk without saying anything!
If you don't want to enable errors for this. Atleast make it possible to turn this on in registry as vMO said.

What more of these kind of errors are not reported? And that Gostev laughs at this as it is no big deal... ...

\Masonit

[Vitaliy S.]

Hi Magnus, registry key as well as Veeam ONE Free Edition report can be a solution here indeed. Thanks for your feedback.

[Gostev]

And that Gostev laughs at this as it is no big deal... ...

Sounds like you did not read any of my posts beyond the smiley face then... because I have recognized the issue with this approach for certain type of customers, and proposed some ways to address it without impacting existing users. But there have been no feedback on my proposal over the course of many months, perhaps because only a handful of people actually consider this to be an issue...

Again, these disks were reported originally, but this reporting was removed based on large amount of feedback. We don't disable existing and working functionality unless there is a big push from our user base, trust me. This is why I need to find a solution here that will not impact existing users who are happy with (and asked for) the current behavior.

[masonit]

Or maybe just a handful people have found out..

Ok sorry maybe I overreacted. But you must realize that this could be a huge issue for some. We backup alot of different virtual environments. Some of them the only access we have is through Veeam. We are not admins and don't monitor them so the only information we get is through Veeam. Then Veeam doesn't report these drives is not good...

Any news on the possibility to choose if this should be a warning or not?

\Masonit

[Vitaliy S.]

Nothing has changed, but as a workaround for now, you can use a nicely formatted report to assess every VM configuration (not only for independent disks, but for pRDMs and other potential issues) that is available in the free version of Veeam ONE.

[masonit]

Nothing has changed, but as a workaround for now, you can use a nicely formatted report to assess every VM configuration (not only for independent disks, but for pRDMs and other potential issues) that is available in the free version of Veeam ONE.

Does Veeam One retrieve this information from Veeam or from Vmware?

\Masonit

[veremin]

Information about vSphere infrastructure is retrieved by Veeam ONE directly from vSphere. Thanks.

[masonit]

Information about vSphere infrastructure is retrieved by Veeam ONE directly from vSphere. Thanks.

Ok then Veeam One is not a good option for us. I really hope Veeam can tell us this instead in a near future..

\Masonit

[Vitaliy S.]

Does Veeam One retrieve this information from Veeam or from Vmware? Ok then Veeam One is not a good option for us.

I'm a bit confused with your question, what do you mean by saying "retrieve info from Veeam or VMware"?

[ramnefors]

I have a few VM with independent disks that should not be backed up. In v7 these VM showed "green" now they show "yellow" with a warning that there are independent disks on these VM that are not backed up.

As this is intended how do I get back the v7 behavior, i.e. no warning?

[tinto1970]

I think it's intended and it's a good idea.

[Gostev]

Perhaps we can find some middle ground, for example the warning is only displayed when the VM is backed up for the very first time (first full backup). This way, the change will not affect any existing jobs.

My proposed solution will solve the dynamic container issue. Each time the new VM falls into the job's scope, we will warn ONCE (during the very first full backup) that it has some unsupported disk types. And you will never see this warning again for that particular VM, at least until it has a change in virtual disks configuration.

This also means you will not get any warnings on your existing jobs after upgrade, because all those VMs already have full backups created at least once

This functionality has been added into v8. Thanks all for your feedback!

As this is intended how do I get back the v7 behavior, i.e. no warning?

So just as I predicted on the previous page of this topic, first complaint about the warning just a few days after release
But don't worry, you will only see this warning once, when creating first ever restore point for any VM (see quote above).

[averylarry]

I have a VM with a bunch of virtual disks that are explicitly excluded from backup (Virtual machines, Exclusions, Disks tab). They are also set to be independent (cannot snapshot).

These disks are generating a warning message from the Veeam backup job.

"Disk 'win2_1.vmdk' has been skipped due to unsupported type (independent)"

I would suggest that this shouldn't be a warning, since the disks are excluded.

Independent disks that are not excluded should generate a warning.
Independent disks that are excluded should not generate a warning.

[Vitaliy S.]

Hi Ted, please take a look at Anton's response why and how we have adjusted notification behavior in v8.