Hi Shawn,

Thanks for your reply!

We are hoping to use few tapes for backup sets also for our Novell
mailbox backup sets.

Our backup sets (weekly and monthly) are backing up specific file spaces
for example the commands below (2 is for the file space directory we
want to backup.

GENERATE BACKUPSET NOCHUGWC "Weeklynochubgwc" 2 DEVCLASS=3592CLASS
RETENTION=30 SCRATCH=YES DESCRIPTION="Wkly nochubgwc" WAIT=NO NAMETYPE=FSID

GENERATE BACKUPSET NOCHUGWC "Monthlynochubgwc" 2 DEVCLASS=3592CLASS
RETENTION=365 SCRATCH=YES DESCRIPTION="Mthly nochubgwc" WAIT=NO NAMETYPE=FS


I had a Point-in-Time command that I was going to test a backupset to
backup the data from Monday to Friday

GENERATE BACKUPSET NOCHUGWN "Wklyhugwn pit" 1 DEVCLASS=3592CLASS
RETENTION=30 SCRATCH=YES DESCRIPTION="backupset for Wkly nochubgwn using
pit" WAIT=NO NAMETYPE=FSID pitdate=today -5 pittime=00:00:00 datatype=file

I have changed it to the following ( I would like this command to start
automatically on friday using a admin schedule if possible)

Gen backupset nochugwn 1 devclass=3592 ret=30 scratch=yes pitd=07/14/2008
pitt=7:00:00


Which uses fewer tapes Point-in-Time backupsets or Multiple Nodes
backupsets? And
Are there any disadvantages to using the TOC=Y Parameter?

Feel free to add comments or suggestions to any of this.

Thanks again
regards,
Tim


Shawn Drew wrote:

I am currently in the process of performing hundreds of these backupsets.

gen backupset CORE-TSM13 2007YE dev=I2K_LTO3 RET=2562 pitd=01/02/2008
pitt=15:00:00 TOC=y

I'm also using nodegroups to stack multiple backupsets onto fewer tapes,
so it is using remarkably few tapes.

Regards,
Shawn
________________________________________________
Shawn Drew




Internet
Timothy.Hughes AT OIT.STATE.NJ DOT US

Sent by: ADSM-L AT VM.MARIST DOT EDU
07/23/2008 02:24 PM
Please respond to
ADSM-L AT VM.MARIST DOT EDU


To
ADSM-L
cc

Subject
Re: [ADSM-L] GENERATE BACKUPSET speed question





Anyone using the New Point-In-Time Backup Set method? If so can you
share an example of one of your commands. Also
does it seem to use many Tapes?

Thanks

Sung Lee wrote:

Just to provide you with some stat information

backup set generation without table to 3592 took about 6 hours to process
577 GB with 8.5 million items.
The most of our data are collocated.

I would think that if you have a huge TSM DB and data is on many tapes

not

collocated there would be alot of processing that goes into it.
Since you didn't mention what LTO drives (I will assume you are using
LTO1).  Let's say LTO1 has max write speed of 15 MB/s that is 54 GB/h. So
to write 50 GB should have taken about an hour in perfect working
condition.

Could it be tape drive issue?


Thanks,

Sung Y.  Lee



David Longo <David.Longo AT HEALTH-FIRST DOT ORG>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
07/22/2008 11:32 AM

Please respond to
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>


To
ADSM-L AT VM.MARIST DOT EDU
cc

Subject
[ADSM-L] GENERATE BACKUPSET speed question






I have TSM server 5.4.3.0 with IBM 3584 Tape library with LTO drives.
I have never used Generate Backupset and decided to do some
testing to see how long it takes to create, for instance.

I am using LTO tape for the backupset, and using one entire
node, not individual filespaces and use toc=no.
In 2 days with several nodes, I have gotten basically nowhere.
In 6 hours it has "generated" just a couple of GB of data of
total requirement of about 50GB.

From watching stats with "q process", it seems that one or both

of the following are happening:

A.  It is scanning the entire TSM DB for what is needed, instead of
just that nodes data.

and/or

B.  When it mounts an input tape, it is reading the entire tape instead
of just "seeking" to where the required data is.

I have no performance issues otherwise with tapes, TSM DB or
backups/restores.

Could someone shed some light on this slowness issue and how
to speed it up?

Thanks,
David Longo



#####################################
This message is for the named person's use only.  It may
contain private, proprietary, or legally privileged information.
No privilege is waived or lost by any mistransmission.  If you
receive this message in error, please immediately delete it and
all copies of it from your system, destroy any hard copies of it,
and notify the sender.  You must not, directly or indirectly, use,
disclose, distribute, print, or copy any part of this message if you
are not the intended recipient.  Health First reserves the right to
monitor all e-mail communications through its networks.  Any views
or opinions expressed in this message are solely those of the
individual sender, except (1) where the message states such views
or opinions are on behalf of a particular entity;  and (2) the sender
is authorized by the entity to give such views or opinions.
#####################################

ForwardSourceID:NT0000DCDE

This message and any attachments (the "message") is intended solely for
the addressees and is confidential. If you receive this message in error,
please delete it and immediately notify the sender. Any use not in accord
with its purpose, any dissemination or disclosure, either whole or partial,
is prohibited except formal approval. The internet can not guarantee the
integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will)
not therefore be liable for the message if modified. Please note that certain
functions and services for BNP Paribas may be performed by BNP Paribas RCC, Inc.