Disconnection problem using CIFS

[Websterm]

Hi,

I have this problem when i do backups to a DR4100 using CIFS. The problem is that sometimes it works and sometimes don't and happens with different VM's. Already have a ticket open (00622480) since august 18 and until now no resolution

Client error: The specified network name is no longer available.
Failed to write data to the file
Exception from server: The specified network name is no longer available.
Failed to write data to the file
Failed to perform data backup.

.The environment have
-vSphere 5.5 with a database in a physical Oracle
-Veeam 7 with Patch 4 with three proxies for backup, the Veeam itself and two more proxies
-Database is in a SQL Server 2012 VM

.The configuration is the same as in this doc: ftp://ftp.dell.com/Manuals/Common/dell- ... _en-us.pdf

.Already tried tho change every possible configuration in the jobs backup, including running a single job to avoid high workload on DR4100

.The same happen to a DataDomain using CIFS

.It works presenting a NFS to ESXi then presenting the disks to the VM's and doing a disk pool on windows to have a single 73Tb disk (because VMware max is 62Tb). The problem with this option is that is not possible to the DR4100 replicate the content to another site after windows format the disks

.Tests were made in Windows 2008 R2 and Windows 2012 R2

.No problems found on Veeam VM or proxies Event Viewer

.All security GPO were removed from proxy VM's

Thanks

[Vitaliy S.]

Since you've tried every possible configuration (using different proxy servers, backup modes), then I would suggest looking into physical switches that your repositories are connected to. Also have you considered using Backup Copy jobs instead of using hardware replication between these boxes?

[Websterm]

Thanks

I'll take a look in the switches, but what i think is strange is that using NFS connected to ESXi works and the only change from CIFS to NFS is done in software.
From what i read everywhere this error happens because the repository is too busy
I was hopping that someone with a similar configuration and have it working without a problem could help

[Vitaliy S.]

Yes, you're right, that's strange. On a side note, I'm not familiar with this device, but it does it have any firmware installed? Can you check if any updates are available for it?

[Websterm]

It's updated, because I have a ticket open with Dell too and they updated both local and remote storages
We were doing more tests in here and without parallel processing apparently there is no errors, but the backup is extremely slow (have to stop after 40 hours of backup)

[tsightler]

You might want to try throttling the traffic to the CIFS server. In the repository settings there's an option to limit the combined data rate. Try taking the maximum data rate you've seen when running backups and throttling backup to 80% and see what happens.

Another option would be to export via NFS and use a Linux server to mount it. Then you can add the Linux server as a repository, but you would need a Linux box on the other side to access the replicated data.

[Websterm]

Great, i'll try the throttling option but it take some time because the problem is totally random

When i retry the job manually sometimes i have the error again and when retry again it finishes without a problem. If there was a option to automatically retry the job in this type of error would be great, but when the connection is lost the job stops immediately for all VM's and the retry option don't work

Thanks

[Vitaliy S.]

As far as I know job retries should handle any error that happened during backup job run. What timeouts do you have for a retry option?

[Websterm]

Sorry for the delay

Don't know why the retry is not working when the error is "The specified network name is no longer available"

The answer i've received from support is to use another way to present the DR4100 to Veeam that is not CIFS, because Parallel Process is inconsistent with CIFS
Don't know what to do now, because using NFS will not work because DR4100 cannot replicate after windows format as NTFS

Thanks

[Vitaliy S.]

Reading back through my answers above, could backup copy job be a replacement for the built-in DR4100 replication mechanism? In this case you could have a reliable backup job target and a copy of backup files in the remote location.

[masonit]

Sorry for the delay

Don't know why the retry is not working when the error is "The specified network name is no longer available"

The answer i've received from support is to use another way to present the DR4100 to Veeam that is not CIFS, because Parallel Process is inconsistent with CIFS
Don't know what to do now, because using NFS will not work because DR4100 cannot replicate after windows format as NTFS

Thanks

Who said parallel process is inconsistent with CIFS? Dell or Veeam?

\Masonit

[Websterm]

Vitaliy
I'll see if i can do this, but my boss will not be happy. Both DR4100 was bought just for this and didn't saw nowhere in documentation that CIFS would be a problem with parallel process. Thanks.

masonit
Veeam support told.

[emelloul]

Just wanted to post some information on this... we have a customer running into the same issue with one of our customers and the DR4100. The max number of CIFS connections is 32. If you have other devices that are writing to the device with CIFS that would chew up the number of concurrent connections - this also applies with Veeam and the number of proxies that you're using. The other issue is that NFS has the same limitation. That being said, it's a limitation in the software that causes this. We're a Dell Premier partner, and from our conversations with Dell, it looks like the virtual appliance does not have this issue (supposedly) and can replicate from virtual to physical. The downside is you chew up a bunch of either DAS, SAN, or NAS space depending on what your storage medium is. It's a frustrating issue we've been fighting for quite some time with no end in sight. I've also had the experience that rebooting the DR4100 fixes the issue but that's also not a solution. Do you have any other devices or backup jobs that are currently writing to the DR4100?

[jensenjk]

Any news on this topic , we are hit by it as well?

[foggy]

I cannot check the case, since it is in Spanish, but anyway, it was closed due to no activity from the OP's side. So I recommend opening your own case for investigation. Thanks.

[mfcit]

Any update on this issue? We are having the same issues with Veeam and a DR4100. Strange .... it just started about 2 weeks ago.

[foggy]

Nothing new since my previous post above. Please contact support directly.

[rborhara]

I am experiecing the same issue but i have a dell dr4000 unit as a backup repository
For around a year backups were running fine (active fulls) at full speed I have a 10gb/s dedicated san and dr4000 switch , however when it did the full once a week it took so long but never ever timed out
However since an upgrade to veeam 8 i reverted to forever forward incrementals and setup 7 restores points. its when the merges started happening on 2 of my backup jobs i decided to give support a call
After 2 weeks of rulling out hardware / dr4000 / network as the cause of the issues , i was told to use a Linux Server with nfs mounts but this got so messy as its a workaround and then i had meta-data ram issues i believe

so im back to cifs shares more backup jobs with less VM's i do still get a timeout on one of my backup jobs and have been advised to throttle the backup speeds , but when when full backups for over a year never timed out - surely its a bug in the veeam 8 merge process or a CIFS Timeout issus which ill set now

[Vitaliy S.]

Hi Rakesh, thanks for the post. Can you please tell us your case ID?

[rborhara]

Hi case id was 00980402

the way i have worked around this is create a lot more backup jobs that run once the previous one has finished.
I still have one job that failes during the merge, but on the retry it just works and complete the previous failed merge

[Vitaliy S.]

Glad that you've managed to find the workaround for this. According to forums search CIFS repositories may experience these kind of issues (due to much traffic or high I/O load), so it's better to use Windows/Linux repositories instead.