I have a Windows 2008 Microsoft Cluster with 2 physical nodes and 1 CSV. Networker Server 8.2.1. Networker Client 8.2
When I make an ALL backup in both nodes, the active one completes successfully, but the passive one does not. It shows me a message like this:
88224:save: The base volume for the path is unavailable or offline. Please ensure all volumes are online for backup operations.
88222:save: Could not add for backup.
WINDOWS ROLES AND FEATURES: ERROR: VSS failed to add components in pre save, writer=System Writer: The system cannot find the file specified. (Win32 error 0x80070002)
98193:save: Unable to save the SYSTEM STATE save sets: cannot add all the system state writers to the snapshot.
This happens because path F:\IBM....is in the Clustered Volume, so only Active Node can see it. So Passive node fails.
I have this configurations:
Backup Command = save -a '"ignore-all-missing-system-files=yes"'
It happens due to reference in registry on passive node. Try to remove that one (but write it down 1st as you wish to make sure that during failover it is created as well - if not, you have issue with entry which is seen as critical and therefore reported for backup regardless if there or not and top of it - it would not get created when switching nodes).
This is because the binary tomcat5.exe is registered as a service on the current server and the system state backup is trying to access this file to get it into the backups.
You can check this by going to Start -> run -> msinfo32 -> Software Environment -> Services.
If the service on the F drive is listed, then you might have to add a registry to exclude this binary from being backed up. below is the registry key details
I'm not sure about that... because registry instruction will be read nevertheless. So, if you say skip A on passive node... it will be skipped. Now, imagine there is failover and active node backup works fine, but it skips A. I assume if you do DR, you would expect data to be back including cluster stuff which would include service definition and data defined by A. I think only proper solution is to have MSCS remove entry during failover (or add it based on action is performs).
This happens only during the backup of the physical nodes, the best practice still says that the cluster node backups should be taken as a separate instance, which means the backup of the cluster node should contain this file as the file is on a shared disk.
I think that if we change the Registry adding this exclusion, it will not backup this file never, even if its the active node...so this can not be the solution (i guess...)
The thing is that why we can avoid this problem when it is incorrect uninstall of software (avoiding the file, or crating a dummy file), but when its a cluster, we can not do anything...
Anyway, I will try this next week and post the results:
Cause
The following error always appears when performing a DISASTER_RECOVERY backup for a passive physical node. The issue is when backing up DISASTER_RECOVERY some of the critical files are on shared volume and the volume can only be accessed through a single node at a time (active node).
Resolution
A) Add the following system environment variable to the client:
NSR_INITIALIZE_DIRECTIVE=TRUE
1. Right click on "My Computer" (or "This PC") and select "Properties". 2. Advanced System Settings. 3. Click on "Environment Variables". 4. On "System Variables" create the following variable:
If it is not set to 1, then set it to 1. NOTE: On Windows 2012 R2 this registry key doesn't seem to exist. If this key is not present, the default value is 1, so there is no further action needed.
B) Update the NetWorker client resource and add the following syntax to the "Backup operations" field: VSS:NSR_SYS_WRITER_WIN32_SERVCOMP_USER=yesThanks..
ble1
6 Operator
•
14354 Posts
•
56186 Points
3417
0
Posted June 11th, 2015 11:00
It happens due to reference in registry on passive node. Try to remove that one (but write it down 1st as you wish to make sure that during failover it is created as well - if not, you have issue with entry which is seen as critical and therefore reported for backup regardless if there or not and top of it - it would not get created when switching nodes).