Veeam backup creating _# folders

[mradr]

Had this issue for a while across a number of devices. Far as I know I didnt make any changes that would affect them directly. Normally, I just reset the whole backup chain and it would be good for a while, but thats starting to become a pain point for me. I dont have a ticket just yet open, but wanted to reach out and see if anyone else has this issue and if there was like a command line method to maybe get this problem fix. I know people say its not a common issue, but I've had seen this issue through out past versions of the software and I do agree with others that this issue is a problem with the product on some level. Instead of making folders - I dont understand why I dont just get an error instead or have some type of "dont create _# folder" option. Seems like a weird way to handle issues.

[david.domask]

Hi mradr,

I would indeed get a Support case for this; this behavior isn't something you should be hitting frequently, and I'm doubtful there is anything specific you're doing that would trigger this, so I advise open a Support case.

Please be sure to export logs as per https://veeam.com/kb1832 and use the 1st option to select the job in question. If the Agent job is not managed by VBR, then follow the steps here.

Please post the case number once you have the case opened.

[danieledrago]

I am experiencing the same issue after v6.1 upgrade.
Almost all devices we manage keep creating new backup chains and the cause is the VBM file being locked by other devices running their jobs at the same time. I have never seen this issue before. In fact, downgrading to v6.0 seems solving the problem.
I have a case opened.

[david.domask]

Hi Daniel,

Welcome to the forums and sorry to hear that you're experiencing the unexpected behavior mentioned in this topic.

Can you share the case number please? It's best to let Support check and comment on the locks as Veeam is aware of its operations locking backup file and other resources, so as long as you are not sharing infrastructure components across multiple VBR servers, Veeam operations should not cause such behavior.

[danieledrago]

Hi David,

sure! My case number is 07174391.

[david.domask]

Hi Daniel,

Thank you for sharing the case number. I do see the Engineer is engaging additional internal resources for this particular case, so let's allow them a little time for an update on this one while they confirm the reason for this behavior. I know the case has been opened for a bit, so your patience is much appreciated! The engineer is engaging the appropriate internal persons as I see it so let's wait for their update.

[danieledrago]

Hi David,

thanks for confirming. I replied to this topic because it was the first time I read someone else was experiencing the same issue, and I was starting to think I was the only one.

[mradr]

You are not, there has been many times I've seen the issue across a number of devices over the years. Most of the time people just recreate the chain and move on. I still need to make the ticket my self, but I can assure you are not crazy and not the only one lol. Most of the time people just wave off the issue. To me, I figure they just had a bad string of the issue and would be fix over the next few versions, but I have never seen the fix come.

With the said, David, if I can ask before anything else, why is it doing this in the first place? I understand you will need the logs, but that doesnt explain the idea behind the logic it self in why the application does this behavior in the first place?

[david.domask]

Hi mradr,

Without the logs it won't be possible to say specifically why it is doing it right now; there are a few reasons why this may occur, the one that comes to my mind is that the job cannot "find" the backup and decides to create a new one even though the previous backup exists. When trying to create a new folder, the number gets appended as there is an existing folder with the same name.

To reiterate though, this is just one situation, and it doesn't explain why there is a discrepancy between what Veeam "finds" and what's actually on the repository, so it's best to let the Support Team check the logs

[mradr]

David,

No I totally understand that, I am just questioning the "why" make the extra folder half - as to say, even if it can't find the correct path, why is the behavior to create a new or append to the end path? Shouldnt we just get an error in the form of "we see the path exist/doesnt exist, but unable to access the correct files"? I assume each device that runs into the issue maybe similar or different, but going above that, shouldnt there be a way to turn on a setting like "dont create new folder, return error instead" option?

Do forgive me, but I just havent had much luck with support. Always came down to just "reinstall" or "delete and start new", so to me, the issue is more in the behavior is why I am pointing this out more than the other.

[danieledrago]

I totally agree with mradr when it comes to the ability to return an error when the current chain is inaccessible. Even better, I would make it the default behaviour.

[david.domask]

mradr,

I can understand a bit of hesitation, and there's no harm in asking for a Root Cause Analysis on the case in addition to a mitigation/workaround. It's in everyone's interest to ensure that you're not having to deal with this regularly, so if you're willing to open a case, please share the case number and we'll monitor and see what might be causing this in your environment. I would be more specific if I could but as I mentioned, there are a few rather different reasons this might happen.

I'll discuss your request on making this a failure instead of continuing as I can understand extra backup chains are not desirable as a result of an error.

[mradr]

Thanks!

I know there is a root issue as you point out, but as you said, I would prefer a different desire out come for the issue than just make a new chain/new folder is all I wanted to point out, so thanks for listening on that matter.

I did open a case finally and just waiting to see what they say for now.

[danieledrago]

I have just been informed that this behavior will be fixed in the next release.
In the meantime, the suggested workaround is to downgrade the backup agents to v6.0.2 or to change the backup schedule so that jobs don't start at the same time.

[david.domask]

Hi danieldrago,

Thank you for the update and glad to hear we have a confirmation of incorrect behavior. The workarounds naturally are correct, and the behavior (696533) is scheduled to be corrected in an upcoming release, so hopefully the workarounds are sufficient for now.

[mradr]

Any ETA then on the next update? Base off current, it might be a while?

[david.domask]

Right now can't be more specific on the release dates, but stay tuned. You can add our KB RSS Feed to your RSS reader of choice (many mail clients have one now) and you'll get up-to-date notifications on new KBs including release announcement KBs.