Network backup fails following Event ID: 50 / Source MRxSmb warnin

I have a Win Server 2003 Std (x86) SP2 machine which refuses to backup over
my network.

It is a Dell Poweredge 1850 machine plugged into a Gigabit ethernet switch.

Everytime I try to run a backup to our dedicated backup staging server
(which it has been doing happily for several years) it now gives me a Warning
message in the System log with ID 50 and Source MRxSmb. This then results in
the ntbackup failing.

The full error is:
{Delayed Write Failed} Windows was unable to save all the data for the file
\Device\LanmanRedirector. The data has been lost. This error may be caused by
a failure of your computer hardware or network connection. Please try to save
this file elsewhere.

I have 4 other servers still happily backing up to the backup staging server
so believe the problem does lie with this particular server.

I have tried various things fixes including:

* Rebooted
* KB890352 hotfix (didn't install because my SP supersedes this hotfix)
* http://support.microsoft.com/kb/304101/en-us
* http://support.microsoft.com/kb/106167/en-us
* Uninstalled NIC & reinstalled.

None of this has resolved the problem.
Can anyone else help?

I have the same problem in our environment.
We use Acronis as backup tool and the same errors happen when running a
backup via the network to a backup server.
There doesnt seem to be a logic in it because it happens radom on some
servers some days, some days not.

Also W2k3 SP2 but on Fujitsu RX300 hardware.

Sorry, don''t have the solution but wanted to share thoughts

Some Questions:
- When did the error start? after SP / hotfix / update driver?
- What is the NIC brand type of server and also the nic of backup server?

I was having similar errors in my development network when perfoming automated scheduled backups that ran overnight.

Event Type: Warning
Event Source: MRxSmb
Event ID: 50
Description: {Delayed Write Failed} Windows was unable to save all the data for the file \Deveice\LanManRedirector. The data has been lost. This error may be caused by a failure of your computer hardware or network connection. Please try to save theis file elsewhere.

Event Type: Information
Event Source: Application Popup
Event ID: 26
Description: Application popup: Windows - Delayed Write Failed : Windows was unable to save all the data for the file \\ServerNmae\VolumeMountPointName\FileName. This data has been lost. This error may be caused by a failure on your computer hardware or network connection. Please try to save this file elsewhere.

Knowledge base article 890352 sounded exactly like my problem and I tried the hotfix. I tried other knowledge base articles about using drive mappings instead of UNC mappings, I tried different network cables and network switches, swapped NICS, I tried all sorts of registry entry additions and adjustments, etc. I tried about everything I could find online and nothing worked.

What ultimately fixed my problem was turning off the poriton of my Symantex firewall on the receiving server that prevents denial of service and other network related attacks. It appears that the constant flow of data into the receiving server was being seen by the firewall as an attack, and Symantex stopped allowing the data transmissions, hence the inability to continue writing data, and write failures.

Now, for me, this was all within an isolated development network which really didn't need such heavy protection in the first place, so just turning off a portion of Symantex was acceptable. This might not be the case in a production environment or where the servers have connection to the outside world (where the attackers truely are). The one oddity that we have not been able to explain is why other machines in our network which also backup to this same server were able to write their backups without error. We got it working and sort of stopped looking due to other priorities.

My network consisted of several MS Windows Server 2003 servers (web, DB, application servers, domain controller) with about a dozen development workstations all networked in. The servers all backed up to a central terabyte disk volume that was installed within the domain controller. Each server had a once weekly scheduled backup job, using the built in NT Backup utility, that wrote to the terabyte volume using UNC pathways.

Some fellow developers helped diagnose this by using pings with max packet size. The delayed responses to the central backup server, but successful pings from the individual servers to themselves using their external IPs, helped to show a general problem with large continued data flows to the central backup servers.

ping -h (to see all the options)
I think we used something like ping -n 10 -l 65500 remoteBackupServerIP
and ping -n 10 -l 65500 localServersExternalIP

I spent wasteful weeks on this issue and hope this might give an additional avenue to pursue.