Backup Central

Here's a weird one .. I have 2 clients (both virtual cluster clients),
both with browse and retention policies of 2 months, who have their
indexes either completely deleted (i.e., the index sub-folder for that
client is 0K), or it only has the previous day's activity. These are both
backups made with the SQL Module. Neither client nor job has changed in at
least months, perhaps longer.

Even weirder - this seems to happen on every weekday. The index backup (we
do "savegrp -O") on Sat morning - which would have the index from the
Friday backup - would be there. And that would be the only index backup
that wasn't empty.

mminfo -avot -q
"client=networker-server,name=index:client,savetime>09/01/2011" -r
volume,client,ssid,name,level,savetime(22),totalsize(2)

volume client ssid name lvl
date time total
006792 networker-server 1667207181 index:client full 9/1/2011
10:00:45 AM 32 KB
006872 networker-server 1298192353 index:client full 9/2/2011
9:19:29 AM 32 KB
006872 networker-server 2825005238 index:client full 9/3/2011
9:16:38 AM 10 MB

I wouldn't have noticed it, except that I needed to do a recover, and I
couldn't because it said there had been no files backed up (which I knew
to be false).
(that snippet is for earlier in the month, but it's the same all month)

"nsrls" shows the total size of the index to be zero
"nsrck -L6" shows no errors, and a total size of zero
"nsrck -L7" reads back in zero (unless I specify one of the Saturday
backups, like 9/3/2011 above)

Note that the groups that these 2 clients are in are set to "no index
save", like all our groups. I have 130 clients, and am only seeing this
problem on these 2. One client is a clone job, one is not.
EMC seems to be confused, as well.

Thoughts, anyone? I am going to uncheck the "No index save" temporarily on
these groups. Can anyone suggest something else to diagnose?

Thanks

--
Michael Leone
Network Administrator, ISM
Philadelphia Housing Authority
2500 Jackson St
Philadelphia, PA 19145
Tel: 215-684-4180
Cell: 215-252-0143
<mailto:michael.leone < at > pha.phila.gov>


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

On 2011-09-27 13:55, Michael Leone wrote:
Here's a weird one .. I have 2 clients (both virtual cluster clients),
both with browse and retention policies of 2 months, who have their
indexes either completely deleted (i.e., the index sub-folder for that
client is 0K),

I'm confused about this part: "is 0K". How is it OK if it's had its
indexes completely deleted? Are you saying that the directory itself if
still there but not its contents?

or it only has the previous day's activity. These are both
backups made with the SQL Module. Neither client nor job has changed in at
least months, perhaps longer.

Even weirder - this seems to happen on every weekday. The index backup (we
do "savegrp -O") on Sat morning - which would have the index from the
Friday backup - would be there. And that would be the only index backup
that wasn't empty.

mminfo -avot -q
"client=networker-server,name=index:client,savetime>09/01/2011" -r
volume,client,ssid,name,level,savetime(22),totalsize(2)

volume client ssid name lvl
date time total
006792 networker-server 1667207181 index:client full 9/1/2011
10:00:45 AM 32 KB
006872 networker-server 1298192353 index:client full 9/2/2011
9:19:29 AM 32 KB
006872 networker-server 2825005238 index:client full 9/3/2011
9:16:38 AM 10 MB

I wouldn't have noticed it, except that I needed to do a recover, and I
couldn't because it said there had been no files backed up (which I knew
to be false).
(that snippet is for earlier in the month, but it's the same all month)

"nsrls" shows the total size of the index to be zero
"nsrck -L6" shows no errors, and a total size of zero
"nsrck -L7" reads back in zero (unless I specify one of the Saturday
backups, like 9/3/2011 above)


Is it possible that the database client has been given permission to
delete client index entries? I'm not sure how things work with the SQL
module, but for the Oracle module, that's exactly how it works. With
Oracle, the recommendation is to give the client administrative
permissions to be able to remove its CFI entries. Apparently, it will
remove only its own entries (we hope) and not some other client's
entries. The theory is that you want the catalog (for example) on the
Oracle client to be in sync with the CFI entries on the backup server
side. If you don't do this, you will see error messages in the NetWorker
log file like:

Permission denied, user 'oracle' on 'clientxyz' does not have 'Operate
NetWorker' privilege to perform this operation - NSR.

And you will see error message in the Oracle logs on the client like:

lnm_index_remove_SSID: Permission denied, user 'oracle' on 'clientxyz'
does not have 'Operate NetWorker' privilege to perform this operation - NSR.

Perhaps, you have the time window set to 1 day on the SQL client for the
catalog, and it's going out and removing those index entries? Something
like that?

Note that the groups that these 2 clients are in are set to "no index
save", like all our groups. I have 130 clients, and am only seeing this
problem on these 2. One client is a clone job, one is not.
EMC seems to be confused, as well.

I don't see why that would be an issue. That controls whether or not the
client index gets written to tape. If you have it enabled for the pool,
that allow the entries to get added to the CFI on disk, right?


Thoughts, anyone? I am going to uncheck the "No index save" temporarily on
these groups. Can anyone suggest something else to diagnose?

Thanks



--
George Sinclair
Voice: (301) 713-3284 x210
- The preceding message is personal and does not reflect any official or
unofficial position of the United States Department of Commerce -
- Any opinions expressed in this message are NOT those of the US Govt. -


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

On 2011-09-27 13:55, Michael Leone wrote:
Here's a weird one .. I have 2 clients (both virtual cluster clients),
both with browse and retention policies of 2 months, who have their
indexes either completely deleted (i.e., the index sub-folder for that
client is 0K),

I'm confused about this part: "is 0K". How is it OK if it's had its
indexes completely deleted? Are you saying that the directory itself if
still there but not its contents?

Correct. There is an index folder, but it's empty.


or it only has the previous day's activity. These are both
backups made with the SQL Module. Neither client nor job has changed
in at
least months, perhaps longer.

Even weirder - this seems to happen on every weekday. The index backup
(we
do "savegrp -O") on Sat morning - which would have the index from the
Friday backup - would be there. And that would be the only index
backup
that wasn't empty.

mminfo -avot -q
"client=networker-server,name=index:client,savetime>09/01/2011" -r
volume,client,ssid,name,level,savetime(22),totalsize(2)

volume client ssid name lvl
date time total
006792 networker-server 1667207181 index:client full 9/1/2011
10:00:45 AM 32 KB
006872 networker-server 1298192353 index:client full 9/2/2011
9:19:29 AM 32 KB
006872 networker-server 2825005238 index:client full 9/3/2011
9:16:38 AM 10 MB

I wouldn't have noticed it, except that I needed to do a recover, and
I
couldn't because it said there had been no files backed up (which I
knew
to be false).
(that snippet is for earlier in the month, but it's the same all
month)

