cancel
Showing results for 
Search instead for 
Did you mean: 

Windows 2003 Cluster Passive Node shows cached drive letter

smakovits
Level 6

I have a windows 2003 file Cluster that finishes with status 1 as a result of "phantom" drive letters.  Essentially what it is is when the cluster drives fail over to the the other node, the now passive node still shows the drive letters in windows explorer.  If you try to open the drive, you cannot because the data does not exist.

 

I have the following EEBs that I use on clusters that fail because software installed on the shared disk is not cluster aware, so the job finishes with a status 42, eebinstaller.2140536.1.AMD64 and eebinstaller.2149421.1.AMD64.  However, this EEB is to tell the system to ignore the missing disk during the shadow copy backup.  The drive letters in this case do not even show up, therefore, it is a completely different issue.

 

I have searched and searched and the only thing I have found is that this is said to be by design and the drive letters appear because of drive letter caching in Windows Explorer, but it is also not an issue that I see on all of my Windows clusters.  For the most part, I only see this on windows 2003 systems.

 

 I am curious if anyone else has experienced this same issue and if they know of any sort of work around.  While it does not appear to be a NBU issue, maybe there is a way to tell NBU to skip the non-accessible drive, but I dont know because the drive letter appears, but there is no disk/data to go along with it, so it is simply a "phantom" drive letter.

 

In the below case, I end up with a status 1 for drives H, I and J

 

Jan 3, 2012 5:09:25 PM - begin writing
Jan 3, 2012 5:10:24 PM - Warning bpbrm (pid=4912) from client cor089f32: WRN - can't open directory: J: (WIN32 21: The device is not ready. )
Jan 3, 2012 5:10:28 PM - end writing; write time: 0:01:03

 

1 ACCEPTED SOLUTION

Accepted Solutions

Mark_Solutions
Level 6
Partner Accredited Certified

Not really a way around it that i can see - even policy specific exclude lists would put you in a similar position and the ALL_LOCAL_DRIVES directive could then cause a 71 error.

Best practice has always been to use seperate policies:

http://www.symantec.com/docs/TECH126206

View solution in original post

7 REPLIES 7

Mark_Solutions
Level 6
Partner Accredited Certified

For Cluster backups you need two policies:

1. A nodes policy that backup up the Shadow Copy Components plus physically local drives (C:\ and D:\?) - this contains each node as a client

2. A cluster policy that contains just the shared / clustered drives and the virtual server name as the client

Hope this helps

smakovits
Level 6

the reason I do not like this solution is that if a drive is added and I dont know about it then the policy will skip that drive.  This issue only started recently as I always used to backup all local drives for each physical node to ensure I get everything.

Mark_Solutions
Level 6
Partner Accredited Certified

Not really a way around it that i can see - even policy specific exclude lists would put you in a similar position and the ALL_LOCAL_DRIVES directive could then cause a 71 error.

Best practice has always been to use seperate policies:

http://www.symantec.com/docs/TECH126206

J_H_Is_gone
Level 6

that is why you run the coverage report at least once a quarter if not more often.

smakovits
Level 6

I have implemented the seperate policy method.  I fought it long enough...I just dont remember the issue prior to 7, but that is now old news.  

I now have 4 policies, 1 for each physical node (2) as their local disk varies slightly and 1 for each of the 2 cluster names, each specifying the drive letters associated with their shared disk.

 

Now the question I have is, What is the coverage report?

J_H_Is_gone
Level 6

check_coverage is found in your /netbackup/bin/goodies dir.

it will get info from your client like what drives it has, and then see if all of those are being backed, and what policy gets them.  if a drive is not backed it will say it is not. 

Exclude list will mess with this a bit as it does not read that into the coverage

with clusters you have to run it on all the servers in the cluster and cross reference.  the not covered "resources" on the physical servers with the covered resources on the virtual servers.

 

I have a real nice script but I cannot remember where I got it from - and I made some change to it.

but it makes a nice report.

As most servers are just straight backups most of the report is easy to go through, only the clusters need to be cross reference - and I have to double check any that have drives not covered (as it may have been setup that way on purpose).

Mark_Solutions
Level 6
Partner Accredited Certified

Hope this has covered things for you as well as also giving extra information in relation to the coverage report.

Dont forget to close off the thread by marking a solution if you feel you have had your question answered here.