MS SQL cluster does not backup disks

[virag0640]

Hi,

I have 2 MS SQL clients with cluster licenses.

Originally we just had Saveset: All configured
but we discovered that only C: drive was being saved on these
systems.

So now we have Savesets configured for S:, P:, Q: and
so on.

But when the backup runs, one server ignores these
completely (as it should) but the other one only
seems to backup 1kb of each drive, even though
there are gigabytes of data on each. I have been told
the P/Q/S drives are SAN connected.

Both systems are Windows 2003, NetWorker version: 7.3.2.Build.364;

I am not an MS admin - I am a Solaris admin but
I can't see any problems with the Legato config - it
is identical to another setup that works fine.

Please let me know what would stop these drives
saving? There is no error, but no backup for them
either.

One machine reports:
P:\ save: File P:\ could not be opened and was not backed up. (The device is not ready.) which is what should be expected, but the other one doesn't run at all.

Please help!

 

[a060463xyz]

If you want to save the shared Disks in a MSCS Cluster you have to define the virtual Clusterserver as a Networker Client.
Example: you have two physical clusternodes sql1 and sql2
Saveset all on this machines will only backup local disks normally only Drive C.
You have a one or more virtual instances who owns the shared disks, its usually the name of the clusterd SQLserver, lets call it prodsql.
The you create a new Client mnamed prodsql, set the savesets to S:\;P:\;Q:\ et. al.
Donst forget to give remote access rights :
SYSTEM@sql1
SYSTEM@sql2
clusterserviceAccount@sql1
clusterserviceAccount@sql2

For testing you can use *@* so every account from every host is authenticated.
If you want to backup the sql instance online you need the sql Business Modul, otherwise shut down the databases with a
savepnpc script or skip the databse Files using a directive.

 

[virag0640]

Hi,
Thanks for your help. I have made partial progress
and then fallen backwards. We created the Virtual Host Client
as suggested. I gave it Drives P/Q/S and added the
client remote access to/from both physical clients.

Then we tried a series of backups which seemed to work.

Then we failed over and it stopped working.
Now in spite of trying every possible combination of
SYSTEM@client attributes, I now get:

save: File index error: permission denied, `SYSTEM' on `sql-2005-1-uat.ad.local' must have remote access privilege to client sql-2005-2-uat. Now all these names and addresses resolve in Legato via DNS or /etc/hosts. I have
added them all into the various aliases and also added
the SYSTEM@client versions on all three as well. But it
refuses to run. We also tried deleting the Clients and
adding them back with the same ID number but it still
doesn't work.

Can you please point me to a definitive guide that has
everything required to do this spelled out, so I can
work through a checklist and try everything.

I am at a loss now...


rachel

 

[haasemi]

Hi,

do the backup work with remote access rights *@*?
How you have set the remote access rights in the client definitions exactly?

regards
Michael

 

[virag0640]

Hi,
sorry for late reply - off sick!
Anyway, I have every possible combination of
remote access on both nodes:

SYSTEM@node1
SYSTEM@node1.fqdn
SYSTEM@*.*
SYSTEM@*
*@*.*
*@*

The last 4 are for testing/debug.
I still get the error:

save: File index error: permission denied, `SYSTEM' on `sql-1' must have remote access privilege to client sql-2
despite addressing all these.

I am at a total loss.


rachel

 

[605]

The general usage is "user@hostname". "*.*" as hostname alias do not make sense.

Anyway - it looks like a bug. It complains about a permission error during a write process and this does not make sense. However, remote access rights are required for recoveries only. Such issues should not occur during backups.

Try to run a manual backup at this client first with added verbosity, for example: save -vvv P:\
This should return more details.

On the other hand - if you use more NW User Groups than Administrators and Users, make sure that the attribute "Remote access all clients" has been set appropriately.

 

[a060463xyz]

Sorry 605,
with a MSCS Cluster you need the remote access rights during backup of the virtual server.
But *@* should always work.
Delete all other entries especially those with @*.* !!

Have a look to name resolution :
Use DNS for all clusternodes if possible get rid of the local etc files (just leave the local host entry 127.0.0.1 in the file).
Foreward and reverse nameresolution is required.

If name resolution is ok, have look at your filesystem rights.
On the root of S:\, P:\ and Q:\ the Systemaccount of each clusternode and the cluster service account must have "fullcontroll". Per Default on a Windows Server "Everyone" has fullcontrol. If you have changed this, look for the System Accounts.

 

[605]

@ a060463xyz,

if you really need the remote access information it could be that NW wants this in preparation for a recovery or that this is simply a bug.

At least the information in the NMS Admin Guide does not point to the fact that it is needed for backups.

 

[a060463xyz]

Hi 605,
MSCS Backup is a little bit tricky :
You connect to the virtaul Server but the networker agent is running on theephysical machine.
So networker connects to client a (virtual server) but client b (physical node) is responding. Therefore the remote access rights are checkked and if properly set the backup continues.

I have about 20 MSCS cluster systems in different customer environments using Networker.
I used NW 7.0 to 7.4.2 in those environments and all versions require the remote access Atributes set to SYSTEM@node to perform a backup.

 

[605]

Thank you for this input, a060463xyz

 

[virag0640]

Hi,
thanks everyone for your assistance.

I got rid of all the wildcard entries in the remote
access field for the client.

Then I set from Networker Server "Remote Access All Clients"
as suggested above. This appears to have solved my
problem, but at the same time, checking this field forces
Legato to check a bunch of parameters in the Users field
that opens up more options in Legato, so I do not
not know what the risk is here.

I am going to consult with our MS admin responsible
for the box and see if the ClusterService "fullcontrol"
setting is correct. If this fixes it, I will adjust
the remote access back again to something more restrictive,
but for now, our backup seems to be working.

Thanks again for the assistance - this is a great site.


rachel

 

[605]

Remote access all sites" is an attribute for a NW User Group resource. It is nothing else but a global entry instead of an individual list for one client.