"nsrls" shows the total size of the index to be zero
"nsrck -L6" shows no errors, and a total size of zero
"nsrck -L7" reads back in zero (unless I specify one of the Saturday
backups, like 9/3/2011 above)


Is it possible that the database client has been given permission to
delete client index entries?

I have no idea how it could do that, or how you could set it. Never did
that with any SQL clients, but it's only these 2 having the problem.

I'm not sure how things work with the SQL
module, but for the Oracle module, that's exactly how it works. With
Oracle, the recommendation is to give the client administrative
permissions to be able to remove its CFI entries. Apparently, it will
remove only its own entries (we hope) and not some other client's
entries. The theory is that you want the catalog (for example) on the
Oracle client to be in sync with the CFI entries on the backup server
side. If you don't do this, you will see error messages in the NetWorker

log file like:

Permission denied, user 'oracle' on 'clientxyz' does not have 'Operate
NetWorker' privilege to perform this operation - NSR.

And you will see error message in the Oracle logs on the client like:

lnm_index_remove_SSID: Permission denied, user 'oracle' on 'clientxyz'
does not have 'Operate NetWorker' privilege to perform this operation -
NSR.

Never saw any such messages, tho.


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

On 2011-09-27 15:13, Michael Leone wrote:
On 2011-09-27 13:55, Michael Leone wrote:
Here's a weird one .. I have 2 clients (both virtual cluster clients),
both with browse and retention policies of 2 months, who have their
indexes either completely deleted (i.e., the index sub-folder for that
client is 0K),

I'm confused about this part: "is 0K". How is it OK if it's had its
indexes completely deleted? Are you saying that the directory itself if
still there but not its contents?

Correct. There is an index folder, but it's empty.


or it only has the previous day's activity. These are both
backups made with the SQL Module. Neither client nor job has changed
in at
least months, perhaps longer.

Even weirder - this seems to happen on every weekday. The index backup
(we
do "savegrp -O") on Sat morning - which would have the index from the
Friday backup - would be there. And that would be the only index
backup
that wasn't empty.

mminfo -avot -q
"client=networker-server,name=index:client,savetime>09/01/2011" -r
volume,client,ssid,name,level,savetime(22),totalsize(2)

