ADSM-L

Re: Client Slow Backing up...

2003-04-23 13:53:03
Subject: Re: Client Slow Backing up...
From: "Magura, Curtis" <curtis.magura AT LMCO DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 23 Apr 2003 13:47:06 -0400
John,

Take a look at the setting PreserverDBOnExit in tsmjbbd.ini

     PreserverDBOnExit
;
;          A value of 1 indicates that the journaled file system journal
database
;          will not be deleted when the journal file system goes offline and
;          will be valid when the journal file system comes back online.
;
;          This value should be used with caution as any file system change
;          activity which occurs while the journaled file system is offline
;          will not be reflected in the journal database.
;
;          The default setting is 0 (delete journal db on exit).


Might be something that you want to consider.

Curt Magura
Lockheed Martin EIS
Orlando Fla.
321-235-1203


-----Original Message-----
From: Talafous, John G. [mailto:Talafous AT TIMKEN DOT COM]
Sent: Wednesday, April 23, 2003 11:01 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Client Slow Backing up...

Hello Joni!
  My experience has been that this can be caused by an extraordinary number
of files on the client machine. Normal TSM backup must review each and every
file to determine if it has changed. At our installation, we have one
'packrat' that has over 450,000 files on his machine.  It takes a LONG, LONG
time to review the files and transfer data.
  A good alternative for this is the utilization of Journal Based Backup. By
configuring the TSM Journal service, a journal is kept that tracks client
file changes. This journal is kept on the client. Then, when backup occurs,
the journal is used to send only the changed files to the TSM server. I
think this was introduced somewhere around TSM 4.2 on the client machine.
  The only caveat I have found is that this works best for a machine that
does not re-boot often. (After reboot or when the TSM Journaling service is
stopped, all files must be reviewed.)  So forget it on a notebook. Works
well for application servers and desktop workstations that can be kept on.

Hope this helps,
John G. Talafous
Information Systems Technical Principal
Global Software Support - Data Management
telephone:  (330)-471-3390
e-mail:     talafous AT timken DOT com
http://www.ctnvm.inside.tkr/~talafous/
http://www.cis.corp.inside.tkr/networkstorage/




-----Original Message-----
From: Joni Moyer [mailto:joni.moyer AT HIGHMARK DOT COM]
Sent: Wednesday, April 23, 2003 8:00 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Client Slow Backing up...


Hi All!

I have notice that 2 of the NT clients that backup to TSM have been sitting
in IdleW for a very long time before committing their backups.  I don't
deal very much with the client side of things, I am just an administrator,
but I was wondering if anyone has seen this before?  Also, what may be
causing this?  Any suggestions?

Thanks in advance!!!!

Sess Number: 16,080
             Comm. Method: BPX-Tcp/Ip
               Sess State: IdleW
                Wait Time: 56.5 M
               Bytes Sent: 3.9 K
              Bytes Recvd: 813
                Sess Type: Node
                 Platform: WinNT
              Client Name: HMCH1132
      Media Access Status:
                User Name:
Date/Time First Data Sent:

              Sess Number: 16,081
             Comm. Method: BPX-Tcp/Ip
               Sess State: RecvW
                Wait Time: 12 S
               Bytes Sent: 458
              Bytes Recvd: 41.7 M
                Sess Type: Node
                 Platform: WinNT
              Client Name: HMCH1132
      Media Access Status:
                User Name:
Date/Time First Data Sent: 04/23/2003 07:00:19


Joni Moyer
Systems Programmer
joni.moyer AT highmark DOT com
(717)975-8338


**********************************************************************
This message and any attachments are intended for the
individual or entity named above. If you are not the intended
recipient, please do not forward, copy, print, use or disclose this
communication to others; also please notify the sender by
replying to this message, and then delete it from your system.

The Timken Company
**********************************************************************

<Prev in Thread] Current Thread [Next in Thread>