Backup Central

On 29/09/11 21:56, jee wrote:
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.


It should be evident by checking client IDs from mminfo reports and
client configs.


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

On 2011-09-29 14: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 ...


Are either of these two clients, or rather any user on those two
clients, listed under the User Groups under nmc? If so, what privileges
do they have? For example, do they have the Operate NetWorker option
checked? What about the administrators?

Have you read through the EMC documentation for the SQL module, maybe
somewhere it talks about indexes and how the SQL client works with the
indexes on the server?

What about flat file (non-SQL module) backups of non-SQL data on those
two hosts? Do those CFI entries also get removed?

George


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

What about flat file (non-SQL module) backups of non-SQL data on those
two hosts? Do those CFI entries also get removed?

Yes.

The one client, where ALL the index records were gone, has finally been
rebuilt, and new backups will start tonight. Since it was rebuilt as a
physical client (not a virtual cluster client), I had to install the NW
client and SQL Module new. SO we'll see if that makes any difference.

For good measure, I did the same to the other client, that was retaining
only 1 day of indexes. I'm leaving early today and am away all weekend, so
I'll pick up next week.


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

Is the time on the client OK ? The time of the saveset is taken from
the client, so that can cause early expiry of savesets of even an error
message.

On 09/27/2011 08:55 PM, 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

On Thursday 29 September 2011 21:59:51 Davina Treiber wrote:
On 29/09/11 21:56, jee wrote:
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.

It should be evident by checking client IDs from mminfo reports and
client configs.

Not at all evident.
In my case (this happened 1 year ago) I removed the offending client and when
I tried to recreate it with the same name NW produced a warning because the
same clientId was already linked to a different hostname ( it had been
renamed a few months earlier by another admin). Apparently some crash had
also occurred in the past and that could have left the system in some
inconsistent state. So, no, not at all evident.


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

Is the time on the client OK ? The time of the saveset is taken from
the client, so that can cause early expiry of savesets of even an error
message.


Yes, it's correct. All Windows domain servers by default synchronize to
the domain controller.


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

From: Davina Treiber <Davina.Treiber < at > PEEVRO.CO.UK>

It should be evident by checking client IDs from mminfo reports and
client configs.


The clientID does match from the mminfo reports and the client config.


At this point, I am going to try EMC's suggestion: save the client ID;
delete the client; move the index folder of the client out of the way;
create new client with old client ID.


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

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.

No, but it was a client definition problem ...

The problem was caused by an alias. On my client PSSQL3, it had an alias
of PSFILE3. PSSQL1 had an alias of PSFILE1.

Both of these (PSSQL3, PSFILE3) are virtual clients resources of a MS
cluster. PSFILE3 used to be a physical client, which was replaced (months
ago) with a cluster resource with the same name and IP. EMC Tech Support
told us to add PSFILE3 as an alias of the other cluster resource, and that
would make it all Just Work.

This turns out to be a BAD idea ... while the backups would work, the
index cleanup would remove all history later than the most recent backup.
And we never knew, since we hardly ever have to do restores of these
things ...

So now Tech Support had me create separate clients for PSSQL3 and PSFILE3
(with a combination of making temporary dummy client names, and re-using
the respective clientid, and then renaming accordingly).

Same issue existed for the other SQL client having the issue - PSSQL1 also
had an alias of PSFILE1 (same situation). Luckily, PSFILE1 got retired a
few weeks ago (nobody told me about that ..) so all I had to do to fix
that one was remove the PSFILE1 alias from PSSQL1. And so PSSQL1 is
working as it should.

And now I see multiple days history for each of the 3 clients (PSSQL1,
PSSQL3, PSFILE3). Granted, it only goes back to yesterday morning, when we
finally fixed the problem, but at least I see than just last night's
backup as restore choices (I see last night, and the night before).

So the moral of the story ... watch those aliases! And have a separate NW
client for every named cluster resource, regardless of what anyone tells
you will work ...


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

On 10/14/11 14:11, Michael Leone wrote:
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.

No, but it was a client definition problem ...

The problem was caused by an alias. On my client PSSQL3, it had an alias
of PSFILE3. PSSQL1 had an alias of PSFILE1.

Both of these (PSSQL3, PSFILE3) are virtual clients resources of a MS
cluster. PSFILE3 used to be a physical client, which was replaced (months
ago) with a cluster resource with the same name and IP. EMC Tech Support
told us to add PSFILE3 as an alias of the other cluster resource, and that
would make it all Just Work.

This turns out to be a BAD idea ... while the backups would work, the
index cleanup would remove all history later than the most recent backup.
And we never knew, since we hardly ever have to do restores of these
things ...

So now Tech Support had me create separate clients for PSSQL3 and PSFILE3
(with a combination of making temporary dummy client names, and re-using
the respective clientid, and then renaming accordingly).

Same issue existed for the other SQL client having the issue - PSSQL1 also
had an alias of PSFILE1 (same situation). Luckily, PSFILE1 got retired a
few weeks ago (nobody told me about that ..) so all I had to do to fix
that one was remove the PSFILE1 alias from PSSQL1. And so PSSQL1 is
working as it should.

And now I see multiple days history for each of the 3 clients (PSSQL1,
PSSQL3, PSFILE3). Granted, it only goes back to yesterday morning, when we
finally fixed the problem, but at least I see than just last night's
backup as restore choices (I see last night, and the night before).

So the moral of the story ... watch those aliases! And have a separate NW
client for every named cluster resource, regardless of what anyone tells
you will work ...


Shockingly bad advice from EMC Support - they of all people should know
how to configure cluster clients


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