volume client ssid name lvl
date time total
006792 networker-server 1667207181 index:client full 9/1/2011
10:00:45 AM 32 KB
006872 networker-server 1298192353 index:client full 9/2/2011
9:19:29 AM 32 KB
006872 networker-server 2825005238 index:client full 9/3/2011
9:16:38 AM 10 MB

I wouldn't have noticed it, except that I needed to do a recover, and
I
couldn't because it said there had been no files backed up (which I
knew
to be false).
(that snippet is for earlier in the month, but it's the same all
month)

"nsrls" shows the total size of the index to be zero
"nsrck -L6" shows no errors, and a total size of zero
"nsrck -L7" reads back in zero (unless I specify one of the Saturday
backups, like 9/3/2011 above)


Is it possible that the database client has been given permission to
delete client index entries?

I have no idea how it could do that, or how you could set it. Never did
that with any SQL clients, but it's only these 2 having the problem.

It's set by granting permissions under User Groups (nmc) for the given
user on the client. In the case of Oracle, the default behavior is that
if that user on the Oracle client is given the required NW privileges
then it will automatically remove the client index entries to match
what's in the catalog so there's no overlap or underlap. Otherwise, it
won't but an error message will be generated every time it tries. Are
the permissions for those two clients any different?


I'm not sure how things work with the SQL
module, but for the Oracle module, that's exactly how it works. With
Oracle, the recommendation is to give the client administrative
permissions to be able to remove its CFI entries. Apparently, it will
remove only its own entries (we hope) and not some other client's
entries. The theory is that you want the catalog (for example) on the
Oracle client to be in sync with the CFI entries on the backup server
side. If you don't do this, you will see error messages in the NetWorker

log file like:

Permission denied, user 'oracle' on 'clientxyz' does not have 'Operate
NetWorker' privilege to perform this operation - NSR.

And you will see error message in the Oracle logs on the client like:

lnm_index_remove_SSID: Permission denied, user 'oracle' on 'clientxyz'
does not have 'Operate NetWorker' privilege to perform this operation -
NSR.

Never saw any such messages, tho.


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER



--
George Sinclair
Voice: (301) 713-3284 x210
- The preceding message is personal and does not reflect any official or
unofficial position of the United States Department of Commerce -
- Any opinions expressed in this message are NOT those of the US Govt. -


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

Something must have changed. Maybe accidentally (a recent NW server crash, a
change on the DNS...?)

If the saveset is saved but the index is removed, then you may be experiencing
some client identity issue.

Have you tried running
nsrim -X (once)
nsrck -L6 (3 times)

