Symantec BE SR 2010 - problems manageing device/network connections

[PCJunky]

We have an inssue with Symantec BE SR where it seems to store its own profile for managing device and netwrok connections that pays no regard to what MS windows does and thinks, this manifests itself in various ways - for example if you setup a backup job and point to a device or network share it insists on a user name and password to store - irrispective of the fact that no security is required.

We get round this by typing anything in there to pasify it...

This works in a fashion but related to this we then have issues with the soiftware making an unnessisary amount of connections to the device, in many cases this is manifesting itself by simlpy crashing the NAS devices we use, or reacj=hing some sort of limit that prvent sysmantec from working - despite windows being quite happy and having no issues, here is a specific example:

MS Windows SBS Server 2008

Symantec BE System Recovery 2010

LaCie 2Big 2TB NAS drive.

The software is set to create a full system image of each drive on the server each night on the NAS drive (windows share) using the network path, not a mapped drive.

At the same time create a second image to a USB drive attached to the LaCie NAS via another share path (for a backup that can be taken off site).

In this particular installation it has worked foro many months without issue but now only works for several days then starts to fail with following error (see screen shot) until the server is rebooted, yet windows is stil able to browse to and write to the share without issue:
 

As mentioned above there is no security on the share so no authentication is required, but you cant leave that blank in the symantec software so we use the admin username and password for the nas and this has sufficed so far.

Can anyone shed any light on this please?

[Sush---]

If there are multiple connections to the destination server from the BESR server, Edit the job settings and Add the destination using UNC path and not the network share name.

Refer to the following technote

http://www.symantec.com/docs/TECH142836 : When the Backup Exec System Recovery (BESR) backups are targeted to Network Shared folder or NAS device the job fails while trying to connect to the destination.

Another recommendation would also be to check and update the firmware of the destination device.

Thanks,

-Sush...

[PCJunky]

Hi,

Thanks for the responce and link.

We do always use a UNC path and not a mapped share, the paths used are:

To the NAS - "\\NASBackup\Backup\Server\"

To the USB drive on the NAS - "\\NASBackup\DriveC (esata)\backup\"

So I don't belive this is the issue, having rebooted the server last night it is now working again as expected, I will monitor and update this post when it starts to fail again to give an idea of time scales.

The NAS is on the latest firmware version.

My main concern here is that we have many customer backup solutions we have supplied that for the most part are based around a backup application backing up across a LAN to a NAS drive and so use a UNC path (this doesn't seem to be an issue if we are backuing up to a USB device attached directly to the server).

Of all the combinations of software we use, and differnet makes of NAS drive, it is only the symantec software that is having these issues, which based on my findings so far seem to be the amount of connections Symantec makes to the device, this manifests itself by either crashing the NAS drive or exceeding the connection limit as in this example.

If I remove symantec and install for example Acronis, or use Windows backup the NAS no longer crashes and there are no more connection issue.

I'm hoping its because we are fairly new to this product and are missing something because if not it suggest the product has issues that need resolving.

We recently switched from Acronis to Symantec, and have put it in 18 installations so far, and really dont want to have to start looking for another solution so any help would be appreciated...

[criley]

This sounds very similar to an issue that is currently under investigation where BESR maintains it's connection to the backup destination even after the backup completes. Eventually the number of connections to the share gets maxed out.

One possible workaround is to schedule a restart of the BESR service before the backup starts. Have you tried this?

[PCJunky]

Thanks Chris, sometimes your so close to these things you dont spot the obvious, I will try exactly that and let you know.

Good to hear its under investigation...

[PCJunky]

Is there a thread for this topic, it would be good to validate my finding and see what people have done to work round this problem?

Thanks

[PCJunky]

On further investigation (we have this issue at a few sites, but the setups have subtle differnences so it would be unfair to campare them as identical problems) so I'll list some examples:

Example 1,  Symantec BESR 2010 backs up two partitions to a budget NAS drive over a 1 GB lan, and offsite copy backs up to a USB drive plugged into the same NAS, this has worked perfectly for several months then suddenly with no apparent changes starts encountering the error above, restarting the services does not help, but rebooting the server does - but only for a few days.

Investigation, turns out the nas has reverted from the name we gave it to the factory name but no other config is lost, the result is that windows still sees it and is happy, and strangely so does BESR but it’s not happy, rather than rename the NAS back we delete and recreate the jobs, when trying to edit them BESR will not resolve the name (even though the job runs), confusingly the backup history is still tracking the old backups and is happy. Once the jobs are recreated to point to the new NAS name and all traces of reference to said name are removed from BESR it now works as expected.

Thoughts: Clearly BESR is not to blame here as the changing NAS device name is responsible for the errors, however its odd that it does not simply fail with the error that it can’t find the device, which does raise my current suspicion that BESR handles names and UNC path resolution independently from the OS - but that’s for another post...

Example 2, Same setup as above - and only backing up 32GB, NAS falls over about once a week, no errors are displayed in BESR.

Investigation, NAS falls over about once a week, removing the offsite copy reduces the NAS to falling over after 2 weeks testing.

Thoughts, Suspect the NAS is falling over due to the amount of connections from BESR as the amount of data being transferred is inconsequential.

Example 3, Same as example 1, but 2 servers backing up to 1 NAS, NAS falls over about once a week, offsite copy never works.

Investigation, In this case the data is around several hundred gb, removing the off-site copy and resolving some minor issues that raised questions as to whether the LAN connection was performing at 1 GB has resolved the issue.

Thoughts, in this case clearly the volume of is a factor, but we suspect it is simply compounding the issue BESR has with multiple connections.

Example 4, same as above, this is a pretty standard setup for us, two server backing up to one NAS, both with Symantec BESR, both backing up to a share on the nas, and also a USB drive attached to the NAS which is treated also as a share.

Investigation, so far we have been unable to make any progress with this, the NAS has been replaced 4 times and is now a higher end model - on-going...

Thoughts, Symantec was used to replace the previous backup software, prior to that this solution worked.

We have for the main part 3 different backup software solutions in place, and 2 different makes of NAS drive, we only encounter the NAS drives falling over where Symantec BESR is in place which is why we are suspicious there is an issue with too many connection...

[PCJunky]

...ok so a little further down the road I have this insight to offer.

There is definately is an issue with to many connection, the amout is hard to pin down, as are the exact circumstances.

Best solution I have come up with when I encounter this is to scrap the current config, delete all jobs and backups - paying close attention to historical backups as Symantec SR tracks these, delete all referance to backups so you effectivly have a clean install with no schedules created, no links to historical backups, and no scheduled virtual server conversions.

Now with nothing configured create 1 new backup job, reoccuring if required (but do not create multiple jobs at this stage), let this run over a few days and see if you have a problem, if you do then there are other issues affecting this, if you don't then its the 'to many connections issue', just slowly add jobs back in untill it becomes a problem - and thats your limit.

Typically this will occur for us if we back up to a NAS drive over 5 days with 5 seperate jobs, and each job has an offsite copy that it writes to a USB drive meaning with historical backups Symanhyec SR could have its finger on 30 to 60 files at any one time....