Re: Backup of Win2`K Fileserver

2002-08-02 Thread Eric Gruber

This will not help with your possible network problems, however, you could rename the 
filespace to the appropriate unc name.
You probably want to rename the existing filespace to \\servername\driveletter$_old 
first.

Eric

-Original Message-
From: Guillaume Gilbert [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 31, 2002 4:31 PM
To: [EMAIL PROTECTED]
Subject: Backup of Win2`K Fileserver


Hello

I have a BIG performance problem with the backup of a win2k fileserver. It used to be 
pretty long before but it was managable. But now the sysadmins put it on a compaq
storageworks SAN. By doing that they of course changed the drive letter. Now it has to 
do a full backup of that drive. The old drive had  1,173,414 files and 120 GB  of
data according to q occ. We compress at the client. We have backup retention set to 
2-1-NL-30. The backup had been running for 2 weeks!!! when we cancelled it to try to
tweak certain options in dsm.opt. The client is at 4.2.1.21 and the server is at 4.1.3 
(4.2.2.7 in a few weeks). Network is 100 mb. I know that journal backups will help
but as long as I don't get a full incremental in it doesn't do me any good. Some of 
the settings in dsm.opt :

TCPWindowsize 63
TxnByteLimit 256000
TCPWindowsize 63
compressalways yes
RESOURceutilization 10
CHAngingretries 2

The network card is set to full duplex. I wonder if an FTP test with show some 
Gremlins in the network...?? Will try it..

I'm certain the server is ok. It's a F80 with 4 processors and 1.5 GB of RAM, though I 
can't seem to get the cache hit % above 98. my bufpoolsize is 524288. DB is 22 GB
73% utilized.

I'm really stumped and I would appreciate any help

Thanks

Guillaume Gilbert



Re: Troubles, troubles, troubles.

2002-06-08 Thread Eric Gruber

Are you having client connection severed messages in the actlog?  How long is does 
this clients backup take compared with the idletimout setting on the server.  You 
could be losing the control session, so even if the data session completes, it will 
not report correctly.  I have also seen this problem hose the client scheduler.

Eric