(that didn't work for me ehan I had a similar problem but the followig
procedure produced some warnings about an old client name and worked for me
fine with just one client:
- remove both clients (remove the index folders too)
- recreate both clients using the existing clientID's but with a resolvable
dummy client name each (e.g. "dummy1" and "dummy2" -- you will need to
create two fake entries on the /etc/hosts *before* you attempt to create the
dummy client definitions).
- remove the dummy definitions
- recreate the clients with the original names (i.e. use original
client_name/clientID values)

jee



Tuesday 27 September 2011 18:55:28 Michael Leone wrote:
Here's a weird one .. I have 2 clients (both virtual cluster clients),
both with browse and retention policies of 2 months, who have their
indexes either completely deleted (i.e., the index sub-folder for that
client is 0K), or it only has the previous day's activity. These are both
backups made with the SQL Module. Neither client nor job has changed in at
least months, perhaps longer.

Even weirder - this seems to happen on every weekday. The index backup (we
do "savegrp -O") on Sat morning - which would have the index from the
Friday backup - would be there. And that would be the only index backup
that wasn't empty.

mminfo -avot -q

"client=networker-server,name=index:client,savetime>09/01/2011" -r
volume,client,ssid,name,level,savetime(22),totalsize(2)

volume client ssid name lvl
date time total
006792 networker-server 1667207181 index:client full 9/1/2011
10:00:45 AM 32 KB
006872 networker-server 1298192353 index:client full 9/2/2011
9:19:29 AM 32 KB
006872 networker-server 2825005238 index:client full 9/3/2011
9:16:38 AM 10 MB

I wouldn't have noticed it, except that I needed to do a recover, and I
couldn't because it said there had been no files backed up (which I knew
to be false).
(that snippet is for earlier in the month, but it's the same all month)

"nsrls" shows the total size of the index to be zero
"nsrck -L6" shows no errors, and a total size of zero
"nsrck -L7" reads back in zero (unless I specify one of the Saturday
backups, like 9/3/2011 above)

Note that the groups that these 2 clients are in are set to "no index
save", like all our groups. I have 130 clients, and am only seeing this
problem on these 2. One client is a clone job, one is not.
EMC seems to be confused, as well.

Thoughts, anyone? I am going to uncheck the "No index save" temporarily on
these groups. Can anyone suggest something else to diagnose?

Thanks


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

Indexes (the directory with the db6 files and the files) never go
away. Even if you delete the client. Even if all backups for the client
have expired. For the indexes to go away someone need to go and actively
remove them (with an rm command or similar).

On 09/27/11 20:55, Michael Leone wrote:
Here's a weird one .. I have 2 clients (both virtual cluster clients),
both with browse and retention policies of 2 months, who have their
indexes either completely deleted (i.e., the index sub-folder for that
client is 0K), or it only has the previous day's activity. These are both
backups made with the SQL Module. Neither client nor job has changed in at
least months, perhaps longer.

Even weirder - this seems to happen on every weekday. The index backup (we
do "savegrp -O") on Sat morning - which would have the index from the
Friday backup - would be there. And that would be the only index backup
that wasn't empty.

mminfo -avot -q
"client=networker-server,name=index:client,savetime>09/01/2011" -r
volume,client,ssid,name,level,savetime(22),totalsize(2)

volume client ssid name lvl
date time total
006792 networker-server 1667207181 index:client full 9/1/2011
10:00:45 AM 32 KB
006872 networker-server 1298192353 index:client full 9/2/2011
9:19:29 AM 32 KB
006872 networker-server 2825005238 index:client full 9/3/2011
9:16:38 AM 10 MB

I wouldn't have noticed it, except that I needed to do a recover, and I
couldn't because it said there had been no files backed up (which I knew
to be false).
(that snippet is for earlier in the month, but it's the same all month)

"nsrls" shows the total size of the index to be zero
"nsrck -L6" shows no errors, and a total size of zero
"nsrck -L7" reads back in zero (unless I specify one of the Saturday
backups, like 9/3/2011 above)

Note that the groups that these 2 clients are in are set to "no index
save", like all our groups. I have 130 clients, and am only seeing this
problem on these 2. One client is a clone job, one is not.
EMC seems to be confused, as well.

Thoughts, anyone? I am going to uncheck the "No index save" temporarily on
these groups. Can anyone suggest something else to diagnose?

Thanks



--

-- Yaron.


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

The records that contain those indices under the index folders can go away.


On Tuesday 27 September 2011 21:11:04 Yaron Zabary wrote:
Indexes (the directory with the db6 files and the files) never go
away. Even if you delete the client. Even if all backups for the client
have expired. For the indexes to go away someone need to go and actively
remove them (with an rm command or similar).

On 09/27/11 20:55, Michael Leone wrote:
Here's a weird one .. I have 2 clients (both virtual cluster clients),
both with browse and retention policies of 2 months, who have their
indexes either completely deleted (i.e., the index sub-folder for that
client is 0K), or it only has the previous day's activity. These are
both backups made with the SQL Module. Neither client nor job has changed
in at least months, perhaps longer.

Even weirder - this seems to happen on every weekday. The index backup
(we do "savegrp -O") on Sat morning - which would have the index from the
Friday backup - would be there. And that would be the only index backup
that wasn't empty.

mminfo -avot -q

"client=networker-server,name=index:client,savetime>09/01/2011" -r
volume,client,ssid,name,level,savetime(22),totalsize(2)

volume client ssid name
lvl date time total
006792 networker-server 1667207181 index:client full 9/1/2011
10:00:45 AM 32 KB
006872 networker-server 1298192353 index:client full 9/2/2011
9:19:29 AM 32 KB
006872 networker-server 2825005238 index:client full 9/3/2011
9:16:38 AM 10 MB

I wouldn't have noticed it, except that I needed to do a recover, and I
couldn't because it said there had been no files backed up (which I knew
to be false).
(that snippet is for earlier in the month, but it's the same all month)

"nsrls" shows the total size of the index to be zero
"nsrck -L6" shows no errors, and a total size of zero
"nsrck -L7" reads back in zero (unless I specify one of the Saturday
backups, like 9/3/2011 above)

Note that the groups that these 2 clients are in are set to "no index
save", like all our groups. I have 130 clients, and am only seeing this
problem on these 2. One client is a clone job, one is not.
EMC seems to be confused, as well.

Thoughts, anyone? I am going to uncheck the "No index save" temporarily
on these groups. Can anyone suggest something else to diagnose?

Thanks


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

Something must have changed. Maybe accidentally (a recent NW server
crash,

No.

a change on the DNS...?)

No.

If the saveset is saved but the index is removed, then you may be
experiencing
some client identity issue.

Have you tried running
nsrim -X (once)
nsrck -L6 (3 times)

Yes.


(that didn't work for me ehan I had a similar problem but the followig
procedure produced some warnings about an old client name and worked for
me
fine with just one client:
- remove both clients (remove the index folders too)
- recreate both clients using the existing clientID's but with a
resolvable
dummy client name each (e.g. "dummy1" and "dummy2" -- you will need to
create two fake entries on the /etc/hosts *before* you attempt to
create the
dummy client definitions).
- remove the dummy definitions
- recreate the clients with the original names (i.e. use original
client_name/clientID values)

I hesitate to do something so drastic just yet, and without direct
instruction from EMC support.

I just checked, and told the GUI SQL recover to do a NORMAL restore. Then
I told it to change Browse time. And it showed *just* last night's backup,
9/27/2011, in the list of backup versions to choose. If I clicked on
"Browse Time", it said "Time range must be between 9/27/2011 21:35 and
9/27/2011 21:35". Apparently that's all it thinks is there.

And yet ....

mminfo -avot -q "client=pssql3,name=MSSQL:,savetime>09/23/2011" -r
name,totalsize(2),ssid,savetime(22),ssbrowse(22)
name total ssid date time browse time
MSSQL: 265 GB 3833408418 9/23/2011 9:00:18 PM
11/23/2011 11:59:59 PM
MSSQL: 6151 MB 3229430570 9/23/2011 9:32:21 PM
11/23/2011 11:59:59 PM
MSSQL: 3284 KB 3145544545 9/23/2011 9:33:20 PM
11/23/2011 11:59:59 PM
MSSQL: 3093 KB 3128767331 9/23/2011 9:33:23 PM
11/23/2011 11:59:59 PM
MSSQL: 1495 KB 3111990118 9/23/2011 9:33:25 PM
11/23/2011 11:59:59 PM
MSSQL: 14 MB 3078435688 9/23/2011 9:33:27 PM
11/23/2011 11:59:59 PM
MSSQL: 440 B 3061658477 9/23/2011 9:33:31 PM
11/23/2011 11:59:59 PM
MSSQL: 265 GB 1249976353 9/26/2011 9:00:17 PM
11/26/2011 11:59:58 PM
MSSQL: 6395 MB 176236403 9/26/2011 9:31:22 PM
11/26/2011 11:59:59 PM
MSSQL: 3604 KB 159459244 9/26/2011 9:32:27 PM
11/26/2011 11:59:59 PM
MSSQL: 3093 KB 142682030 9/26/2011 9:32:29 PM
11/26/2011 11:59:59 PM
MSSQL: 1496 KB 125904816 9/26/2011 9:32:31 PM
11/26/2011 11:59:59 PM
MSSQL: 15 MB 109127602 9/26/2011 9:32:34 PM
11/26/2011 11:59:59 PM
MSSQL: 440 B 92350390 9/26/2011 9:32:37 PM
11/26/2011 11:59:59 PM
MSSQL: 265 GB 729969055 9/27/2011 9:00:14 PM
3/27/2012 11:59:59 PM
MSSQL: 6674 MB 3699538309 9/27/2011 9:33:54 PM
3/27/2012 11:59:59 PM
MSSQL: 3668 KB 3598875071 9/27/2011 9:34:55 PM
3/27/2012 11:59:59 PM
MSSQL: 3093 KB 3582097857 9/27/2011 9:34:57 PM
3/27/2012 11:59:59 PM
MSSQL: 1496 KB 3565320644 9/27/2011 9:34:59 PM
3/27/2012 11:59:59 PM
MSSQL: 15 MB 3548543430 9/27/2011 9:35:02 PM
3/27/2012 11:59:59 PM
MSSQL: 440 B 3531766218 9/27/2011 9:35:05 PM
3/27/2012 11:59:59 PM

Here we see SQL databases being backed up before 9/27/2011, with browse
time at least 2 months in the future (I changed browse time to 6 months
yesterday, thinking perhaps that changing it would kick something loose
and maybe make it start to work). Yet I can't browse to them, to do a
restore.

If I do a mminfo for the actual index, I see entries that seem the same
size, for 9/27 and before (and a large one for Friday night that I
recovered, which would be a non-SQL files backup ...). Every night we do
SQL backups, and regular filesystem backups, from this client, so I guess
that's why a normal night's index is 700-800K. But I don't know how to
check the contents of the index, to see what files those records pertain
to. Apparently, they don't pertain to the SQL backups listed above, since
I couldn't browse to a SQL backup before 9/27/2011.

mminfo -avot -q "name=index:pssql3,savetime>09/22/2011" -r
name,totalsize(2),ssid,savetime(22),ssbrowse(22)
name total ssid date time browse time
index:pssql3 796 KB 2205891239 9/22/2011 9:39:51 AM
11/22/2011 11:59:59 PM
index:pssql3 851 KB 1232900019 9/23/2011 9:54:59 AM
11/23/2011 11:59:59 PM
index:pssql3 12 MB 3263030167 9/24/2011 10:05:11 AM
11/24/2011 11:59:59 PM
index:pssql3 820 B 2206238424 9/26/2011 10:06:16 AM
11/26/2011 11:59:59 PM
index:pssql3 731 KB 2004997867 9/27/2011 10:00:11 AM
11/27/2011 11:59:59 PM


There is an index backup going on right now, as a matter of fact - we do
it daily at 9AM - so I will check back later, and see if the index is
still there ...

The other client I was having trouble with, the one where the index was
actually zero, has been offline for a couple days now (hardware failure).
So I can't do anything more with it ...


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

Michael,

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.

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


BTW - to verify the contents of an index use "nsrls -v -t [n]savetime client"

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.

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 } ]


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

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 } ]


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

