Video Screencast Help

backup destination unreachable after server reboot

Created: 21 Aug 2012 • Updated: 22 Aug 2012 | 9 comments

I'm running in a recurrent problem with SSR2011 :

We use to backup our server running under SBS2011 using SSR2011 onto a backup directory on a NAS. The backup directory is protected and access is granted to administrators (me, of course). Note that security on the NAS is managed by Active Directory.

This uses to work perfectly except when server is rebooted (i.e. for updates)

After server has been rebooted, the next backup fails because access to the backup destination is denied :

Erreur EC8F17B7 : Impossible de créer des points de récupération pour l'opération : Sauvegarde du lecteur de Réservé au système (*:\), (C:\), DATA (E:\).
 Erreur EC8F03ED : Impossible de créer le point de récupération.
  Erreur E7D10041 : Impossible d'établir une connexion de réseau à \\nas1_cbl\svg_sbs.
   Erreur EBAB03F1 : Plusieurs connexions à un serveur ou à une ressource partagée par le même utilisateur, en utilisant plus d’un nom utilisateur, ne sont pas autorisées. Supprimez toutes les connexions précédentes au serveur ou à la ressource partagée et recommencez. (UMI:V-281-3215-6071)

Détails :
Source : Symantec System Recovery

Sorry for the error message in French blush essentially, it says that SSR was unable to connect the NAS on the network because many connections to a single resource (the NAS) using more than one name are not allowed.

However SSR knows only one name (mine) which worked fine before reboot of the server.

I tried to remove any protection on NAS directory (access granted to all): same error.

NAS can be accessed from the server using windows explorer. NAS can even be accessed from SSR using Recovery Point Browser. But no backup can be performed on the NAS and previous recovery points are declared unavailable !!!

Up to now, the only solution I have found is to delete the current backup work, remove all protection on the NAS (not only for the Backup directory but fot the NAS as a whole), create a new backup work (which requires a name and password even if not needed - I use always the same - mine), have it run during a couple of backups and then reset the protection on the NAS.

Any hint on why this happens? and how to cure it?

BTW, I would like to know how to cancel all connecions to the NAS as suggested by the last sentence of the error message. I have already reset completely the NAS without any succes...

 

 

 

Comments 9 CommentsJump to latest comment

Chris Riley's picture

Have you tried using ip address instead of hostname when specifying the backup destination?

http://support.microsoft.com/kb/938120

PJ_CBL's picture

Yes, I did. It works for a new backup but does not consider previous backups which stay unavailable and starts with a new recovery point (does not consider the previous full RP for creating an incremental RP). I really fear that at next reboot of the server, I will have no more access to the NAS , neither by name nor by IP...angry

Well, OK it is a bit more handy than my previous solution but does not solve the problem of continuity of the backups crying

I tried too the command NET USE {NAS name} / DELETE which is supposed to clear previous connections to the NAS but SSR still continues to show the same error.

I also tried to stop and restart all services connected to SSR on the server, same result...

 

Thanks for your help.

Chris Riley's picture

Well, OK it is a bit more handy than my previous solution but does not solve the problem of continuity of the backups.

  1. It wont 'remember' the previous backups as you are now using a new backup destination. For this reason, the first backup to this new location must be a full.
  2. I'm not sure I understand your comments about this being 'more handy'....are you saying that it has helped with the issue where the destination is unreachable folllowing a restore?
PJ_CBL's picture

Sorry for my poor English... It may cause some misunderstanding...

1) "...a new backup destination..." is not actually new, it's the same with another name. Previously recorded RPs are still here. I admit that using an alias for the path to the destination, the system is not clever enough to detect that it arrived at the same place. However, if I have to change the name for the path each time I reboot the server, I will have a lot more full RPs than expected, thus consuming more disk space... and also more time in switching aliases for the path, trying to remember in which set of RPs is the file I want to recover, etc. Therefore, this "solution" is not an "industrial" solution. It is at best a temporary workaround.

2) "more handy" was intended to mean easier to implement than my previous workaround where I had to perform more operations to restart safe backups. However, as said here above, this is NOT a solution (at least in my mind).

I know I'm a bit of a perfectionist, but having little time to spend on these computer issues (this is not my main activity) I do like fixes that fix definitively errors ;)

I suspect that the problem is not only on Symantec side but also on M$ side as network access is managed by the system... but why SSR is the only software affected by reboot of the system ? Our antivirus solution (Symantec Endpoint Protection) has no problem with server reboot though it has to deal with much more network destinations...

Chris Riley's picture
  1. I know it's the same location - you are just using IP instead of hostname, but SSR will 'see' this as a new backup destination as the path is different.
  2. However, if I have to change the name for the path each time I reboot the server - I was not suggesting you change this every time the server is rebooted. My suggestion was to change the backup destination so that it uses the ip address instead of the hostname. This destination should stay as it is. Have you tested yet to confirm that you don't see any problems with this new destination following a reboot?
PJ_CBL's picture

Hi Chris,

1) I knew that computers are a bit more stupid than humans... I wish I could see my mother-in-law with new eyes each time my wife tells me to use another way to go to her ;)

2) OK I confess I'm stupid too. I now understand that designating the NAS by its IP address is supposed to solve definitively the problem and that SSR will no more forget its way to the storage directory.

I have not tested yet (I don't like rebooting the server too frequently) but I will check at next mandatory reboot and post here to confirm the solution.

Thanks a lot for your patience with this damned dumb Frenchy ;)

Pierre

 

Chris Riley's picture

No problem. Keep us posted with your results once you have tested this then.

PJ_CBL's picture

Back after 2 months test : I got at least 4 times the same kind of error where SSR was unable to get access to the NAS, even using IP address for it.

Error message :

Erreur EC8F17B7 : Impossible de créer des points de récupération pour l'opération : Sauvegarde du lecteur de Réservé au système (*:\), (C:\), DATA (E:\).
 Erreur EC8F03ED : Impossible de créer le point de récupération.
  Erreur E7D10041 : Impossible d'établir une connexion de réseau à \\192.168.1.250\svg_sbs.
   Erreur EBAB03F1 : Accès refusé. (UMI:V-281-3215-6071)

It seems to appear randomly (no reboot of the server before occurrence of error) and it is in no way linked to a bad password as it worked the following day without any action on my side...

I have now installed SP3 and will see if things improve...

Chris Riley's picture

This could be a Windows issue but the logs will need to be analyzed before this can be confirmed.

If SP3 does not help, please open a support case for this issue.