Unsuccessful backups

[COTLG]

Hi,

I shut down legato, renamed the client index files, started Legato and ran nsrck -L7 for all the clients. I got this sort of message after the next backup ran. Please how do I resolve this?

--- Unsuccessful Save Sets ---

* client1:index 1 retry attempted
* client1:index usage: save [<options>] [path ...]
* client1:index
* client1:index options: [-BEiLnqvx] [-s server] [-c client-name] [-N name] [-e expiration]
* client1:index [-f dirfile] [-b pool] [-F file] [-I input file] [-g group]
* client1:index [-l level] [-t date] [-m masquerade] [-W width]

--- Successful Save Sets ---

* client1:C:\ Warning: unsynchronized client clock detected
client1: C:\ level=incr, 7634 KB 00:06:58 45 files
* client1:E:\ Warning: unsynchronized client clock detected
client1: E:\ level=incr, 4984 MB 00:12:44 83 files
* client1:SYSTEM STATE:\ Warning: unsynchronized client clock detected
client1: SYSTEM STATE:\ level=full, 9981 KB 00:03:19 12 files
* client1:REPAIRDISK:\ Warning: unsynchronized client clock detected
client1: REPAIRDISK:\ level=incr, 0 KB 00:01:32 0 files

 

[605]

It looks like NW cannot backup the index any more due to the
renaming process.

The &quot;Warning: unsynchronized client clock detected&quot; just
occurs if the system times client/server are more than 1
minute apart.

 

[COTLG]

605 any suggestions as to how I can resolve this? not been long I started making use of Legato Networker.

 

[TDun]

Try an nsrck -c client1.

 

[john7]

go to the admin gui and use the detailed view (or in NT go to options\customize and check all three boxes on the windows configurations screen) exit the gui and start it again. Now go to the client that is the problem. There is a field for the index path you can use this to point to the new location of the indexes. Be careful while using this mode, if you are a novice you can cause yourself a great deal of greif. You may want to uncheck the boxes from above after you change the path.

 

[COTLG]

Hi TDun and john7,

I have done an nsrck -c, nsrck -L7 and also changed the index path which I noticed was not under /local/data/nsr/index but /local/data/index. Still problem persists. However I think that it is not getting the correct save index instruction (that is the syntax is wrong) from whichever file it is getting it from.

If anyone knows the file that the nsrindexd daemon gets its index save instructions from, then I will have a look to spot out any inconsistency.

Thanks and please awaiting your replies.

 

[TDun]

Try running savegrp -vvvv groupname, replacing groupname with the name of the relevant group.
This should give you details of the commands issued.

 

[COTLG]

Hi TDun,

I have run savegrp -v groupname. The index saves failed and I did not get a clue as to what files this command works with. Is there a sort of last resort to this problem? I really need to get over with this.

 

[TDun]

call nsradmin >>outp.txt
at the prompt enter
print type: NSR group
and then press enter twice
then type quit.
edit the file so it only shows the group you are having the problem with (or one of them) and then post that part of the file onto here, then we can see what your settings are for the group.

 

[TDun]

ALSO, paste in the ping info for the client in question and a ping of the server from the client, both of them from the IP address and the server names, as shown in Networker.
PS the output from savegrp -vvvv would have shown something like:
C:\>savegrp -vvvv Default
tdun:C:\ level=incr
tdun:SYSTEM STATE: level=incr
08/21/03 15:57:11 savegrp: Run up to 4 clients in parallel
08/21/03 15:57:11 savegrp: tdunrobe

savefs -s tdun -c tdun -g Default -p -l full -R -v -F C:\ SYSTEM STATE:

showing thsat it generates savefs.

 

[COTLG]

Hi TDun,

I hope this is the information you need. All the groups have the same problem therefore I think a print out of one is enough. Thanks.


type: NSR group;
name: Default;
autostart: Enabled;
start time: &quot;20:20&quot;;
client retries: 4;
clones: No;
clone pool: Default Clone;
migration clone pool: Migration Clone;
printer: ;

 

[COTLG]

If you need more information please ask. This is the result of the unsuccessful saveset from the backup server x:

server x:index 5 retries attempted
* server x:index usage: save [<options>] [path ...]
* server x:index
* server x:index options: [-BEiLnqvx] [-s server] [-c client-name] [-N name] [-e expiration]
* server x:index [-f dirfile] [-b pool] [-F file] [-I input file] [-g group]
* server x:index [-l level] [-t date] [-m masquerade] [-W width]

* server x:bootstrap 5 retries attempted
* server x:bootstrap usage: save [<options>] [path ...]
* server x:bootstrap
* server x:bootstrap options: [-BEiLnqvx] [-s server] [-c client-name] [-N name] [-e expiration]
* server x:bootstrap [-f dirfile] [-b pool] [-F file] [-I input file] [-g group]
*server x:bootstrap [-l level] [-t date] [-m masquerade] [-W width]

 

[TDun]

You will have had more before this part. Give us from the previous empty line to the next empty line.

 

[COTLG]

Please what actually do want me to do or what particular information do you need? So that I can supply it in detail. Thanks.

 

[605]

I think it is most important to also tell us how you renamed
the files. But on the other hand this is only important for
recovering old client index files.

Never change a subset of the files - always rename the
whole index path (starting with the client name).

Whatever you have done to the CFIs - once you restarted the
NW daemons, the resource file info will create a new CFI for
a valid client (according to the index path entry) if it
does not exist any more. So once you restarted the server,
it should also be able to do successful CFI backups.

-----------------------------------------------------

But i see another problem: Meanwhile you cannot even backup
your bootstrap either which does not have to do anything
with the CFI - since NW 6 only the resource files and the
media index will be backed up here.

As these files cannot be moved at all, NW must be able to
find them. The only problem is that you are running on a
UNIX or Linux server and you forget to start nsrexecd on
the NW server. This is why Legato corrected this in 6.1.3
and 7.x.

 

[COTLG]

Hi 605,

Thanks. The problem is now resolved. Had to manually start nsrexecd on the backup server. Once again thanks. It's a big relief.

Chike.