Hi Michael,

it seems that we are are struggeling with command syntaxes.

1. My command
"nsrls -v -t [n]savetime client" should in fact read
"nsinfo -v -t [n]savetime client"

nsrls just reports the index size, not the contents.
Sorry for the confusion.


2. Your command seems to be wrong as well:

E:\nsr\bin>mminfo -a -r "name,ssid,ssb"
unknown report constraint: ssb
usage: mminfo [-avV] [-o order] [-s server] [-x exportspec] [report] [query] [volname...]

<report>: [ -m | -p | -B | -S | -X | -r reportspec ]
<query>: [-c client] [-N name] [-t time] [-q queryspec]

E:\nsr\bin>

The only hits i got from the Command Line Reference for "ssb" are
ssbrowse
ssbundle

However if you use "ssflags" instead will result in an output like yours. Another alternative would be "sumflags".

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

As is said - if NW does not delete the index, another operation must be responsible for it. Carefully look at cron jobs etc. Another possibility is to move the client's CFI to a new directory which can not be affected by any other job yet. Then just adjust the client's index path.

2. Your command seems to be wrong as well:

E:\nsr\bin>mminfo -a -r "name,ssid,ssb"

Line cut off when pasting into email, that's all. It originally said
"ssbrowse(22)".

As is said - if NW does not delete the index, another operation must
be responsible for it. Carefully look at cron jobs etc.

