Shawn thanks,
We will begin testing the Point-in-Time method first to see how that
works out. We may try Multiple Node backup sets for the individual file
spaces also. ( we are only doing backup sets for 3 nodes)
Regards,
Tim
Shawn Drew wrote:
"Which uses fewer tapes Point-in-Time backupsets or Multiple Nodes
backupsets? "
I don't think one has anything to do with the other. For example, we are
performing multiple-node, point-in-time backupsets. The answer to saving
tapes is, obviously, "it depends" Basically, it will use at least one
full tape for each "generate backupset" command. The key to saving tapes
is to backup as much data as possible under one command. (I.E. Multiple
nodes) If you are running commands to backup individual filespaces, that
is completely in the other direction. (I haven't tried backing up
multiple nodes with just one file space per node, I.E Specifying FSID=2
for every node in the nodegroup) I'm not sure that would be realistic.
"Are there any disadvantages to using the TOC=Y Parameter?"
I personally think the TOC is absolutely necessary for our NDMP and
Backupsets. If the TOC fails, I want the whole backup to fail, so I'll be
notified. Some might look at this as a disadvantage. If the Backupset
took a week to perform, and only the TOC creation failed, it will fail the
whole backupset. In the case of backupsets (As opposed to NDMP backups)
You can generate the TOC after the fact, so maybe for most people the
toc=y parameter is not necessary.
Regards,
Shawn
________________________________________________
Shawn Drew
Internet
[EMAIL PROTECTED]
Sent by: ADSM-L@VM.MARIST.EDU
07/24/2008 10:47 AM
Please respond to
ADSM-L@VM.MARIST.EDU
To
ADSM-L
cc
Subject
Re: [ADSM-L] GENERATE BACKUPSET speed question
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
[EMAIL PROTECTED]
Sent by: ADSM-L@VM.MARIST.EDU
07/23/2008 02:24 PM
Please respond to
ADSM-L@VM.MARIST.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 <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU>
07/22/2008 11:32 AM
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU>
To
ADSM-L@VM.MARIST.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.