-Original Message-
From: Bern Ruelas [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 07, 2002 11:51 PM
To: [EMAIL PROTECTED]
Subject: Re: Troubles, troubles, troubles.


Rick,

We had the same problem that went away with 4.1.1.11.

-Bern Ruelas
Sr. Systems Engineer - Storage
Cadence Design Systems



-Original Message-
From: Rushforth, Tim [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 07, 2002 8:44 PM
To: [EMAIL PROTECTED]
Subject: Re: Troubles, troubles, troubles.


Try running manual backup, does client abend?  Can you narrow down the
directories backed up to determine if it is one bad file/location on disk

Check for drwatson log files.

I've seen this happen on a bad sector of disk which chkdsk fixed.

-Original Message-
From: Rick Harderwijk [mailto:[EMAIL PROTECTED]]
Sent: June 6, 2002 7:11 AM
To: [EMAIL PROTECTED]
Subject: Troubles, troubles, troubles.

Hi all,

One of my servers is giving me a major headache at the moment. Every morning
when I come in, I check, as anyone does, I presume, whether all scheduled
backups completed succesfully. The past couple of days, one of my servers
doesn't complete, nor does it fail. Or so it tells me, because the result of
the scheduled backup is '(?)' . Nice, isn't it?

Since I'm not going to lay awake all night because of one backup, I decided
the first time it happened, to just let it go. 'It'll all be better
tomorrow,', I told myself. Unfortunately, it didn't get better. Nope, the
same thing happened the next night, and the one after.

So, this morning, I started to check if there was a serious glitch. So I
checked the dsmsched.log on the client. Strange thing... it sent a file,
then it gets a new schedule. It feels as if something is missing here. Next,
I checked the dsierror.log. Three entries here:

06-06-2002 03:52:27 sessOpen: Error 137 from signon authentication.
06-06-2002 03:53:30 sessOpen: Error 137 from signon authentication.
06-06-2002 03:54:33 sessOpen: Error 137 from signon authentication.

Messages like that make me pop out a fresh browser window, call up
www.adsm.org and go looking for that message... as it turns out 'this
message just is there, can be ignored and will go away in the next couple of
upgrades'. So, not very helpful *but* it also tells me this message
occurs when the Scheduler service starts. Now there's something I can do
something with.

Opening up ye olde Eventlog on that same W2k-client tells me that indeed, at
that time, the Scheduler Service was started - it had stopped just before,
and since we've had some problems with earlier versions with services just
quitting on us, the services are automatically restarted when they go down.

As it turns out, the backup stopped when the service crashed and when the
service came back, it just got a new schedule and the backup in progress
stopped and never continued.

It seems to me that all I have to fix is that darned Scheduler Service.

But where to start?
Why does it stop?
Where to look for more clues?

And ofcourse: why me? :-)

Anyone care to join me and hunt this bugger down to fix it once and for all?
You're most welcome - I feel like I'm on a dead end trail... and that
headache is keeping me from thinking clearly...

Kind regards,

Rick Harderwijk
Systems Administrator
Factotum Media BV
Oosterengweg 44
1212 CN Hilversum
P.O. Box 335
1200 AH Hilversum
The Netherlands
Tel: +31-35-6881166
Fax: +31-35-6881199
E: [EMAIL PROTECTED]



Re: Can't do reclamation

2002-06-05 Thread Eric Gruber

Hi Max,

Is this all the volumes in this storage pool?  At first glance it would seem that you 
have no scratch tapes available to perform reclamation with.

Yours Truly,

Eric

-Original Message-
From: Max Kwong [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 05, 2002 10:41 PM
To: [EMAIL PROTECTED]
Subject: Re: Can't do reclamation


Hi all,

Thanks for all reply. Here is the details of the storage pool that can't perform
reclamatoin.

Volume Name   Storage  Device  EstimatedPct   Volume
  Pool NameClass Name   Capacity   Util   Status
(MB)
--- --
-  -  
FP0018FILE_PTPOOL  3590CLASS2   21,271.10.1Full
FP0024FILE_PTPOOL  3590CLASS2   21,177.20.0Full
FP0025FILE_PTPOOL  3590CLASS2   22,015.40.0Full
FP0026FILE_PTPOOL  3590CLASS2   21,700.40.0Full
FP0027FILE_PTPOOL  3590CLASS2   21,324.94.3Full
FP0028FILE_PTPOOL  3590CLASS2   21,091.50.0Full
FP0029FILE_PTPOOL  3590CLASS2   21,160.00.0Full
FP0030FILE_PTPOOL  3590CLASS2   21,141.00.0Full
FP0031FILE_PTPOOL  3590CLASS2   21,185.00.0Full

The followin is the result of q stgp file_ptpool f=d

 Storage Pool Name: FILE_PTPOOL
   Storage Pool Type: Primary
   Device Class Name: 3590CLASS2
 Estimated Capacity (MB): 2,051,004,907,651.1
Pct Util: 0.0
Pct Migr: 0.0
 Pct Logical: 100.0
High Mig Pct: 99
 Low Mig Pct: 99
 Migration Delay: 0
  Migration Continue: Yes
 Migration Processes:
   Next Storage Pool:
Reclaim Storage Pool:
  Maximum Size Threshold: No Limit
  Access: Read/Write
 Description:
   Overflow Location:
   Cache Migrated Files?:
  Collocate?: No
   Reclamation Threshold: 80
 Maximum Scratch Volumes Allowed: 99,999,999
   Delay Period for Volume Reuse: 0 Day(s)
  Migration in Progress?: No
Amount Migrated (MB): 0.00
Elapsed Migration Time (seconds): 0
Reclamation in Progress?: No
 Volume Being Migrated/Reclaimed:
  Last Update by (administrator): ADMIN
   Last Update Date/Time: 04/29/02 11:44:41


l've already tried to update thereclamation thershold to 50% but it still no
reclaim process can be query.

Max







Gerald Wichmann [EMAIL PROTECTED] on 06/06/2002 12:37:17 AM

Please respond to ADSM: Dist Stor Manager [EMAIL PROTECTED]

To:   [EMAIL PROTECTED]
cc:(bcc: Max LH KWONG/LCSD/HKSARG)

Subject:  Re: Can't do reclamation



You'll need to provide more information then that.. be a lot more specific.
Specifically why can't you perform reclamation? Did you configure a
reclamation pool? Is it a problem in the configuration of the reclamation
pool? I recommend posting some details/output about the storage pool you're
trying to reclaim (q stg f=d) and the reclamation pool you have setup to do
the reclamation. Also post output on any errors you're getting as to why you
can't do it. The more info you provide the more likely someone can help you.

Regards,

Gerald Wichmann
Senior Systems Development Engineer
Zantaz, Inc.
925.598.3099 (w)

-Original Message-
From: Max Kwong [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 04, 2002 9:47 PM
To: [EMAIL PROTECTED]
Subject: Can't do reclamation

Hi all,

l have a storage pool can't peform the reclamation. It just only can use the
move data command to manually reclaim the tape. How can l solve this
problem?

Max



Re: Always full backup !!!! Please help

2002-05-22 Thread Eric Gruber

Is the copy mode in the backup copy group set to absolute or modified?

Eric

-Original Message-
From: Robert Ouzen [mailto:[EMAIL PROTECTED]]
Sent: Monday, May 20, 2002 7:06 AM
To: [EMAIL PROTECTED]
Subject: Always full backup  Please help


Hi

I have a Netware 5 with tivoli backup client 5.1.0.0 every backup I made
it's run FULL !!!
Despite that I run Incremental ... I made several test with the same
result always full backup.

Did anyone get a clue what can be the reason 

Regards Robert Ouzen



Re: reporting on backup successes/failures

2002-04-08 Thread Eric Gruber

Mark,

I believe the problem is that you are scheduling the command from the excfull.smp 
script which is shipped with the client.  This command is pasted from that script.

start /B tdpexcc backup * full /tsmoptfile=dsm.opt /logfile=excsch.log  excfull.log

When you run the start /B it opens a new command window so when you run a query event 
it shows that the schedule acually has completed becuase the script has completed by 
opening the new window.  Remove the Start /B and it should help you.  

Eric Gruber
TSM Certified Consultant TSM

-Original Message-
From: Mark Bertrand [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 08, 2002 9:03 AM
To: [EMAIL PROTECTED]
Subject: Re: reporting on backup successes/failures


Let me begin by saying that this rant is in no way meant to be directed to
Mark Stapleton, his advice has helped me many times and he is a great asset
to the group, he never hesitates to help.

Be aware, q event ONLY reports on the success or failure of the backup
script being ran, NOT the actual job.

Example: Last week the below method was used as it is everyday to check the
status of scheduled jobs and it reported the following.

04/05/2002 01:30:00 04/05/2002 02:01:54 130AM_EXCHANGE03_DB- EXCHANGE03_DB
Completed

But when you actually look into the job you still see it running as a
session.

Sess Comm. Sess Wait Bytes Bytes Sess Platform Client Name Number Method
State Time Sent Recvd Type -- -- -- -- --- --- -
  3,102 Tcp/Ip RecvW 0 S 8.0 K 11.6 G Node TDP
EXCHANGE03_DB MSExc- hgV2 NT

And the activity log only shows that the Directory completed, the
Information Store is still being backed up.

I spoke to level 2 support and I understand that q event only reports on the
script, he suggested that I need to put some kind of wait statement in the
script to not let it complete until the job actually completes.

I am not very happy with his suggestion, I am querying the event, I am not
running a q script!!! I don't want a Band-Aid, I just want a q event that
works!!!

Is there another solution within Tivoli to query the actual events?

BTW, we are running TSM 4.1.3 on W2K server and the example is for Exchange
TDP 2.2 on Exchange 5.5.

Thanks all,
Mark B.

-Original Message-
From: Mark Stapleton [mailto:[EMAIL PROTECTED]]
Sent: Sunday, April 07, 2002 10:39 PM
To: [EMAIL PROTECTED]
Subject: Re: reporting on backup successes/failures


On Tue, 5 Mar 2002 10:26:18 -0600, Glass, Peter
[EMAIL PROTECTED] wrote:

What would be the best way to produce a report that shows the number of
client backup successes vs. failures, for a given day?

This is not as hard as some folks seem to want to make it:

  q event * * begind=start_date endd=end_date

If you want it in script form:

  def script backup_check 'q event * * $1 $2  /tmp/backup_check'

You run it by inputting

  run backup_check 04/01/2002 04/03/2002

--
Mark Stapleton ([EMAIL PROTECTED])