None.

Another possibility is to move the client's CFI to a new directory which
can
not be affected by any other job yet. Then just adjust the client's
index path.

EMC wants me to save the clientid; delete the client; move the index
directory; recreate client using same clientid. We'll see ...


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

On 29/09/11 19:06, Michael Leone wrote:

2. Your command seems to be wrong as well:

E:\nsr\bin>mminfo -a -r "name,ssid,ssb"

Line cut off when pasting into email, that's all. It originally said
"ssbrowse(22)".

As is said - if NW does not delete the index, another operation must
be responsible for it. Carefully look at cron jobs etc.

None.

Another possibility is to move the client's CFI to a new directory which
can
not be affected by any other job yet. Then just adjust the client's
index path.

EMC wants me to save the clientid; delete the client; move the index
directory; recreate client using same clientid. We'll see ...

They might be right, but I wouldn't do that without first establishing
whether or not that is the problem.


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

On Thursday 29 September 2011 20:01:50 Davina Treiber wrote:
On 29/09/11 19:06, Michael Leone wrote:


EMC wants me to save the clientid; delete the client; move the index
directory; recreate client using same clientid. We'll see ...

They might be right, but I wouldn't do that without first establishing
whether or not that is the problem.


And how can they determine the nature of the problem if they don't try doing
that (and other troubleshooting tests)? This is not behaving as expected and
hence the only way to know what's going on is by doing some tests.
Index issues are most likely caused by probles related to resolution and
clientID's.


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER