02-14-2013 07:27 AM
hi
i'm trying to restore clustered datbase to same node with different name (previous month) . It fails with insuficient disk space. despite we have 10times space available restore fails.
DB size is approx 103GB restore LUN has 1.5 TB free space
NBU 7.1.0.4 windows 2003 r2
SQL 2008 r2 clustered
Solved! Go to Solution.
02-14-2013 07:29 AM
Is drive where u are restoring part of cluster? If not then
Try adding that drive in cluster resource group and then perform restore
also post dbclient logs
02-14-2013 07:29 AM
Is drive where u are restoring part of cluster? If not then
Try adding that drive in cluster resource group and then perform restore
also post dbclient logs
02-14-2013 10:41 AM
Please post restore script as well as dbclient log on destination client.
Any chance you are accidently restoring to inactive node?
02-15-2013 12:01 AM
There are a few requirements when restoring to a SQL cluster.
1. You must first (re)start the SQL server/services in single instance mode. This is some kind of maintenance mode. Basically you have to first un-cluster the cluster.
1a. Now you should only have a single active SQL server, let's call it NodeA. This is where you should run the SQL restore procedures. You cannot restore SQL from within the master or media servers. You have to do it from within the active SQL server NodeA.
2. Since you backed up the SQL cluster using a virtual name, NodeA cannot restore the DBs because Nbu treats the virtual name and NodeA as unrelated entities.
To solve this problem, one solution is to create the following touch file:
install_path\NetBackup\db\altnames\No.Restrictions
3. Now that the prerequisites are all set, you have to follow the steps in the Nbu SQL admin guide under "Redirecting a restore to a different host". It is considered a redirect restore because, as stated previously, the SQL virtual name and NodeA are considered unrelated by Netbackup.
You will find details to all 3 of the above steps in the Nbu SQL admin guide.
02-16-2013 08:45 PM
hello all
sorry for delay in responding. was stuck with back to back restore calls.
following things was done to complete restore. Thanks to capt.jack for hint
we verified we have No.Restrictions is place
hostname/virtualname used during restore was correct
drive space was sufficient
user had privileges required for restores
disk was also member of cluster group. but when we did failover due to patch update on nodes we found disk didn't failed over. so suspect was correct somehow disk was not correctly became part of cluster group
we removed it and added new LUN and did failover drill which went successful and subsequent out restore too.
Thanks jack for highlighting disk part