"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. > >
