Re: [Networker] Indexes disappearing ..

On 29/09/11 15:13, Michael Leone wrote:
>> NW can purge a single save set or a volume, deleting the CFI data. 
>> The question just is: why would he do so? - So far i have no answer.

Is it possible that you have two set of index directories existing with
similar names, e.g. a long name and a short name? If so, try mminfo
queries using both versions, and check on the client ID.

Take a look at the client ID in the media database using mminfo. Is it
the same as the one in the client resource?

If anything here doesn't tally up we might be on the way to solving this.


> 
> Neither do I. Neither does EMC.
> 
> What I do know - my client seems to be retaining only 1 day's saveset, not 
> for MSSQL: backups, nor normal filesystem backups. 
> 
> If I start a GUI saveset recover, I do see previous MSSQL: backups, all 
> listed as browseable, to choose from. Yet I can not browse them, using the 
> SQL Module GUI. Nor can I browse the filesystem backups, which I also see, 
> and are also listed as browsable.
> 
>> However, i would look at the save set attribute:
>>   - if the save set is "recoverable" or "recyclable", then NW 
>> himself must have purged the 
>> save set(s)/volume(s)
>>   - if the save set is still listed as "browsable", somebody else (a
>> scheduled job?) must have deleted the index files/directories
> 
>> mminfo -avot -q "client=pssql3,savetime>09/27/2011" -r 
> ssid,name,totalsize(2),ssid,savetime(22),ssb
> 
>  ssid      name                        total ssid           date     time  
>       browse time      ssflags
> 729969055  MSSQL:                     265 GB 729969055   9/27/2011 9:00:14 
> PM 3/27/2012 11:59:59 PM vF
> 427979557  W:\                       4565 KB 427979557   9/27/2011 9:06:44 
> PM 11/27/2011 11:59:59 PM vF
> 411202384  V:\                        279 GB 411202384   9/27/2011 9:07:24 
> PM 11/27/2011 11:59:59 PM vF
> 327316335  U:\                          4  B 327316335   9/27/2011 9:07:58 
> PM 11/27/2011 11:59:59 PM vF
> 193098643  S:\                         99 MB 193098643   9/27/2011 9:08:34 
> PM 11/27/2011 11:59:59 PM vF
> 92435381   T:\                          2 KB 92435381    9/27/2011 9:09:08 
> PM 11/27/2011 11:59:59 PM vF
> 25326559   F:\                         30 MB 25326559    9/27/2011 9:09:50 
> PM 11/27/2011 11:59:59 PM vF
> 3699538309 MSSQL:                    6674 MB 3699538309  9/27/2011 9:33:54 
> PM 3/27/2012 11:59:59 PM vF
> 3598875071 MSSQL:                    3668 KB 3598875071  9/27/2011 9:34:55 
> PM 3/27/2012 11:59:59 PM vF
> 3582097857 MSSQL:                    3093 KB 3582097857  9/27/2011 9:34:57 
> PM 3/27/2012 11:59:59 PM vF
> 3565320644 MSSQL:                    1496 KB 3565320644  9/27/2011 9:34:59 
> PM 3/27/2012 11:59:59 PM vF
> 3548543430 MSSQL:                      15 MB 3548543430  9/27/2011 9:35:02 
> PM 3/27/2012 11:59:59 PM vF
> 3531766218 MSSQL:                     440  B 3531766218  9/27/2011 9:35:05 
> PM 3/27/2012 11:59:59 PM vF
> 696501024  MSSQL:                     265 GB 696501024   9/28/2011 9:00:15 
> PM 3/28/2012 11:59:59 PM vF
> 595838103  W:\                       4784 KB 595838103   9/28/2011 9:06:29 
> PM 11/28/2011 11:59:59 PM vF
> 579060927  V:\                        285 GB 579060927   9/28/2011 9:07:10 
> PM 11/28/2011 11:59:59 PM vF
> 562283747  U:\                          4  B 562283747   9/28/2011 9:07:46 
> PM 11/28/2011 11:59:59 PM vF
> 528729352  S:\                        100 MB 528729352   9/28/2011 9:08:21 
> PM 11/28/2011 11:59:59 PM vF
> 428066088  F:\                         32 MB 428066088   9/28/2011 9:08:55 
> PM 11/28/2011 11:59:59 PM vF
> 260293980  T:\                          2 KB 260293980   9/28/2011 9:09:47 
> PM 11/28/2011 11:59:59 PM vF
> 3917728315 MSSQL:                    6947 MB 3917728315  9/28/2011 9:30:32 
> PM 3/28/2012 11:59:59 PM vF
> 3800287862 MSSQL:                    3604 KB 3800287862  9/28/2011 9:31:33 
> PM 3/28/2012 11:59:59 PM vF
> 3783510648 MSSQL:                    3158 KB 3783510648  9/28/2011 9:31:35 
> PM 3/28/2012 11:59:59 PM vF
> 3766733435 MSSQL:                    1496 KB 3766733435  9/28/2011 9:31:38 
> PM 3/28/2012 11:59:59 PM vF
> 3749956221 MSSQL:                      15 MB 3749956221  9/28/2011 9:31:40 
> PM 3/28/2012 11:59:59 PM vF
> 3733179009 MSSQL:                     440  B 3733179009  9/28/2011 9:31:44 
> PM 3/28/2012 11:59:59 PM vF
> 
> 
> If I go to client PSSQL3 and start to do a GUI recover using the SQL 
> Module, the only backups it shows that I can choose from are 2008-09-28. 
> Those backups shown above, from 2011-09-27? Not showing up as available at 
> all, even though they have not expired, and are still browsable for 6 
> months yet. Have not run any "nsrim" commands, or marked anything as 
> expired, or anything. Just our regularly scheduled "savegrp -O" to save 
> the indexes. And no one else has been administering Networker but me.
> 
>> BTW - to verify the contents of an index use "nsrls -v -t [n]savetime 
> client"
> 
> That command does not work.
> 
>> nsrls -v -t 09/27/2011 pssql3
> usage: nsrls [ { clientname ... | -m } ]
> 
> To sign off this list, send email to listserv AT listserv.temple DOT edu and 
> type "signoff networker" in the body of the email. Please write to 
> networker-request AT listserv.temple DOT edu if you have any problems with 
> this list. You can access the archives at 
> http://listserv.temple.edu/archives/networker.html or
> via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

To sign off this list, send email to listserv AT listserv.temple DOT edu and 
type "signoff networker" in the body of the email. Please write to 
networker-request AT listserv.temple DOT edu if you have any problems with this 
list. You can access the archives at 
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER