"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
Timothy.Hughes AT OIT.STATE.NJ DOT US
Sent by: ADSM-L AT VM.MARIST DOT EDU
07/24/2008 10:47 AM
Please respond to
ADSM-L AT VM.MARIST DOT 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
>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.
>
>
|
