Re: anyone currently using or evaluating TSM FastBack
Larsa, Fastback doesn't work with 2008 yet, it's XP/2003 only (SP1 and up). Exchange 2007 works fine with 2003 64bit. Restoring public folders is no problem. I can restore data to another server also, as long as I have access on the domain & network. Restored items from Exchange do come back as unread, also the forward/reply icons are gone after a restore. Stefan -Oorspronkelijk bericht- Van: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Namens Lars-Erik Öhman Verzonden: maandag 1 december 2008 18:57 Aan: ADSM-L@VM.MARIST.EDU Onderwerp: Re: [ADSM-L] anyone currently using or evaluating TSM FastBack Do you use TSM Fastback with Windows 2008 and Exchange 2007? Are you able to restore public folders with this client? With TDP for Exchange I'm not able to do it, and we will need it for awhile before we can leave public folders behind. Can you restore the data to another server in some way? /Larsa -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Stefan Folkerts Sent: den 1 december 2008 08:08 To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] anyone currently using or evaluating TSM FastBack Yep, I am running it as a second backup tool next to Tivoli for Demo's (of Fastback) and to get the data outside every night without having to be or pass by the office. It's a nice product, it does what it say's it does, the interface could use some tuning, some icons are really small and the tiniest differences inside of these icons can indicate certain error states or activities that are currently runninga little fiddly but that all. It's really simple to get going and configure, within minutes it's all done, the client is just a dream to configure, all you do is point it to the server and that's it! :) All configuration is done on the server but even that is very limited, you can't exclude data, you either backup the partition/disk or you don't, the policies are extremely simplistic but are all you need for what the product does. It just works, makes me wonder why all software can't be this simple and just work. Exchange single item restore support runs thru Outlook, that's a little odd at first but it works nicely and IBM has made that interface better it seems going from 5.5.0.0 to 5.5.1.0. I am pleased with the product except for one issue...we need Windows 2008 support and we need it fast! :) Any questions about fastback, just post it here, I will try to answer them as good as I can. Regards, Stefan (works for IBM business partner ITAA.NL) -Oorspronkelijk bericht Van: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Namens Conway, Timothy Verzonden: donderdag 18 september 2008 17:01 Aan: ADSM-L@VM.MARIST.EDU Onderwerp: Re: [ADSM-L] anyone currently using or evaluating TSM FastBack There's no evaluation provided. List is USD1030.90 for 10 PVU of the basic product with exchange brick-level and bare-metal. It's the former "FilesX" product. We're torn between implementing it and waiting for the native brick-level exchange restores in TSM 6. Every Thursday this month at 15:30 UTC there's a demo. I understand this to be publically-available information, so I'll drop the information here. The next demo starts in half an hour. If this post causes a big flood and they have to limit participants, I imagine they might archive a demo and/or put on more of them. Call-in: 877-421-0528 USA Toll#: 770-615-1258 T/L: 421-0528 ITN: 2-421-0528 PC: 298419 Web Conference: www.sametimeunyte.com Conference ID 9663533 See details to configure system before Web Conference -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Laughlin, Lisa Sent: Tuesday, September 16, 2008 11:23 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] anyone currently using or evaluating TSM FastBack Hello all, Is anyone currently using or evaluating TSM FastBack? Was this an in-house (IBM) software or was it bought and adapted for TSM use - kind of like the AvePoint software for MS SharePoint? I hadn't heard of it before, but figured someone out there may have gotten their fingers into it. thanks! lisa __ Informatie van ESET NOD32 Antivirus, versie van database viruskenmerken 3452 (20080918) __ Het bericht is gecontroleerd door ESET NOD32 Antivirus. http://www.nod32.nl This communication is from a Carnegie company within the Carnegie Group. The information contained in it, including any attachment or enclosure, is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any unauthorised use, review, retransmissions, dissemination, copying or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete or shred the material immediately. Thank you. Opinions, c
Re: anyone currently using or evaluating TSM FastBack
True, the fastback exchange software is installed on a machine with outlook installed on it, it used the outlook connection to inject the objects back into exchange. Fastback exchange software does NOT run on the exchange server. On the exchange server you only have the default (one size fits all) fastback agent running that is the same for all windows clients and that client just let's you configure the fastback server via a >= 100Mb tcp/ip connection. -Oorspronkelijk bericht- Van: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Namens Mark Stapleton Verzonden: dinsdag 2 december 2008 19:54 Aan: ADSM-L@VM.MARIST.EDU Onderwerp: Re: [ADSM-L] anyone currently using or evaluating TSM FastBack From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Allen S. Rout > There was more than a little bit of smoke and mirrors, but it -looked- > as though that also worked on a per-message basis for exchange: > i.e. you only pulled down the blocks you needed for the message you > wanted back. That sounded very very keen. That is true. You can drag-n-drop individual items (messages, invites, etc.) back onto the Exchange server. One little "gotcha" that I'm not sure the doco is clear on--the Exchange piece of Fastback is not installed on the Exchange server. It's installed upon a proxy. -- Mark Stapleton ([EMAIL PROTECTED]) CDW Berbee
Re: anyone currently using or evaluating TSM FastBack
It's asynchronous, the software doesn't wait for the write to complete on the fastback server. -Oorspronkelijk bericht- Van: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Namens steve sorenson Verzonden: maandag 1 december 2008 20:20 Aan: ADSM-L@VM.MARIST.EDU Onderwerp: Re: [ADSM-L] anyone currently using or evaluating TSM FastBack Mark Stapleton said: >It has a CDP (constant data protection) component for (more or less) real-time updating of data between replicator and replicant. What do you mean by "more or less?" Are you just saying that it's asynchronous? I think all the CDP solutions are. Or are you saying something else?
Re: SQL command to query Sessions with MediaWait or Idle
Try select * from sessions and see if that gives you what you need Steven Harris Tivoli Storage Manager SME Backup & Recovery Team Storage Services Group Cumberland Forest Phone: IBM Internal :70-75130 External:02 9407 5130 Mobile: 0422 932 065
SQL command to query Sessions with MediaWait or Idle
Hello all I am trying to figure out an effective way to get alerted if a backup job is idle or not proceeding due to a MediaWait state. I want it to have the smarts to maybe only alert me if it finds the same successive node has been in the same MediaWait state for a predetermined period (eg an hour) - given that I am aware at different times an occasional 'mediawait' warning is just part of normal function What is the best way of doing this? I am thinking either running a SQL query of some sort to do this, then fire an email or netsend to someone - OR use SNMP.. Would welcome any suggestions or hints? http://www.santos.com/library/logo.gif";> Santos Ltd A.B.N. 80 007 550 923 Disclaimer: The information contained in this email is intended only for the use of the person(s) to whom it is addressed and may be confidential or contain privileged information. If you are not the intended recipient you are hereby notified that any perusal, use, distribution, copying or disclosure is strictly prohibited. If you have received this email in error please immediately advise us by return email and delete the email without making a copy. Please consider the environment before printing this email
Re: Centera or better yet NAS restore help
If you use a windows base client and sign in to the TSM server using a privilege account. You will see in the GUI for restore the expansion tab for nodes. You will see the NAS nodes and then the windows nodes. -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Ochs, Duane Sent: Thursday, December 04, 2008 9:05 AM To: ADSM-L@VM.MARIST.EDU Subject: Centera or better yet NAS restore help Good day all, The on going saga of Centera backups and now restore attempts using TSM. I have performed a number of backups of our Centera. 1 full and three Differentials using the following command. BACKUP NODE test_cbrm c:\centera mode=differential toc=yes w=y I am unable to see any of the backups from the client's TSM client. Can anyone point me in the right direction ? Here is a copy of the opt file: NASNODENAME test_cbrm PASSWORDACCESS GENERATE TCPSERVERADDRESS local_tsm1 COMPRESSION YES COMPRESSALWAYS NO MEMORYEFFICIENTBACKUP YES LARGECOMMBUFFERS YES TAPEPROMPT NO TCPBUFFSIZE 64 TCPNODELAY YES TCPWINDOWSIZE 512 TXNBYTELIMIT 2097152 schedlogretention 7 d errorlogretention 7 d NASNode is define as: tsm: QTWATSM1>q node test* type=nas f=d Node Name: TEST_CBRM Platform: Windows NT Client OS Level: 5 (EMC) Client Version: Policy Domain Name: CBRM_DOMAIN Last Access Date/Time: 12/04/08 11:42:42 Days Since Last Access: <1 Password Set Date/Time: 11/05/08 12:20:19 Days Since Password Set: 29 Invalid Sign-on Count: 0 Locked?: No Contact: Compression: Archive Delete Allowed?: Yes Backup Delete Allowed?: No Registration Date/Time: 11/05/08 12:20:19 Registering Administrator: ADMIN Last Communication Method Used: NDMP Bytes Received Last Session: Bytes Sent Last Session: Duration of Last Session: Pct. Idle Wait Last Session: Pct. Comm. Wait Last Session: Pct. Media Wait Last Session: Optionset: URL: Node Type: NAS Password Expiration Period: Keep Mount Point?: No Maximum Mount Points Allowed: 1 Auto Filespace Rename : No Validate Protocol: No TCP/IP Name: TEST TCP/IP Address: XX.XX.XX.XX Globally Unique ID: 1b.7d.b2.e1.c2.14.11.dd.8f.e4.00.19.b9.cf.3c.88 Transaction Group Max: 0 Data Write Path: ANY Data Read Path: ANY Session Initiation: ClientOrServer High-level Address: Low-level Address: Collocation Group Name: Proxynode Target: Proxynode Agent: Node Groups: Email Address: created a host and admin and granted auth to the system for access to the nasnode. tsm: QTWATSM1>q node test f=d Node Name: test Platform: WinNT Client OS Level: 5.02 Client Version: Version 5, Release 5, Level 1.1 Policy Domain Name: STANDARD Last Access Date/Time: 12/04/08 11:46:16 Days Since Last Access: <1 Password Set Date/Time: 12/04/08 10:04:46 Days Since Password Set: <1 Invalid Sign-on Count: 0 Locked?: No Contact: Compression: Client Archive Delete Allowed?: Yes Backup Delete Allowed?: No Registration Date/Time: 12/04/08 10:04:46 Registering Administrator: ADMIN Last Communication Method Used: Bytes Received Last Session: 0 Bytes Sent Last Session: 0 Duration of Last Session: 0.00 Pct. Idle Wait Last Session: 0.00 Pct. Comm. Wait Last Session: 0.00 Pct. Media Wait Last Session: 0.00 Optionset: URL: Node Type: Client Password Expiration Period: Keep Mount Point?: No Maximum Mount Points Allowed: 1 Auto Filespace Rename : No Validate Protocol: No TCP/IP Name: TEST TCP/IP Address: xx.xx.xx.xx Globally Unique ID: 1b.7d.b2.e1.c2.14.11.dd.8f.e4.00.19.b9.cf.3c.88 Transaction Group Max: 0 Data Write Path: ANY Data Read Path: ANY Session Initiation: ClientOrServer High-level Address: Low-level Address: Collocation Group Name: Proxynode Target: Proxynode Agent: Node Groups: Email Address: Admin defined as: tsm: QTWATSM1>q admin TEST f=d Administrator Name: TEST Last Access Date/Time: 12/04/08 10:45:05 Days Since Last Access: <1 Password Set Date/Time: 12/04/08 10:04:46
Re: Database size, Split to multiple instances or wait for version 6.1
Interesting.. we have a database that's about the same size, but it takes us 2 hours and 40 minutes to back it up to LTO3. We also have 15K rpm 36GB drives, in two mirrored RAID5,7 sets (TSM mirroring). SAN is 2Gb FC. Server is P5 570. Server is not entire idle, but mostly so. Our database is ancient, dating back to ADSM 1.2 days and has never been re-organized. How old is your database? I'm wondering if a re-org would improve things that much. ..Paul At 12:05 PM 12/4/2008, Conradt, Jeremy wrote: Its actually not 350 GB. The actual used size is: Available Assigned Maximum MaximumPage Total Used Pct Max. Space Capacity Extension ReductionSizeUsable Pages Util Pct (MB) (MB) (MB) (MB) (bytes) Pages Util - - - --- - - - - 350,000 340,00010,00057,580 4,096 87,040,00 72,203,13 83.0 83.1 0 6 The DB resides on 7 - 15K fiber channel drives in a Raid5 configuration with 2 GB/s Fiber connection. Also the Log resides on a separate lun on a separate controller. Also during this time basically nothing else is happening on the system. The tape drive is LTO3. If I backup the DB while multiple migration or reclamation processes are running then the DB backup is significantly slowed down. I have also attached the output of the last DBBackup for your reference and for the doubters. I actually estimated the time and I was a little high on it. I can't give you the output from an expire because my log files have already been replaced but here is the last run's time output. C:\Program Files\Tivoli\tsm\baclient>time /t 12:16 PM C:\Program Files\Tivoli\tsm\baclient>dsmadmc -id=scriptrun -password=** expire inventory wait=yes 1>c:\scripts\logs\07-expire.txt C:\Program Files\Tivoli\tsm\baclient>time /t 01:12 PM Jeremy -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Bos, Karel Sent: Thursday, December 04, 2008 10:45 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Database size, Split to multiple instances or wait for version 6.1 Ok, 350GB tsm db backing up in 1 hour? How did you get it that fast? Regards, Karel -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Conradt, Jeremy Sent: donderdag 4 december 2008 17:19 To: ADSM-L@VM.MARIST.EDU Subject: Re: Database size, Split to multiple instances or wait for version 6.1 Expiration takes about 1 hour. DB Backup takes about 1 hour 15 minutes. Thanks, Jeremy -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Wanda Prather Sent: Wednesday, December 03, 2008 7:01 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Database size, Split to multiple instances or wait for version 6.1 How long does it take you now to do Expiration and DB backup? On Wed, Dec 3, 2008 at 4:24 PM, Conradt, Jeremy < [EMAIL PROTECTED]> wrote: > I have a TSM server currently running version 5.3.5 on Windows 2003 > that we plan to upgrade soon. > The problem I have is our database has grown to 350 GB. > The question I have is will version 6.1 of TSM be better capable of > maintaining a database this size and much larger or should I break it > apart? > I would rather keep everything together so we can make better use of > de-duplication that may be coming out with version 6. > Thanks, > Jeremy > > > -- Paul ZarnowskiPh: 607-255-4757 Manager, Storage Services Fx: 607-255-8521 719 Rhodes Hall, Ithaca, NY 14853-3801Em: [EMAIL PROTECTED]
Re: Where is the missing 38GB?
On Dec 4, 2008, at 23:41 , Roger Deschner wrote: . The missing 38GB is just simply gone. Wave it goodbye. Disks are cheap - find something more expensive to worry about. ok, I'll have to disagree here. an empty db (and this one is) should not have 100% fragmentation. And like my test server, with only 2*18GB internally, I'd hate to loose 38 ;-) You will get it back, though, if you ever refill this database with data. But wait, you say, won't the new data be fragmented too? Sure, just like it would be if you started fresh with an empty database and let it run a year or so. in normal operations, agreed, unless you agree that 100% fragmentation should at least clean up pretty nicely with an unload/load. Our 377gb database is from 1999 and has never been audited fully or reloaded, and is running smoothly on v5.5.1 now. We have done some large DELETE FILESPACE operations as we move some nodes to a second server, and some space has disappeared just like you report, but I'm not really worried about it. It will get reused by natural growth. Now, you should be worried. 377 GB is huge :) I agree, in a production db of that size, about 10-20% external fragmentation (free block amongst the used ones) is nothing to worry about, neither is 50% or more internal fragmentation (half used blocks). Zoltan's db is something completely different and a good example of a db that does apply for an unload/load cycle. OTOH, judging by the amount of data left in your database, an unload/load cycle should be cheap and fast, so why not? At least try it as a test, reloading to a test server, and let us know what happened. We're all waiting anxiously to hear - because we on this list can argue about TSM database fragmentation forever, as you have just seen. A third idea was suggested already - DELETE DBVOL. I've watched this remarkable command work, and it's like reclamation, except on the database. It's going to run for a very long time, and it's goal is not defragmentation so it won't do very well at that, but it will accomplish a basic reclamation operation on this database. The nice thing about DELETE DBVOL is that it can run with the system up and running. The not-so-nice thing about it is that it's unmirrored. You've got to delete all the mirror copies before DELETE DBVOL can work its real magic, and while it does you're very badly exposed to a single-disk failure, especially because it's slow. Therefore, before using DELETE DBVOL for this kind of thing, I always move that database extent to something that does hardware mirroring such as a commonplace hardware RAID box, or SSA RAID, etc. delete dbvol only solves external fragmentation, non-empty block will be moved as they are. In Zoltan's case, these make up about 100% of his database. I happen to like thinking and discussing about intresting TSM oddities, I even do it when I'm not at work. Zoltan, did you ever do the unload/load? Roger Deschner University of Illinois at Chicago [EMAIL PROTECTED] "Whether you think you can or can not, you are right." On Tue, 2 Dec 2008, Remco Post wrote: I'd say, from what I read in the thread, that an unload/load at this point will remove a lot of fragmentation, even though the estimate says nill. The other option is to run an export server, reformat everything, and then import server. You'll probably want to save your devconf.txt so you can easily recreate the stgpools, devclasses and server2server comms you might have. On Dec 2, 2008, at 18:20 , Zoltan Forray/AC/VCU wrote: I have a test TSM server (5.5.1) which is producing some strange DB statistics. ** *** ---> Q DB F=D ** Available Space (MB): 56,336 Assigned Capacity (MB): 53,264 Maximum Extension (MB): 3,072 Maximum Reduction (MB): 14,360 Page Size (bytes): 4,096 Total Usable Pages: 13,635,584 Used Pages: 15,676 Pct Util: 0.1 Max. Pct Util: 0.1 Physical Volumes: 6 Buffer Pool Pages: 131,072 Total Buffer Requests: 249 Cache Hit Pct.: 100.00 Cache Wait Pct.: 0.00 Backup in Progress?: No Type of Backup In Progress: Incrementals Since Last Full: 4 Changed Since Last Backup (MB): 211.15 Percentage Changed: 344.82 Last Complete Backup Date/Time: 08/20/2008 09:49:38 Estimate of Recoverable Space (MB): Last Estimate of Recoverable Space (MB): With an assigned capacity of 52GB yet only 0.1% utilized (52MB?), it says I can only reduce the DB by 13GB So, where is the remaining 38GB of DB usage ? There are 5-Disk STG volumes (empty/0% utilized), 2-Nodes with NO filespaces, defined
Re: Where is the missing 38GB?
. The missing 38GB is just simply gone. Wave it goodbye. Disks are cheap - find something more expensive to worry about. You will get it back, though, if you ever refill this database with data. But wait, you say, won't the new data be fragmented too? Sure, just like it would be if you started fresh with an empty database and let it run a year or so. Our 377gb database is from 1999 and has never been audited fully or reloaded, and is running smoothly on v5.5.1 now. We have done some large DELETE FILESPACE operations as we move some nodes to a second server, and some space has disappeared just like you report, but I'm not really worried about it. It will get reused by natural growth. OTOH, judging by the amount of data left in your database, an unload/load cycle should be cheap and fast, so why not? At least try it as a test, reloading to a test server, and let us know what happened. We're all waiting anxiously to hear - because we on this list can argue about TSM database fragmentation forever, as you have just seen. A third idea was suggested already - DELETE DBVOL. I've watched this remarkable command work, and it's like reclamation, except on the database. It's going to run for a very long time, and it's goal is not defragmentation so it won't do very well at that, but it will accomplish a basic reclamation operation on this database. The nice thing about DELETE DBVOL is that it can run with the system up and running. The not-so-nice thing about it is that it's unmirrored. You've got to delete all the mirror copies before DELETE DBVOL can work its real magic, and while it does you're very badly exposed to a single-disk failure, especially because it's slow. Therefore, before using DELETE DBVOL for this kind of thing, I always move that database extent to something that does hardware mirroring such as a commonplace hardware RAID box, or SSA RAID, etc. Roger Deschner University of Illinois at Chicago [EMAIL PROTECTED] "Whether you think you can or can not, you are right." On Tue, 2 Dec 2008, Remco Post wrote: > >I'd say, from what I read in the thread, that an unload/load at this >point will remove a lot of fragmentation, even though the estimate >says nill. > >The other option is to run an export server, reformat everything, and >then import server. You'll probably want to save your devconf.txt so >you can easily recreate the stgpools, devclasses and server2server >comms you might have. > >On Dec 2, 2008, at 18:20 , Zoltan Forray/AC/VCU wrote: > >> I have a test TSM server (5.5.1) which is producing some strange DB >> statistics. >> >> ** >> *** ---> Q DB F=D >> ** >> >> >> Available Space (MB): 56,336 >> Assigned Capacity (MB): 53,264 >> Maximum Extension (MB): 3,072 >> Maximum Reduction (MB): 14,360 >> Page Size (bytes): 4,096 >> Total Usable Pages: 13,635,584 >> Used Pages: 15,676 >> Pct Util: 0.1 >> Max. Pct Util: 0.1 >> Physical Volumes: 6 >> Buffer Pool Pages: 131,072 >> Total Buffer Requests: 249 >> Cache Hit Pct.: 100.00 >>Cache Wait Pct.: 0.00 >>Backup in Progress?: No >> Type of Backup In Progress: >> Incrementals Since Last Full: 4 >> Changed Since Last Backup (MB): 211.15 >> Percentage Changed: 344.82 >> Last Complete Backup Date/Time: 08/20/2008 09:49:38 >> Estimate of Recoverable Space (MB): >> Last Estimate of Recoverable Space (MB): >> >> >> With an assigned capacity of 52GB yet only 0.1% utilized (52MB?), it >> says >> I can only reduce the DB by 13GB >> >> So, where is the remaining 38GB of DB usage ? >> >> There are 5-Disk STG volumes (empty/0% utilized), 2-Nodes with NO >> filespaces, defined. "Q STG" shows: >> >> 12:15:11 PM TSMTEST : q stg >> >> Storage Device EstimatedPctPct High Low Next >> Stora- >> Pool NameClass NameCapacity Util Migr Mig Mig ge Pool >>Pct Pct >> --- -- -- - - --- >> --- >> ARCHIVEPOOL DISK 0.0 M0.00.090 30 >> BACKUPPOOL DISK 123 G0.00.090 30 >> COPYPOOL-I- IBM3583-10.0 M0.0 >> BM3583-1 >> COPYPOOL-I- IBM3583-20.0 M0.0 >> BM3583-2 >> IBM3494-35- 3592E05 0.0 M0.00.090 70 >> 92 >> >> I did a "DSMSERV AUDITDB FIX=YES" and the only thing it complained >> (and >> fixed) about was old schedules for non-existing nodes. Also did an >> "EXPIRE INVENTORY". > >-- >Met vriendelijke groeten, > >Remco Post >[EMAIL PROTE
Re: Server Platform Upgrade
Go the P550 route. I've seen P-series boxes handle 3 to 5 times the amount of workload an Intel box can handle, and I'm a big fan of Linux. I know more about Linux than I do AIX. However, you need the right tool for the job, and the P-series box will do the job, and do it longer. On heavy I/O boxes I'm convinced that P-series is the way to go. Especially if you can get the AIX box for the same price as the x86 box. However, if not you'll need more than one x86 box to handle the load. See Ya' Howard > -Original Message- > From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf > Of Sam Sheppard > Sent: Thursday, December 04, 2008 12:51 PM > To: ADSM-L@VM.MARIST.EDU > Subject: [ADSM-L] Server Platform Upgrade > > We are currently running 3 TSM servers at Version 5.5, two on z/OS and > the third on a Solaris 10 box. We have been tasked to combine these > into one. > > The current Solaris system is on a Sun V240 w/8GB memory: > >Around 400 clients (combined) including a 3TB Exchange system, and a > fairly large SAP implemtation in development on MS SQL Server, > several Oracle boxes, and a large number of Windows servers. > >Total database size (Solaris) is around 80GB, expiration runs about > two hours. z/OS databases total 50GB. > >8 TS1120 tape drives in a 3494 ATL. > >1.2TB array for storage pools and database on the Solaris server > which we are currently trying to separate. > >Total daily backup volume is around 1TB with additional weekly > backups of 9TB. > > I am the TSM guy and the z/OS systems programmer and as such don't > really have a feel for hardware sizing or configuration on the Unix > side > of things and so have to rely on our Unix guys. I suggested that AIX > would be the preferred platform for this implementation with another > Solaris box having the advantage of not requiring converting the exist- > ing one. They came up with the following options with their favorite > being the x86(HP) with Linux because it is much cheaper and they claim > would be more powerful. The AIX and Sun configurations are similar in > price at around 5 times the x86. > > Thought, comments, considerations? What are people using for disk > storage pools and would the internal drives on these boxes be adequate? > I'm also in the process of freeing one array on our ESS800 (Shark) for > fiber connection to this configuration. > > Here are the proposed options: > > IBM Power 550 ExpressHP DL380 G5 > Up to 8 cores and 256GB RAM Up to 8 cores and 64GB RAM > Six 300GB internal SAS 15k drivesEight 146GB internal SAS 15k > drives > Three PCIe and two PCI-X slots Four PCIe slots > Dual port 10 GB Ethernet card > 4 GB fiber channel cards - x2 > > Thanks > Sam Sheppard > San Diego Data Processing Corp. > (858)-581-9668
Re: Server Platform Upgrade
If I were going to be in the x86 family, I would move into the larger platforms with more processors and more PCI-E slots. So the HP DL580 I think would be your best bet. That will reduce the 5x cost benefit somewhat but provide you with more flexibility. Consider the IBM x3850 M2 server. These are great boxes and IBM will continue to love and support you. And perhaps a bit cheaper than HP. Similar to my comment about Windows vs. Unix below, if you have a ton of HP stuff in your site now, go with HP. Linux or Windows then. Hmmm. I'm not a Linux guy so I would choose windows. If most of your clients are windows and most of your internal IT knowledge is Windows, stay Windows. If you have the Linux expertise, then use that. Won't make much difference to TSM (I know, I know, Windows for I/O sucks and all that, which BTW is contrary to what I know and believe...). You can probably buy two x86 and split the load and still save money over the mongo AIX box. I'd rather do that. Kelly Lipp CTO STORServer, Inc. 485-B Elkton Drive Colorado Springs, CO 80907 719-266-8777 x7105 www.storserver.com -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Sam Sheppard Sent: Thursday, December 04, 2008 11:51 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Server Platform Upgrade We are currently running 3 TSM servers at Version 5.5, two on z/OS and the third on a Solaris 10 box. We have been tasked to combine these into one. The current Solaris system is on a Sun V240 w/8GB memory: Around 400 clients (combined) including a 3TB Exchange system, and a fairly large SAP implemtation in development on MS SQL Server, several Oracle boxes, and a large number of Windows servers. Total database size (Solaris) is around 80GB, expiration runs about two hours. z/OS databases total 50GB. 8 TS1120 tape drives in a 3494 ATL. 1.2TB array for storage pools and database on the Solaris server which we are currently trying to separate. Total daily backup volume is around 1TB with additional weekly backups of 9TB. I am the TSM guy and the z/OS systems programmer and as such don't really have a feel for hardware sizing or configuration on the Unix side of things and so have to rely on our Unix guys. I suggested that AIX would be the preferred platform for this implementation with another Solaris box having the advantage of not requiring converting the exist- ing one. They came up with the following options with their favorite being the x86(HP) with Linux because it is much cheaper and they claim would be more powerful. The AIX and Sun configurations are similar in price at around 5 times the x86. Thought, comments, considerations? What are people using for disk storage pools and would the internal drives on these boxes be adequate? I'm also in the process of freeing one array on our ESS800 (Shark) for fiber connection to this configuration. Here are the proposed options: IBM Power 550 ExpressHP DL380 G5 Up to 8 cores and 256GB RAM Up to 8 cores and 64GB RAM Six 300GB internal SAS 15k drivesEight 146GB internal SAS 15k drives Three PCIe and two PCI-X slots Four PCIe slots Dual port 10 GB Ethernet card 4 GB fiber channel cards - x2 Thanks Sam Sheppard San Diego Data Processing Corp. (858)-581-9668
Server Platform Upgrade
We are currently running 3 TSM servers at Version 5.5, two on z/OS and the third on a Solaris 10 box. We have been tasked to combine these into one. The current Solaris system is on a Sun V240 w/8GB memory: Around 400 clients (combined) including a 3TB Exchange system, and a fairly large SAP implemtation in development on MS SQL Server, several Oracle boxes, and a large number of Windows servers. Total database size (Solaris) is around 80GB, expiration runs about two hours. z/OS databases total 50GB. 8 TS1120 tape drives in a 3494 ATL. 1.2TB array for storage pools and database on the Solaris server which we are currently trying to separate. Total daily backup volume is around 1TB with additional weekly backups of 9TB. I am the TSM guy and the z/OS systems programmer and as such don't really have a feel for hardware sizing or configuration on the Unix side of things and so have to rely on our Unix guys. I suggested that AIX would be the preferred platform for this implementation with another Solaris box having the advantage of not requiring converting the exist- ing one. They came up with the following options with their favorite being the x86(HP) with Linux because it is much cheaper and they claim would be more powerful. The AIX and Sun configurations are similar in price at around 5 times the x86. Thought, comments, considerations? What are people using for disk storage pools and would the internal drives on these boxes be adequate? I'm also in the process of freeing one array on our ESS800 (Shark) for fiber connection to this configuration. Here are the proposed options: IBM Power 550 ExpressHP DL380 G5 Up to 8 cores and 256GB RAM Up to 8 cores and 64GB RAM Six 300GB internal SAS 15k drivesEight 146GB internal SAS 15k drives Three PCIe and two PCI-X slots Four PCIe slots Dual port 10 GB Ethernet card 4 GB fiber channel cards - x2 Thanks Sam Sheppard San Diego Data Processing Corp. (858)-581-9668
Re: NAS NDMP backups using a copy pool
My NAS backup scripts looks like serial backup node NAS /fs1 mode=full wait=yes . backup node NAS /fsx mode=full wait=yes backup stgpool nasprimary nascopy The NAS unit backups over the SAN and creates the copies over the SAN. The NAS unit creates the copy and not TSM -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Joni Moyer Sent: Thursday, December 04, 2008 8:51 AM To: ADSM-L@VM.MARIST.EDU Subject: NAS NDMP backups using a copy pool Hello everyone, I recently upgraded a TSM AIX 5.3 server to 5.5.1.1 and would like to begin utilizing the copy pools for our offsite backups. I've been searching in the 5.5 manuals for good documentation on how to set this up and then fold it into our DRM plan, but I'm not finding much. Does anyone know how to do this? Thanks in advance! Joni Moyer Highmark Storage Systems, Storage Mngt Analyst III Phone Number: (717)302-9966 Fax: (717) 302-9826 [EMAIL PROTECTED]
Re: Maintenance Processes - Scheduling optimization
If it helps this is our sequence. 4am start backup storage pool Run DB backup Eject tapes and do DRM stuff Start expiration and run single thread migration After expiration completes increase migration threads Run reclaim 9pm terminate reclaims 9pm run a "spare" DB backup. We move about 3TB per day of new stuff with a DB of about 120GB and about 95TB of stored data. Reclamation does not always complete, so we have between 0 and 50 reclaimable tapes from the previous day. To help we will run timed reclaims in the morning for storage pools that have completed the backup process. We are careful to not run competing process, such as reclaiming and backing up the same storage pool. And we avoid running anything during the DB backup. To decrease the run times we have 20 storage pools so we can have many parallel processes running. In general we spin tape about 20 hours per day (old tape drives). And it is rare for a TSM server to have nothing to do. Andy Huebner -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Conradt, Jeremy Sent: Wednesday, December 03, 2008 3:25 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Maintenance Processes - Scheduling optimization I have recently forced myself to admit we have a major flaw in our backup system. What was happening and may be happening to many other people is we had maintenance processes, reclaims, migrations and so on happening on fileclass volumes after or even during the database backup. The problem with this is if the database were to crash or corrupt after its backup any maintenance work that happened after the beginning of the backup will cause issues with the recovery. For example X file exists on Filevolume1 at the beginning of the database backup but after the backup migration or reclamation moves it to Filevolume2. The database corrupts we restore the database which doesn't know anything about Filevolume2 and now it can't find Filevolume1 which forces us to restore Filevolume1 from offsite. Basically just a lot of work to get everything back in sync. I have been working on trying to get all of our backup stg, migrate stg and reclaim stg to run in a single script sequentially but there is insufficient time in the day to complete successfully. We end up overlapping into the next backup window which just slows everything down. The Copy pool "Offsite" tapes are fine because I have the stg set with a delay period of 1 day but I don't want to tie up file volume space for a day if I don't have to. I am wondering if anyone has worked their way through this issue and developed a good set of scripts to get everything running cleanly and in proper order. System Stats TSM Server version 5.3.5 Windows 2003 SP2 1.1 TB Disk pool 15K Fiber channel san disk with DISK class volumes Files smaller than 3GB are backed up to this location. This pool is migrated to 0% every day. 3 TB file class volumes on 10K Fiber Channel san disk Files larger than 3GB are backed up to this location. This pool is migrated to 50% every day. 43 TB file class volumes on multiple disk drives primarily SATA. Long term storage or data. In general we have about 32 TB of regular backup data and about 60 TB of Archive data on tape. We back up approximately 2 TB of data daily. At this time all of our backup data remains on disk. If anyone has any questions about how we have anything setup and working please let me know. If anyone has any suggestions on how to resolve any problems they see in our system please let me know. Thanks, Jeremy This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.
Re: RMAN - Oracle Deletes
This is the script I use: ASSUMPTIONS: RMAN is backing-up using the node name ORACLE-NODE-BU select NODE_NAME,cast(BACKUP_DATE as date) as "BACKUP_DATE",STATE,cast(DEACTIVATE_DATE as date) as "DEACTIVATE_DATE", HL_NAME,LL_NAME from BACKUPS where NODE_NAME='ORACLE-NODE-BU' order by BACKUP_DATE > /tmp/ORACLE-NODE-BU.bulist.txt Thanks, H. Milton Johnson -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Hart, Charles A Sent: Friday, November 21, 2008 9:59 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] RMAN - Oracle Deletes Hope everyone is well in these trying times. Does anyone know if there's a way other than tracking occupancy to see if RMAN is passing deletes to TSM for Oracle TDP clients? We've had many challenges with our Oracle group and their delete backup script not working. Thank you Have a great day! Charles This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately.
Re: Database size, Split to multiple instances or wait for version 6.1
On Dec 4, 2008, at 17:45 , Bos, Karel wrote: Ok, 350GB tsm db backing up in 1 hour? How did you get it that fast? lots of very fast disk, very wide striping? And I guess using stk t10kb drives of disk to store the backups, since those are the only two I know that can go this fast Regards, Karel -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Conradt, Jeremy Sent: donderdag 4 december 2008 17:19 To: ADSM-L@VM.MARIST.EDU Subject: Re: Database size, Split to multiple instances or wait for version 6.1 Expiration takes about 1 hour. DB Backup takes about 1 hour 15 minutes. Thanks, Jeremy -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Wanda Prather Sent: Wednesday, December 03, 2008 7:01 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Database size, Split to multiple instances or wait for version 6.1 How long does it take you now to do Expiration and DB backup? On Wed, Dec 3, 2008 at 4:24 PM, Conradt, Jeremy < [EMAIL PROTECTED]> wrote: I have a TSM server currently running version 5.3.5 on Windows 2003 that we plan to upgrade soon. The problem I have is our database has grown to 350 GB. The question I have is will version 6.1 of TSM be better capable of maintaining a database this size and much larger or should I break it apart? I would rather keep everything together so we can make better use of de-duplication that may be coming out with version 6. Thanks, Jeremy -- Met vriendelijke groeten, Remco Post [EMAIL PROTECTED] +31 6 248 21 622
Re: Database size, Split to multiple instances or wait for version 6.1
Its actually not 350 GB. The actual used size is: Available Assigned Maximum MaximumPage Total Used Pct Max. Space Capacity Extension ReductionSizeUsable Pages Util Pct (MB) (MB) (MB) (MB) (bytes) Pages Util - - - --- - - - - 350,000 340,00010,00057,580 4,096 87,040,00 72,203,13 83.0 83.1 0 6 The DB resides on 7 - 15K fiber channel drives in a Raid5 configuration with 2 GB/s Fiber connection. Also the Log resides on a separate lun on a separate controller. Also during this time basically nothing else is happening on the system. The tape drive is LTO3. If I backup the DB while multiple migration or reclamation processes are running then the DB backup is significantly slowed down. I have also attached the output of the last DBBackup for your reference and for the doubters. I actually estimated the time and I was a little high on it. I can't give you the output from an expire because my log files have already been replaced but here is the last run's time output. C:\Program Files\Tivoli\tsm\baclient>time /t 12:16 PM C:\Program Files\Tivoli\tsm\baclient>dsmadmc -id=scriptrun -password=** expire inventory wait=yes 1>c:\scripts\logs\07-expire.txt C:\Program Files\Tivoli\tsm\baclient>time /t 01:12 PM Jeremy -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Bos, Karel Sent: Thursday, December 04, 2008 10:45 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Database size, Split to multiple instances or wait for version 6.1 Ok, 350GB tsm db backing up in 1 hour? How did you get it that fast? Regards, Karel -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Conradt, Jeremy Sent: donderdag 4 december 2008 17:19 To: ADSM-L@VM.MARIST.EDU Subject: Re: Database size, Split to multiple instances or wait for version 6.1 Expiration takes about 1 hour. DB Backup takes about 1 hour 15 minutes. Thanks, Jeremy -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Wanda Prather Sent: Wednesday, December 03, 2008 7:01 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Database size, Split to multiple instances or wait for version 6.1 How long does it take you now to do Expiration and DB backup? On Wed, Dec 3, 2008 at 4:24 PM, Conradt, Jeremy < [EMAIL PROTECTED]> wrote: > I have a TSM server currently running version 5.3.5 on Windows 2003 > that we plan to upgrade soon. > The problem I have is our database has grown to 350 GB. > The question I have is will version 6.1 of TSM be better capable of > maintaining a database this size and much larger or should I break it > apart? > I would rather keep everything together so we can make better use of > de-duplication that may be coming out with version 6. > Thanks, > Jeremy > > > IBM Tivoli Storage Manager Command Line Administrative Interface - Version 5, Release 3, Level 0.8 (c) Copyright by IBM Corporation and other(s) 1990, 2005. All Rights Reserved. Session established with server TSM_SERVER1: Windows Server Version 5, Release 3, Level 5.0 Server date/time: 12/04/2008 08:59:39 Last access: 12/04/2008 08:59:32 ANS8000I Server command: 'backup db t=f devclass=lto3class scratch=yes wait=yes' ANR0984I Process 937 for DATABASE BACKUP started in the FOREGROUND at 09:03:51. ANR2280I Full database backup started as process 937. ANR4554I Backed up 192064 of 72239574 database pages. ANR4554I Backed up 811072 of 72239574 database pages. ANR4554I Backed up 1594688 of 72239574 database pages. ANR4554I Backed up 2416896 of 72239574 database pages. ANR4554I Backed up 3216704 of 72239574 database pages. ANR4554I Backed up 3953536 of 72239574 database pages. ANR4554I Backed up 4704704 of 72239574 database pages. ANR4554I Backed up 5465600 of 72239574 database pages. ANR4554I Backed up 6233856 of 72239574 database pages. ANR4554I Backed up 7000320 of 72239574 database pages. ANR4554I Backed up 7805120 of 72239574 database pages. ANR4554I Backed up 8595840 of 72239574 database pages. ANR4554I Backed up 9408256 of 72239574 database pages. ANR4554I Backed up 10197248 of 72239574 database pages. ANR4554I Backed up 10996544 of 72239574 database pages. ANR4554I Backed up 11785984 of 72239574 database pages. ANR4554I Backed up 12532992 of 72239574 database pages. ANR4554I Backed up 13279552 of 72239574 database pages. ANR4554I Backed up 14032320 of 72239574 database pages. ANR4554I Backed up 14795264 of 72239574 database pages. ANR4554I Backed up 15526848 of 72239574 database pages. ANR4554I Backed up 16275328 of 72239574 database pages. ANR4554I Backed up 17042432 of 72239574 database pages. ANR4554I Backed up 17814784 of 72239574 database pages. ANR4554I Backed up 18584064 of 72239574 database pages. ANR4554I Backed up 19348928 of 7223957
Centera or better yet NAS restore help
Good day all, The on going saga of Centera backups and now restore attempts using TSM. I have performed a number of backups of our Centera. 1 full and three Differentials using the following command. BACKUP NODE test_cbrm c:\centera mode=differential toc=yes w=y I am unable to see any of the backups from the client's TSM client. Can anyone point me in the right direction ? Here is a copy of the opt file: NASNODENAME test_cbrm PASSWORDACCESS GENERATE TCPSERVERADDRESS local_tsm1 COMPRESSION YES COMPRESSALWAYS NO MEMORYEFFICIENTBACKUP YES LARGECOMMBUFFERS YES TAPEPROMPT NO TCPBUFFSIZE 64 TCPNODELAY YES TCPWINDOWSIZE 512 TXNBYTELIMIT 2097152 schedlogretention 7 d errorlogretention 7 d NASNode is define as: tsm: QTWATSM1>q node test* type=nas f=d Node Name: TEST_CBRM Platform: Windows NT Client OS Level: 5 (EMC) Client Version: Policy Domain Name: CBRM_DOMAIN Last Access Date/Time: 12/04/08 11:42:42 Days Since Last Access: <1 Password Set Date/Time: 11/05/08 12:20:19 Days Since Password Set: 29 Invalid Sign-on Count: 0 Locked?: No Contact: Compression: Archive Delete Allowed?: Yes Backup Delete Allowed?: No Registration Date/Time: 11/05/08 12:20:19 Registering Administrator: ADMIN Last Communication Method Used: NDMP Bytes Received Last Session: Bytes Sent Last Session: Duration of Last Session: Pct. Idle Wait Last Session: Pct. Comm. Wait Last Session: Pct. Media Wait Last Session: Optionset: URL: Node Type: NAS Password Expiration Period: Keep Mount Point?: No Maximum Mount Points Allowed: 1 Auto Filespace Rename : No Validate Protocol: No TCP/IP Name: TEST TCP/IP Address: XX.XX.XX.XX Globally Unique ID: 1b.7d.b2.e1.c2.14.11.dd.8f.e4.00.19.b9.cf.3c.88 Transaction Group Max: 0 Data Write Path: ANY Data Read Path: ANY Session Initiation: ClientOrServer High-level Address: Low-level Address: Collocation Group Name: Proxynode Target: Proxynode Agent: Node Groups: Email Address: created a host and admin and granted auth to the system for access to the nasnode. tsm: QTWATSM1>q node test f=d Node Name: test Platform: WinNT Client OS Level: 5.02 Client Version: Version 5, Release 5, Level 1.1 Policy Domain Name: STANDARD Last Access Date/Time: 12/04/08 11:46:16 Days Since Last Access: <1 Password Set Date/Time: 12/04/08 10:04:46 Days Since Password Set: <1 Invalid Sign-on Count: 0 Locked?: No Contact: Compression: Client Archive Delete Allowed?: Yes Backup Delete Allowed?: No Registration Date/Time: 12/04/08 10:04:46 Registering Administrator: ADMIN Last Communication Method Used: Bytes Received Last Session: 0 Bytes Sent Last Session: 0 Duration of Last Session: 0.00 Pct. Idle Wait Last Session: 0.00 Pct. Comm. Wait Last Session: 0.00 Pct. Media Wait Last Session: 0.00 Optionset: URL: Node Type: Client Password Expiration Period: Keep Mount Point?: No Maximum Mount Points Allowed: 1 Auto Filespace Rename : No Validate Protocol: No TCP/IP Name: TEST TCP/IP Address: xx.xx.xx.xx Globally Unique ID: 1b.7d.b2.e1.c2.14.11.dd.8f.e4.00.19.b9.cf.3c.88 Transaction Group Max: 0 Data Write Path: ANY Data Read Path: ANY Session Initiation: ClientOrServer High-level Address: Low-level Address: Collocation Group Name: Proxynode Target: Proxynode Agent: Node Groups: Email Address: Admin defined as: tsm: QTWATSM1>q admin TEST f=d Administrator Name: TEST Last Access Date/Time: 12/04/08 10:45:05 Days Since Last Access: <1 Password Set Date/Time: 12/04/08 10:04:46 Days Since Password Set: <1 Invalid Sign-on Count: 0 Locked?: No Contact: System Privilege: Yes Policy Privilege: ** Included with system privilege ** Storage Privilege: ** Included with system privilege ** Analyst Privilege: ** Included with system privilege ** Operator Privilege: ** Included with system privilege ** Client Access Privilege:
Re: NAS NDMP backups using a copy pool
On Dec 4, 2008, at 17:51 , Joni Moyer wrote: Hello everyone, I recently upgraded a TSM AIX 5.3 server to 5.5.1.1 and would like to begin utilizing the copy pools for our offsite backups. I've been searching in the 5.5 manuals for good documentation on how to set this up and then fold it into our DRM plan, but I'm not finding much. Does anyone know how to do this? Thanks in advance! in order to do this, make sure there are no paths defined from your filer to your drives, only in that case will the TSM server use NDMP via the LAN and use the normal storage hierarchy (so you'll need to setup your ndmp nodes to backup to a 'normal' storagepool (DISK) Now that the data is coming into the normal hierarchy you can do the usual stuff. chapter 7 of the admin guide is your best reference: http://publib.boulder.ibm.com/infocenter/tivihelp/v1r1/topic/com.ibm.itsmaixn.doc/anragd55172.htm#nscfg Joni Moyer Highmark Storage Systems, Storage Mngt Analyst III Phone Number: (717)302-9966 Fax: (717) 302-9826 [EMAIL PROTECTED] -- Met vriendelijke groeten, Remco Post [EMAIL PROTECTED] +31 6 248 21 622
Re: Database size, Split to multiple instances or wait for version 6.1
Well, I'd say that you are doing great right now, if you can do a DB backup of 350 G from a Windows box in an hour and 15 minutes! The biggest problem you are likely to have, as mentioned, is the time it takes to do the conversion to 6.1 (or in the unlikely event you have a problem and need to do a DB audit before you get to 6.1). Here's something that might be useful, depending on your circumstances. If you look at the Occupancy table, it shows not only the amount of storage occupied by your clients, but the number of objects retained for each. Sum the objects for each client, and sort by client in descending order: select node_name, cast(sum(logical_mb/1024) as decimal(10,1)) as "GB" , sum(num_files) as "#Objects" from occupancy where stgpool_name in (select stgpool_name from stgpools where pooltype='PRIMARY') group by node_name order by 2 desc. At some of my customers, we find that there are just a handful of nodes responsible for 30-40% of the DB objects (imaging apps are usually the biggest offenders). If that is the case for you, that's a logical way to start splitting out your DB, by splitting out a handful of big (in terms of objects) clients. And if it's only a handful of nodes, I suspect it would also be the way that would have the least impact on de-dup. W On Thu, Dec 4, 2008 at 11:18 AM, Conradt, Jeremy < [EMAIL PROTECTED]> wrote: > Expiration takes about 1 hour. DB Backup takes about 1 hour 15 minutes. > > Thanks, > Jeremy > > -Original Message- > From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of > Wanda Prather > Sent: Wednesday, December 03, 2008 7:01 PM > To: ADSM-L@VM.MARIST.EDU > Subject: Re: [ADSM-L] Database size, Split to multiple instances or wait > for version 6.1 > > How long does it take you now to do Expiration and DB backup? > > > > On Wed, Dec 3, 2008 at 4:24 PM, Conradt, Jeremy < > [EMAIL PROTECTED]> wrote: > > > I have a TSM server currently running version 5.3.5 on Windows 2003 > > that we plan to upgrade soon. > > The problem I have is our database has grown to 350 GB. > > The question I have is will version 6.1 of TSM be better capable of > > maintaining a database this size and much larger or should I break it > > apart? > > I would rather keep everything together so we can make better use of > > de-duplication that may be coming out with version 6. > > Thanks, > > Jeremy > > > > > > >
Re: Database size, Split to multiple instances or wait for version 6.1
Are you mis-reading/writing that info?350GB takes 1-hour to expire and about the same to backup?? My 190GB DB used to take 48+ hours to run expire (350M objects) and 2-hours for a full backups! With recent cleanup/load balancing by moving nodes to a new server, the expires are down to 24-hours. "Conradt, Jeremy" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" 12/04/2008 11:28 AM Please respond to "ADSM: Dist Stor Manager" To ADSM-L@VM.MARIST.EDU cc Subject Re: [ADSM-L] Database size, Split to multiple instances or wait for version 6.1 Expiration takes about 1 hour. DB Backup takes about 1 hour 15 minutes. Thanks, Jeremy -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Wanda Prather Sent: Wednesday, December 03, 2008 7:01 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Database size, Split to multiple instances or wait for version 6.1 How long does it take you now to do Expiration and DB backup? On Wed, Dec 3, 2008 at 4:24 PM, Conradt, Jeremy < [EMAIL PROTECTED]> wrote: > I have a TSM server currently running version 5.3.5 on Windows 2003 > that we plan to upgrade soon. > The problem I have is our database has grown to 350 GB. > The question I have is will version 6.1 of TSM be better capable of > maintaining a database this size and much larger or should I break it > apart? > I would rather keep everything together so we can make better use of > de-duplication that may be coming out with version 6. > Thanks, > Jeremy > > >
NAS NDMP backups using a copy pool
Hello everyone, I recently upgraded a TSM AIX 5.3 server to 5.5.1.1 and would like to begin utilizing the copy pools for our offsite backups. I've been searching in the 5.5 manuals for good documentation on how to set this up and then fold it into our DRM plan, but I'm not finding much. Does anyone know how to do this? Thanks in advance! Joni Moyer Highmark Storage Systems, Storage Mngt Analyst III Phone Number: (717)302-9966 Fax: (717) 302-9826 [EMAIL PROTECTED]
Re: Database size, Split to multiple instances or wait for version 6.1
Ok, 350GB tsm db backing up in 1 hour? How did you get it that fast? Regards, Karel -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Conradt, Jeremy Sent: donderdag 4 december 2008 17:19 To: ADSM-L@VM.MARIST.EDU Subject: Re: Database size, Split to multiple instances or wait for version 6.1 Expiration takes about 1 hour. DB Backup takes about 1 hour 15 minutes. Thanks, Jeremy -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Wanda Prather Sent: Wednesday, December 03, 2008 7:01 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Database size, Split to multiple instances or wait for version 6.1 How long does it take you now to do Expiration and DB backup? On Wed, Dec 3, 2008 at 4:24 PM, Conradt, Jeremy < [EMAIL PROTECTED]> wrote: > I have a TSM server currently running version 5.3.5 on Windows 2003 > that we plan to upgrade soon. > The problem I have is our database has grown to 350 GB. > The question I have is will version 6.1 of TSM be better capable of > maintaining a database this size and much larger or should I break it > apart? > I would rather keep everything together so we can make better use of > de-duplication that may be coming out with version 6. > Thanks, > Jeremy > > > ÿþD i t b e r i c h t i s v e r t r o u w e l i j k e n k a n g e h e i m e i n f o r m a t i e b e v a t t e n e n k e l b e s t e m d v o o r d e g e a d r e s s e e r d e . I n d i e n d i t b e r i c h t n i e t v o o r u i s b e s t e m d , v e r z o e k e n w i j u d i t o n m i d d e l l i j k a a n o n s t e m e l d e n e n h e t b e r i c h t t e v e r n i e t i g e n . A a n g e z i e n d e i n t e g r i t e i t v a n h e t b e r i c h t n i e t v e i l i g g e s t e l d i s m i d d e l s v e r z e n d i n g v i a i n t e r n e t , k a n A t o s O r i g i n n i e t a a n s p r a k e l i j k w o r d e n g e h o u d e n v o o r d e i n h o u d d a a r v a n . H o e w e l w i j o n s i n s p a n n e n e e n v i r u s v r i j n e t w e r k t e h a n t e r e n , g e v e n w i j g e e n e n k e l e g a r a n t i e d a t d i t b e r i c h t v i r u s v r i j i s , n o c h a a n v a a r d e n w i j e n i g e a a n s p r a k e l i j k h e i d v o o r d e m o g e l i j k e a a n w e z i g h e i d v a n e e n v i r u s i n d i t b e r i c h t . O p a l o n z e r e c h t s v e r h o u d i n g e n , a a n b i e d i n g e n e n o v e r e e n k o m s t e n w a a r o n d e r A t o s O r i g i n g o e d e r e n e n / o f d i e n s t e n l e v e r t z i j n m e t u i t s l u i t i n g v a n a l l e a n d e r e v o o r w a a r d e n d e L e v e r i n g s v o o r w a a r d e n v a n A t o s O r i g i n v a n t o e p a s s i n g . D e z e w o r d e n u o p a a n v r a a g d i r e c t k o s t e l o o s t o e g e z o n d e n . T h i s e - m a i l a n d t h e d o c u m e n t s a t t a c h e d a r e c o n f i d e n t i a l a n d i n t e n d e d s o l e l y f o r t h e a d d r e s s e e ; i t m a y a l s o b e p r i v i l e g e d . I f y o u r e c e i v e t h i s e - m a i l i n e r r o r , p l e a s e n o t i f y t h e s e n d e r i m m e d i a t e l y a n d d e s t r o y i t . A s i t s i n t e g r i t y c a n n o t b e s e c u r e d o n t h e I n t e r n e t , t h e A t o s O r i g i n g r o u p l i a b i l i t y c a n n o t b e t r i g g e r e d f o r t h e m e s s a g e c o n t e n t . A l t h o u g h t h e s e n d e r e n d e a v o u r s t o m a i n t a i n a c o m p u t e r v i r u s - f r e e n e t w o r k , t h e s e n d e r d o e s n o t w a r r a n t t h a t t h i s t r a n s m i s s i o n i s v i r u s - f r e e a n d w i l l n o t b e l i a b l e f o r a n y d a m a g e s r e s u l t i n g f r o m a n y v i r u s t r a n s m i t t e d . O n a l l o f f e r s a n d a g r e e m e n t s u n d e r w h i c h A t o s O r i g i n s u p p l i e s g o o d s a n d / o r s e r v i c e s o f w h a t e v e r n a t u r e , t h e T e r m s o f D e l i v e r y f r o m A t o s O r i g i n e x c l u s i v e l y a p p l y . T h e T e r m s o f D e l i v e r y s h a l l b e p r o m p t l y s u b m i t t e d t o y o u o n y o u r r e q u e s t . A t o s O r i g i n N e d e r l a n d B . V . / U t r e c h t K v K U t r e c h t 3 0 1 3 2 7 6 2
Re: Database size, Split to multiple instances or wait for version 6.1
Expiration takes about 1 hour. DB Backup takes about 1 hour 15 minutes. Thanks, Jeremy -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Wanda Prather Sent: Wednesday, December 03, 2008 7:01 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Database size, Split to multiple instances or wait for version 6.1 How long does it take you now to do Expiration and DB backup? On Wed, Dec 3, 2008 at 4:24 PM, Conradt, Jeremy < [EMAIL PROTECTED]> wrote: > I have a TSM server currently running version 5.3.5 on Windows 2003 > that we plan to upgrade soon. > The problem I have is our database has grown to 350 GB. > The question I have is will version 6.1 of TSM be better capable of > maintaining a database this size and much larger or should I break it > apart? > I would rather keep everything together so we can make better use of > de-duplication that may be coming out with version 6. > Thanks, > Jeremy > > >
Re: SV: Journal unsync?
The "Journal" is extremely finicky. So much so that if you reboot the server you have to do a completely new backup of the drive the Journal service is watching so that the db will know what's going on again. Now, for those that did not backup, if they did not reboot you should be able to just pick up from where you left off after Day 1. ON those that HAD completed their backups you'll need to scratch the journal and do a new backup. I know, it stinks, but such was our experience. Unless they have drastically improved the journal service and stopped the crap they were doing before. We had such trouble out of it that we went to the disk cache method for backups instead. It's a little slower, and needs a good bit of disk space, but it's more reliable across reboots and crashes. See Ya' Howard > -Original Message- > From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf > Of Christian Svensson > Sent: Thursday, December 04, 2008 6:53 AM > To: ADSM-L@VM.MARIST.EDU > Subject: [ADSM-L] SV: Journal unsync? > > Hi Rich, > Please don't comment our setup. We got much better performance when we > moved from local disk to SAN and we have configure our SAN so it should > work perfect. > The issue was a Dell driver issue and nothing with the SAN. But we are > still talking to DELL to understand why this happened. > > I still wonder how Journal Database works in our case? > Will it understand that our TSM Database doesn't have all information > that the clients Journal Database has and will then do a roll-backward > of the information? > > Best Regards > Christian Svensson > > Cell: +46-70-325 1577 > E-mail: [EMAIL PROTECTED] > Skype: cristie.christian.svensson > > Från: ADSM: Dist Stor Manager [EMAIL PROTECTED] för Richard > Sims [EMAIL PROTECTED] > Skickat: den 4 december 2008 13:06 > Till: ADSM-L@VM.MARIST.EDU > Ämne: Re: Journal unsync? > > On Dec 4, 2008, at 4:18 AM, Christian Svensson wrote: > > > During the backup window and we say that maybe 50% of all our > > backups have run successfully and the other half is maybe in > > progress or are waiting for their time slot. But middle of the > > backup windows does my SAN go down and all my backups stops that > > mean 50% has run OK and 50% hasn't. > > Now when I try to start my TSM Server it shows up that my log files > > are corrupt and I need to do a TSM Database Recovery and my latest > > TSM DB Backup is from Day 1. > > Whoa, Christian... Are you saying that your TSM database is on an > unreliable SAN, rather than a far more reliable storage unit such as > local disk? This is the problem that really needs to be addressed, > rather than secondary effects. Your site is in great jeopardy where > its storage networking is unreliable *and* its fall-back data store > (TSM) is being crashed (and may be suffering damage you don't > immediately perceive, which could make some restorals impossible). > > Any issues with client backups needs to very much take a back seat > until the manifest problems with TSM server infrastructure are > corrected. TSM db recovery should be a very exceptional thing, and > not a routine consequence of unreliable storage. > > Richard Sims
SV: Journal unsync?
Hi Rich, Please don't comment our setup. We got much better performance when we moved from local disk to SAN and we have configure our SAN so it should work perfect. The issue was a Dell driver issue and nothing with the SAN. But we are still talking to DELL to understand why this happened. I still wonder how Journal Database works in our case? Will it understand that our TSM Database doesn't have all information that the clients Journal Database has and will then do a roll-backward of the information? Best Regards Christian Svensson Cell: +46-70-325 1577 E-mail: [EMAIL PROTECTED] Skype: cristie.christian.svensson Från: ADSM: Dist Stor Manager [EMAIL PROTECTED] för Richard Sims [EMAIL PROTECTED] Skickat: den 4 december 2008 13:06 Till: ADSM-L@VM.MARIST.EDU Ämne: Re: Journal unsync? On Dec 4, 2008, at 4:18 AM, Christian Svensson wrote: > During the backup window and we say that maybe 50% of all our > backups have run successfully and the other half is maybe in > progress or are waiting for their time slot. But middle of the > backup windows does my SAN go down and all my backups stops that > mean 50% has run OK and 50% hasn't. > Now when I try to start my TSM Server it shows up that my log files > are corrupt and I need to do a TSM Database Recovery and my latest > TSM DB Backup is from Day 1. Whoa, Christian... Are you saying that your TSM database is on an unreliable SAN, rather than a far more reliable storage unit such as local disk? This is the problem that really needs to be addressed, rather than secondary effects. Your site is in great jeopardy where its storage networking is unreliable *and* its fall-back data store (TSM) is being crashed (and may be suffering damage you don't immediately perceive, which could make some restorals impossible). Any issues with client backups needs to very much take a back seat until the manifest problems with TSM server infrastructure are corrected. TSM db recovery should be a very exceptional thing, and not a routine consequence of unreliable storage. Richard Sims
Re: Journal unsync?
On Dec 4, 2008, at 4:18 AM, Christian Svensson wrote: During the backup window and we say that maybe 50% of all our backups have run successfully and the other half is maybe in progress or are waiting for their time slot. But middle of the backup windows does my SAN go down and all my backups stops that mean 50% has run OK and 50% hasn't. Now when I try to start my TSM Server it shows up that my log files are corrupt and I need to do a TSM Database Recovery and my latest TSM DB Backup is from Day 1. Whoa, Christian... Are you saying that your TSM database is on an unreliable SAN, rather than a far more reliable storage unit such as local disk? This is the problem that really needs to be addressed, rather than secondary effects. Your site is in great jeopardy where its storage networking is unreliable *and* its fall-back data store (TSM) is being crashed (and may be suffering damage you don't immediately perceive, which could make some restorals impossible). Any issues with client backups needs to very much take a back seat until the manifest problems with TSM server infrastructure are corrected. TSM db recovery should be a very exceptional thing, and not a routine consequence of unreliable storage. Richard Sims
Journal unsync?
What's up all *SMers. It is close to x-mas and I hope you have been a good person so you got any presents this year also. :) >From one thing to another. I have a small question for you all. The scenario is like this. Day 1: I have over 400 Windows nodes that run daily backups to our TSM Server. We do also run TSM BA Client Journal on all our backups. Days 2: During the backup window and we say that maybe 50% of all our backups have run successfully and the other half is maybe in progress or are waiting for their time slot. But middle of the backup windows does my SAN go down and all my backups stops that mean 50% has run OK and 50% hasn't. Now when I try to start my TSM Server it shows up that my log files are corrupt and I need to do a TSM Database Recovery and my latest TSM DB Backup is from Day 1. Now to my question. Now is my database from Day 1 that mean I lose the 50% successfully backups and that is not a problem. But what happened with the Journal on does 50% servers? Because the Journal thinks the backup have been done on the file but the database don't think that. My questions is. Will the Journal resync it's database with TSM Server or will it still believe that the files are backed up and I need to delete the Journal Database and run a resync? Can anyone explain for me how it communicate with the TSM Server Database? Best Regards Christian Svensson Cell: +46-70-325 1577 E-mail: [EMAIL PROTECTED] Skype: cristie.christian.svensson
