Hi, this problem appears to be an FAQ, for which there appears to be very little answer. I have attempted here to put all the required info in one place, where it can be searched and commented on. It would appear the solution and the problem manifest themselves differently for different reasons, but there is no one consolidated place to find the info and the specific solution for our problem (until now)! It took me many hours of searching, testing, retesting and frustration until I finally got it to work. Even Sun had problems giving me a straight answer. The problem will manifest itself thusly: # savegrp unix-daily * myclient:/usr save: error, no matching devices; check storage nodes, devices or pools * myclient:/usr save: Cannot open save session with nsrserverhost 06/29/04 14:24:27 savegrp: myclient:/usr will retry 5 more time(s) * myclient:/ save: error, no matching devices; check storage nodes, devices or pools * myclient:/ save: Cannot open save session with nsrserverhost 06/29/04 14:24:27 savegrp: myclient:/ will retry 5 more time(s) * myclient:/export/home save: error, no matching devices; check storage nodes, devices or pools The client is backed up via Storage Node, but the Index and Bootstrap files *must* be backed up via the nsrserverhost to be a valid backup. Here is the checklist to work against: You have to have Legato 6.0 or better. For "mixed media" (LTO1 & LTO2), 6.1.4 is the minimum version. Make sure 111962-10 is installed if you are using Legato 6.0.1. The Client must have both the nsrserverhost and the hostname of the Storage Node set in the Storage Nodes attribute field in the Client Configuration. The Storage Node has to be able to write to attached storage on the nsrserverhost. The IP address of the nsrserverhost and the Storage Node have to be correct. In early (5.x) versions of Legato, the order of names in /etc/hosts is important. It is not so much of an issue in V6.x. The /etc/hosts order should be: IP FQDN Alias1 Alias2 ... Our setup is a special situation, in that the nsrserverhost and the Storage Node are both attached to the same L700, in a "mixed media" configuration, but they do not share the same type of drive media. This made it doubly hard to resolve the problem since we couldn't write to the different devices. SOLUTION: The simplest way for us was to create a "File Device" in Legato, attached to nsrserverhost. Then a special Pool was created called "Index", with an entry included for only 2 kinds of save sets - index and bootstrap. Then, the nsrgroups were added to the Pool config, for all groups run via the Storage Node. When the Storage Node backup is run, the bootstrap will be written to the file device. Subsequently, we clone the data to an active Tape Pool. Here is the procedure I used, in detail, to do the above. Knowledge of Legato is required! 1) First create your Storage Node Pool. Only add the devices that the Storage Node has control of to this Pool. Check the boxes for each group you wish to backup via the Storage Node. You may also add individual clients or Save Sets here as well. You may check "Store Index entries" but leave the other options switched to "No". 2) Create a new Device in the Devices Menu. On your nsrserverhost machine, create a directory somewhere with plenty of space on it. I used "/opt/nsr/Index" - there is also a "/opt/nsr/index" directory already, so be careful! Go to the Devices menu and Create a new Device. Delete the path for the default tape drive that is added and put "/opt/nsr/Index" (or whatever you chose) instead. The directory *must* exist on nsrserverhost! Set the Media Type to "file". Set the device to "enabled". Set all other checkboxes to "No". Save the device. You will then see the Device in your drive list. You will have to manually Mount the device to use it, but you must first Label the Volume, just like a real Tape. I labeled mine "Full.000" but you can Label it however. 3) Create a new Pool. I used the name "Index" for my Pool. The only device added here should be your "/opt/nsr/Index" file device. Leave all other devices unchecked. In the "Save Sets" Attribute field, you must only add 2 entries: index bootstrap You may check "Store Index entries" but leave the other options switched to "No". Leave "Volume Preferences" unchecked. In the "Groups" section of this Pool, add all the Groups that are backed up via the Storage Node. If you fail to add one, you will get the "bootstrap failed" error message described above. You may also add the individual clients as in your Storage Node Pool above. Whatever, you must make sure that whatever you back up via the Storage Node is also listed here in this Pool. Now your system is configured to backup the bootstrap to the local nsrserverhost. You must make sure your "file device" is mounted. It doesn't seem to mount automagically, unlike a tape volume. If you leave it mounted during shutdown, it will remount, but it doesn't seem to get used until you dismount and remount it - this is a "gotcha!" (help here appreciated) Start your backup. The backup should run through the Storage Node as usual, but you will see when the index and bootstrap get backed up, it will go to the "file device" you nominated instead. Success! IMPORTANT! This file device directory gets BIG. It gets BIG, FAST! ( the above sentence looks like Spam?!) Take note of the next procedure - to clone your Index file volume to a real Tape Pool. At the end of each backup session (we do it via each group), the bootstrap record is written out. You can do the following to clone the bootstrap to an existing Pool: This is a very Q&D shell script, to be further developed, but it works for now: ############ #!/bin/sh # SSID=`/usr/sbin/nsr/mminfo -B -q 'volume=Full.000' | awk -F' ' '{print $4}' |egrep -v "ssid"` /usr/sbin/nsr/nsrstage -b"UWS Daily" -m -S $SSID ########### The mminfo command gets the bootstraps for the last 5 weeks (canned query) and investigates our file volume "Full.000" and then I just simply grab the SSID's. Then pass this to nsrstage, to backup to one of our regular volumes to long term storage. This volume Pool needs to be one attached to nsrserverhost for DR purposes or you will be unable to recover the bootstrap. The boostrap will be automagically deleted after being cloned. You will note, that if you look in the directory where your file device is referenced, that the index files will not be deleted. You can do this manually, but you will need to dismount/remount the file Volume yourself (via a script). If anyone has more elegant solutions than this, let me know. rachel -- Rachel Polanskis Systems Admin, University of Western Sydney V1-37, Kingswood Campus (+61 2) 47 360 291 <r.polanskis@uws.edu.au> "They who would give up an essential liberty for temporary security, deserve neither liberty or security" - Benjamin Franklin, 1759 _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagersReceived on Tue Jun 29 21:44:55 2004
This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:43:34 EST