Everyone,
Thanks for the ideas. I have considered the incrbydate and was concerned with
the problem that Grigori mentions below. I have tried to sell management on
Fastback as well, but cannot get them to cough up the money for it.
As an update...
Doing some further investigation I have found that we are completely saturating
the network for about 4 hours every night. So we are looking at some networking
solutions.
Also, from reading some posts about systemstate in windows 2008, we excluded
the systemstate from backup last night on 2 of our problem servers and the
backup time reduced from about 7 hours to 13 minutes.
Again, thanks for your responses and ideas.
cory
Cory L Heikel
Tivoli Systems Administrator
Penn State Hershey Medical Center
(717)531-7972
The opposite of stress is Options...
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT vm.marist DOT edu] On Behalf Of
Grigori Solonovitch
Sent: Wednesday, October 27, 2010 1:05 AM
To: ADSM-L AT vm.marist DOT edu
Subject: Re: Change rate performance question
But keep in mind http://www-01.ibm.com/support/docview.wss?uid=swg1IC50766.
Incrbydate is not reliable enough. You can easily loose files, if server is
active during -incrbydate.
Grigori G. Solonovitch
Senior Technical Architect
Information Technology Ahli United Bank Kuwait http://www.ahliunited.com.kw
Phone: (+965) 2231-2274 Mobile: (+965) 99798073 E-Mail: Grigori.Solonovitch
AT ahliunited DOT com
Please consider the environment before printing this Email
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Roger Deschner
Sent: Wednesday, October 27, 2010 7:55 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Change rate performance question
We have one machine with a very high change rate like this. We are successfully
using -incrbydate on weekdays, and a regular incremental every weekend to catch
up - exactly as suggested in the TSM manuals.
It's made a big difference.
Roger Deschner University of Illinois at Chicago rogerd AT uic DOT edu
=== Allergy Warning: Produced in a facility that processes peanuts. ====
=================== -- warning on a sack of peanuts ====================
On Wed, 27 Oct 2010, Xav Paice wrote:
>----- "cory heikel" <cheikel AT HMC.PSU DOT EDU> wrote:
>
>> I have many clients with an average daily change rate of over 50%.
>> Most of these clients take several hours to back up and show a high
>> percentage of wait time in the summary table. My question is this:
>> Would it make sense for these clients to be backed up full each day
>> instead of incremental?
>>
>
>Without more detail, I'd suggest trying an online image backup of some
>selected clients and see what difference it makes. You might find, however,
>that there are pros and cons for image vs incremental - in terms of storage
>used, performance of other operations during backup, and ability to restore
>individual files.
>
>You could also consider using -incrbydate - just so long as you regularly do a
>'normal' incremental since -incrbydate misses deleted files and isn't the most
>secure option.
>
>Where is the delay though - have you looked at the instrumentation to
>determine if it really is filesystem scanning that is the slow bit?
>
Please consider the environment before printing this Email.
CONFIDENTIALITY AND WAIVER: The information contained in this electronic mail
message and any attachments hereto may be legally privileged and confidential.
The information is intended only for the recipient(s) named in this message. If
you are not the intended recipient you are notified that any use, disclosure,
copying or distribution is prohibited. If you have received this in error
please contact the sender and delete this message and any attachments from your
computer system. We do not guarantee that this message or any attachment to it
is secure or free from errors, computer viruses or other conditions that may
damage or interfere with data, hardware or software.
|
