Re: [ADSM-L] Change rate performance question
2010-10-27 01:07:13
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.
|
|
|