TSM Copypool question
We have recently installed TSM 5.5 on a new server and using a new IBM TS3200 tape library. It took some time to migrate the data over from the tapes used in the old tape library to the new (migrating data from LTO2 LTO3 tapes to LTO4 tapes) but that has finally finished. While that was happening we were performing backups of client servers onto the new library, but I was not copying the data from the primary tape storage pool to the copypool to send offsite. I now wish to start this process. Is it possible to perform full backups of each client now to the primary storage pool and have the backed up data flagged so that if I start copying the data from the primary tape storage pool to the copypool via the backup stg command it will only copy the data from the full backups I do now onwards? Thanks Regards Paul Paul Dudley ANL Container Line Pty Limited Email: pdud...@anl.com.au Web: http://www.anl.com.au ANL DISCLAIMER This e-mail and any file attached is confidential, and intended solely to the named addressees. Any unauthorised dissemination or use is strictly prohibited. If you received this e-mail in error, please immediately notify the sender by return e-mail from your system. Please do not copy, use or make reference to it for any purpose, or disclose its contents to any person.
Re: TSM Copypool question
There is no way to copy only full backups, if any other backups are presented in primary pools. You have to expiry all previous backups before making copy - for example, just change temporary copy groups to have 1 day retention. Be careful with TSM database logs - do expiry process pool by pool and monitor TSM database. In general, I will advise you to copy all data to copy pools instead of expiring previous backups. Grigori G. Solonovitch Senior Technical Architect Information Technology Ahli United Bank Kuwait http://www.ahliunited.com.kw Phone: (+965) 2231-2274 Mobile: (+965) 99798073 E-Mail: grigori.solonovi...@ahliunited.com Please consider the environment before printing this Email -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Paul_Dudley Sent: Wednesday, June 23, 2010 10:25 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TSM Copypool question We have recently installed TSM 5.5 on a new server and using a new IBM TS3200 tape library. It took some time to migrate the data over from the tapes used in the old tape library to the new (migrating data from LTO2 LTO3 tapes to LTO4 tapes) but that has finally finished. While that was happening we were performing backups of client servers onto the new library, but I was not copying the data from the primary tape storage pool to the copypool to send offsite. I now wish to start this process. Is it possible to perform full backups of each client now to the primary storage pool and have the backed up data flagged so that if I start copying the data from the primary tape storage pool to the copypool via the backup stg command it will only copy the data from the full backups I do now onwards? Thanks Regards Paul Paul Dudley ANL Container Line Pty Limited Email: pdud...@anl.com.au Web: http://www.anl.com.au ANL DISCLAIMER This e-mail and any file attached is confidential, and intended solely to the named addressees. Any unauthorised dissemination or use is strictly prohibited. If you received this e-mail in error, please immediately notify the sender by return e-mail from your system. Please do not copy, use or make reference to it for any purpose, or disclose its contents to any person. Please consider the environment before printing this Email. CONFIDENTIALITY AND WAIVER: The information contained in this electronic mail message and any attachments hereto may be legally privileged and confidential. The information is intended only for the recipient(s) named in this message. If you are not the intended recipient you are notified that any use, disclosure, copying or distribution is prohibited. If you have received this in error please contact the sender and delete this message and any attachments from your computer system. We do not guarantee that this message or any attachment to it is secure or free from errors, computer viruses or other conditions that may damage or interfere with data, hardware or software.
Re: TSM 6.2 server AIX installation issue
I have installed 6.2 on AIX 6.1 in the last few days, fine onto two difference servers, I haven't seen that issue. Have you had anything useful back from IBM?? Jane Baker AIX Technical Specialist AIX/BASIS TEAM -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Robert Clark Sent: 19 June 2010 02:04 To: ADSM-L@vm.marist.edu Subject: Re: [ADSM-L] TSM 6.2 server AIX installation issue This is a Friday afternoon, just about to go home guess: If your AIX box doesn't have the X11 libraries installed, (for example if it is headless), you may need SWING, which needs AWT, which comes in one of the X11 filesets. If installing X11 filesets resolves the issue, then the install doc would likely need to be revised to include X11 filesets must be installed. Thanks, [RC] From: Pawlos Gizaw pawlos.gi...@sanofi-aventis.com To: ADSM-L@VM.MARIST.EDU Date: 06/17/2010 07:03 AM Subject: [ADSM-L] TSM 6.2 server AIX installation issue Sent by: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU Has anyone tried to install TSM 6.2 on AIX (6.1). I keep getting an error message that Content is not allowed in prolog. I tried silent and wizard but got same message. The systems has all the minimum requirements. Thu Jun 17 00:51:33.448 EDT 2010 : FINEST : User interface type:SWING (from com.ibm.ac.coi.ext.ia.plugin.COIProcessInventorySteps.install) Thu Jun 17 00:51:46.063 EDT 2010 : SEVERE : Aborting installer: Content is not allowed in prolog. (from com.ibm.ac.coi.ext.ia.plugin.COIProcessInventorySteps.install). Thanks Pawlos U.S. BANCORP made the following annotations - Electronic Privacy Notice. This e-mail, and any attachments, contains information that is, or may be, covered by electronic communications privacy laws, and is also confidential and proprietary in nature. If you are not the intended recipient, please be advised that you are legally prohibited from retaining, using, copying, distributing, or otherwise disclosing this information in any manner. Instead, please reply to the sender that you have received this communication in error, and then immediately delete it. Thank you in advance for your cooperation. - Please check that this email is addressed to you. If not, you should delete it immediately as its contents may be confidential and its disclosure, copying or distribution unlawful. C. J. Clark International Limited takes steps to prevent the transmission of electronic viruses but responsibility for screening incoming messages and the risk of such transmission lies with the recipient. C. J. Clark International Limited Trading as Clarks, Registered in England number 141015.Registered office 40 High Street, Street, Somerset. BA16 0EQ. England. This message has been scanned for viruses by MailControl - www.MailControl.com
Unable to setup tdpo
further info sbttest a -libname /usr/tivoli/tsm/client/oracle/bin64/tdpo.opt /usr/tivoli/tsm/client/oracle/bin64/tdpo.opt could not be loaded. Check that it is installed properly, and that LD_LIBRARY_PATH environment variable (or its equivalent on your platform) includes the directory where this file can be found. Here is some additional information on the cause of this error: 0509-022 Cannot load module /usr/tivoli/tsm/client/oracle/bin64/tdpo.opt. 0509-103 The module has an invalid magic number. $ +-- |This was sent by danny...@gmail.com via Backup Central. |Forward SPAM to ab...@backupcentral.com. +--
Re: Unable to setup tdpo
Refer to your sbttest documentation and have -libname specify what it actually should be. On Jun 23, 2010, at 5:46 AM, dannywcw wrote: further info sbttest a -libname /usr/tivoli/tsm/client/oracle/bin64/tdpo.opt /usr/tivoli/tsm/client/oracle/bin64/tdpo.opt could not be loaded. ...
Re: Windows 2003 Device Driver
Mark I believe the behaviour you're seeing is by design. IBM chose a number that was larger than the expected maximum number of tape drives. The actual number chosen as the seed for the persistent tape names is 4801101 because it's hex equivalent is 0x49424d, and this in turn is the ASCII codes for IBM strung together. More of an in-joke among the device driver developers than anything more complex, I suspect. Regards Neil - Find out how our new character Numptee is causing all sorts of problems by putting the wrong things down his toilet and drains - check out his videos and look at what you can do to help keep your drains running free. Visit http://www.yorkshirewater.com/binit The information in this e-mail is confidential and may also be legally privileged. The contents are intended for recipient only and are subject to the legal notice available at http://www.keldagroup.com/email.htm Yorkshire Water Services Limited Registered Office Western House Halifax Road Bradford BD6 2SZ Registered in England and Wales No 2366682
Re: ESXi and ESX
The new integration with TSM V6 and the new vStorage API is the recommended way to go with TSM. Replaces VCB and is supported going forward. Integrates with your Virtual Center server. Haven't implemented this yet. But unless they've changed things my VMware-guy told me that recovery using this method is 2-phase. You first restore the backup snapshot, but then you have to run it through the converter to get an actual running VM again. Just about doubles your recovery time. You can still back them up from the console using the client (http://www-01.ibm.com/support/docview.wss?uid=swg27009931) but I've heard that this capability will be unavailable in future releases of ESX. The new VDR appliance is OK, but as others have said it does have limitations. -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Storer, Raymond Sent: Tuesday, June 22, 2010 3:12 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: ESXi and ESX Tim, when it comes to VCB backups so long as your VCB Proxy can see the disk the VM is on you can perform a VCB backup of it. If not, you can't. Ray -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Timothy Hughes Sent: Tuesday, June 22, 2010 11:48 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] ESXi and ESX Question, Is there any documentation on backing up a VM that's on a different TSM Server that the PROXY or the VCB server? Both the Proxy and the VCB server's are Windows boxes. Tim Prather, Wanda wrote: HI Alan. Most of my customers who are moving into VM for production systems need/want full VM backups as well as TSM-type file-level backups. The full VM backup is an image backup of the .vmdk file containing the VM guest. The horror of running production apps on Windows is the dreaded DR situation. Since MS doesn't have a supported method for doing Bare-metal recovery to different hardware, recovery of a Windows system to different hardware at DR is a slow, multi-step process prone to complications. However, if you have a copy of the .vmdk, you can drop it back onto an ESX server at DR, in one step, and you DONT have to deal with the move to unlike hardware and the universe of issues dealing with Windows system state. And you can't get those .vmdk images with the TSM client. While it is possible to do file-by-file BMR for a VM guest, it's not something I'd recommend if .vmdk images are available. TSM file-level backups are still useful for versioning. I have 2 customers using TSM (installed on the guest in the normal way) for the VM file-level backups, and full VM's for DR. The problem with using VCB, is that doing those full VM's puts you back into the business of dumping LOTS of data every week. I much prefer the use of VDR, which is VM's replacement tool for backups in V4. With VDR you get your fullvm's, but deduped into a disk repository. Then you back up the repository using TSM subfile backup. Your first step then at DR, is to restore the repository from TSM tape. Etc. If you need more info, feel free to contact me directly. Wanda -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Allen S. Rout Sent: Tuesday, June 22, 2010 11:14 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] ESXi and ESX On Tue, 22 Jun 2010 13:41:48 +0200, louw pretorius l...@sun.ac.za said: 1. VCB is still officially the right way for backing up VM's from VMware's (and IBM's) perspective and TSM 6.2 has some nice enhancements to get this done. I'm aware that using VCB permits you to shift backup work from the real server to some proxy. Is there any other reason to prefer VCB to simply managing your guests like any other machine? - Allen S. Rout CONFIDENTIALITY NOTICE: This email and any attachments are for the exclusive and confidential use of the intended recipient. If you are not the intended recipient, please do not read, distribute or take action in reliance upon this message. If you have received this in error, please notify us immediately by return email and promptly delete this message and its attachments from your computer system. We do not waive attorney-client or work product privilege by the transmission of this message.
Unable to setup tdpo
problem solved by re-register node to tsm server. +-- |This was sent by danny...@gmail.com via Backup Central. |Forward SPAM to ab...@backupcentral.com. +--
Changing management class wihtout retransferring all data
Hi, is there a possibility to change the management class without transfering the data again to TSM server? We have to change the management class of approx. 50TB of data (12 millions files) and we don't want to backup all the data again. Thanks. Alex
Re: ESXi and ESX
FYI: As per IBM support and the doco VCB is still utilized in version 6.2 for the snapshot (or full image). But it does use the vStorage API's for the FLR. Our rep told me that they are working to eliminate the use of VCB and should be available later this year (no ETA yet). For futher info reference the 6.2 Backup/Archive client manual, page 140. ~Rick Adamson Jax, Fl. -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Bill Boyer Sent: Wednesday, June 23, 2010 9:36 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] ESXi and ESX The new integration with TSM V6 and the new vStorage API is the recommended way to go with TSM. Replaces VCB and is supported going forward. Integrates with your Virtual Center server. Haven't implemented this yet. But unless they've changed things my VMware-guy told me that recovery using this method is 2-phase. You first restore the backup snapshot, but then you have to run it through the converter to get an actual running VM again. Just about doubles your recovery time. You can still back them up from the console using the client (http://www-01.ibm.com/support/docview.wss?uid=swg27009931) but I've heard that this capability will be unavailable in future releases of ESX. The new VDR appliance is OK, but as others have said it does have limitations. -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Storer, Raymond Sent: Tuesday, June 22, 2010 3:12 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: ESXi and ESX Tim, when it comes to VCB backups so long as your VCB Proxy can see the disk the VM is on you can perform a VCB backup of it. If not, you can't. Ray -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Timothy Hughes Sent: Tuesday, June 22, 2010 11:48 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] ESXi and ESX Question, Is there any documentation on backing up a VM that's on a different TSM Server that the PROXY or the VCB server? Both the Proxy and the VCB server's are Windows boxes. Tim Prather, Wanda wrote: HI Alan. Most of my customers who are moving into VM for production systems need/want full VM backups as well as TSM-type file-level backups. The full VM backup is an image backup of the .vmdk file containing the VM guest. The horror of running production apps on Windows is the dreaded DR situation. Since MS doesn't have a supported method for doing Bare-metal recovery to different hardware, recovery of a Windows system to different hardware at DR is a slow, multi-step process prone to complications. However, if you have a copy of the .vmdk, you can drop it back onto an ESX server at DR, in one step, and you DONT have to deal with the move to unlike hardware and the universe of issues dealing with Windows system state. And you can't get those .vmdk images with the TSM client. While it is possible to do file-by-file BMR for a VM guest, it's not something I'd recommend if .vmdk images are available. TSM file-level backups are still useful for versioning. I have 2 customers using TSM (installed on the guest in the normal way) for the VM file-level backups, and full VM's for DR. The problem with using VCB, is that doing those full VM's puts you back into the business of dumping LOTS of data every week. I much prefer the use of VDR, which is VM's replacement tool for backups in V4. With VDR you get your fullvm's, but deduped into a disk repository. Then you back up the repository using TSM subfile backup. Your first step then at DR, is to restore the repository from TSM tape. Etc. If you need more info, feel free to contact me directly. Wanda -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Allen S. Rout Sent: Tuesday, June 22, 2010 11:14 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] ESXi and ESX On Tue, 22 Jun 2010 13:41:48 +0200, louw pretorius l...@sun.ac.za said: 1. VCB is still officially the right way for backing up VM's from VMware's (and IBM's) perspective and TSM 6.2 has some nice enhancements to get this done. I'm aware that using VCB permits you to shift backup work from the real server to some proxy. Is there any other reason to prefer VCB to simply managing your guests like any other machine? - Allen S. Rout CONFIDENTIALITY NOTICE: This email and any attachments are for the exclusive and confidential use of the intended recipient. If you are not the intended recipient, please do not read, distribute or take action in reliance upon this message. If you have received this in error, please notify us immediately by return email and promptly delete this message and its attachments from your computer system. We do not waive attorney-client or work product privilege by the transmission of this message.
Re: Changing management class wihtout retransferring all data
If you change the management class (for example by adding an INCLUDE statement to bind a file to a different management class), the next time you run a backup you will see files rebound n in the statistics. TSM will just change the management class for the files it finds (files that still exist on the hard drive). It will not resend the data. There is not a way to change the management class for inactive files that no longer exist on the hard drive. -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Alexander Födisch Sent: Wednesday, June 23, 2010 9:49 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Changing management class wihtout retransferring all data Hi, is there a possibility to change the management class without transfering the data again to TSM server? We have to change the management class of approx. 50TB of data (12 millions files) and we don't want to backup all the data again. Thanks. Alex
Re: Getting backup duration in TSM 6.2 select statement
I feel your pain. The conversion guide says there are changes to the way SELECT does time calculation, but it is very non-specific (and the example it gives is incorrect). The timestampdiff function appears to work consistently. It's documented in the DB2 SQL guide. An example: select timestampdiff(8,cast( (current_timestamp-last_backup_date) as char(22))) as DBHRS from db /* 2 seconds /* 4 minutes /* 8 hours /* 16 days /* 32 weeks /* 64 months /*128 quarters /*256 years -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Gary Bowers Sent: Monday, June 21, 2010 3:00 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Getting backup duration in TSM 6.2 select statement I must be missing something. It used to be that we could use the following select statement to get event durations from the summary table. select event, (end_time - start_time) seconds from summary. I am keeping this simple for illustrative purposes. I verified that this works as expected in 5.5. This used to return the total number of seconds that an event like a backup or migration ran. Now it returns just the number of seconds. For instance. If the process took 1 hour 20 minutes and 30 seconds, the command should return 4800 seconds. Instead it just returns 30. The number of seconds in the timestamp field. If I run the same select statement for minutes I get 20 instead of 80... etc. This seems to only be problem with the summary table, as running a select from the processes table works as expected. Does anyone else see this??? I am running TSM 6.2.1.0 on AIX 6.1. I am having to rewrite all kinds of scripts in order to accomodate this. I know that we are supposed to cast the timestamp as an integer, but I have not had any luck with that either. That just helps me do math with it like in calculating backup speeds. Any help is appreciated.
Re: Getting backup duration in TSM 6.2 select statement
Hello, indeed, the documentation is incorrect and time calculation changed. We have apar IC67375 that makes changes to the documentation. You can find the apar here : http://www-1.ibm.com/support/docview.wss?uid=swg1IC67375 Rejean Larivee IBM Tivoli Storage Manager Level 2 support. ADSM: Dist Stor Manager ADSM-L@vm.marist.edu wrote on 06/23/2010 11:37:40 AM: [image removed] Re: Getting backup duration in TSM 6.2 select statement Prather, Wanda to: ADSM-L 06/23/2010 11:38 AM Sent by: ADSM: Dist Stor Manager ADSM-L@vm.marist.edu Please respond to ADSM: Dist Stor Manager I feel your pain. The conversion guide says there are changes to the way SELECT does time calculation, but it is very non-specific (and the example it gives is incorrect). The timestampdiff function appears to work consistently. It's documented in the DB2 SQL guide. An example: select timestampdiff(8,cast( (current_timestamp-last_backup_date) as char(22))) as DBHRS from db /* 2 seconds /* 4 minutes /* 8 hours /* 16 days /* 32 weeks /* 64 months /*128 quarters /*256 years -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Gary Bowers Sent: Monday, June 21, 2010 3:00 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Getting backup duration in TSM 6.2 select statement I must be missing something. It used to be that we could use the following select statement to get event durations from the summary table. select event, (end_time - start_time) seconds from summary. I am keeping this simple for illustrative purposes. I verified that this works as expected in 5.5. This used to return the total number of seconds that an event like a backup or migration ran. Now it returns just the number of seconds. For instance. If the process took 1 hour 20 minutes and 30 seconds, the command should return 4800 seconds. Instead it just returns 30. The number of seconds in the timestamp field. If I run the same select statement for minutes I get 20 instead of 80... etc. This seems to only be problem with the summary table, as running a select from the processes table works as expected. Does anyone else see this??? I am running TSM 6.2.1.0 on AIX 6.1. I am having to rewrite all kinds of scripts in order to accomodate this. I know that we are supposed to cast the timestamp as an integer, but I have not had any luck with that either. That just helps me do math with it like in calculating backup speeds. Any help is appreciated.
NAS vs traditional fileservers
We currently use traditional windows fileservers, but are being presented with an opportunity to start using a NAS device. I've been reading up on NDMP, doesn't sound to me like NAS is the backup admin's friend. Can anyone who has gone down this road share any of the biggest pros/cons/gotchas? I seem to recall from several years ago that getting the backup data offsite was an issue, but the NAS vendor claims this is no longer true. Currently using half a dozen fileservers to manage about 20TB of user data. Thanks, Steve Schaub Systems Engineer, Windows BlueCross BlueShield of Tennessee - Please see the following link for the BlueCross BlueShield of Tennessee E-mail disclaimer: http://www.bcbst.com/email_disclaimer.shtm
Re: TSM Copypool question
- rename your current primary and copy pools to something else such as primarypool.old and copypool.old - create new primary and copy pools and begin your new full backups to that pool. and only run backup stg on the new pool moving forward Regards, Shawn Shawn Drew Internet pdud...@anl.com.au Sent by: ADSM-L@VM.MARIST.EDU 06/23/2010 03:24 AM Please respond to ADSM-L@VM.MARIST.EDU To ADSM-L cc Subject [ADSM-L] TSM Copypool question We have recently installed TSM 5.5 on a new server and using a new IBM TS3200 tape library. It took some time to migrate the data over from the tapes used in the old tape library to the new (migrating data from LTO2 LTO3 tapes to LTO4 tapes) but that has finally finished. While that was happening we were performing backups of client servers onto the new library, but I was not copying the data from the primary tape storage pool to the copypool to send offsite. I now wish to start this process. Is it possible to perform full backups of each client now to the primary storage pool and have the backed up data flagged so that if I start copying the data from the primary tape storage pool to the copypool via the backup stg command it will only copy the data from the full backups I do now onwards? Thanks Regards Paul Paul Dudley ANL Container Line Pty Limited Email: pdud...@anl.com.au Web: http://www.anl.com.au ANL DISCLAIMER This e-mail and any file attached is confidential, and intended solely to the named addressees. Any unauthorised dissemination or use is strictly prohibited. If you received this e-mail in error, please immediately notify the sender by return e-mail from your system. Please do not copy, use or make reference to it for any purpose, or disclose its contents to any person. 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.
Re: NAS vs traditional fileservers
We've been backing up one NAS system with NDMP filer-to-server for about 2 years now, it's currently at around 16TB. In our particular setup, we rely on backups fitting on disk before going to tape. As such, we've had to size the disk pool for that client to match the NAS size. We hit a problem recently when they grew one filesystem to 10TB. IBM developers found an 8.7TB size limit in disk pools, so backups were going directly to tape and being preempted by the morning migrations. We got around this by backing up to virtual volumes on another instance with a large disk pool. Of course NDMP backups are full/differentials, so the retention policies you're used to are pretty much out the window. If it's a NetApp device, you can back it up with a regular TSM client using the snapdiff option. Even given the limitations of CIFS (slw), in my limited testing I've found the savings from not having to do full/differentials to be a big win. There's also a savings in tape occupancy, since files that haven't changed aren't backed up again. Clients charge on occupancy, like ours, like this. I'm not sure what you mean about getting data offsite, but we're able to do our normal copy pools with NDMP backups. - Cameron Hanover chano...@umich.edu When any government, or church for that matter, undertakes to say to its subjects, this you may not read, this you must not see, this you are forbidden to know, the end result is tyranny and oppression, no matter how holy the motive. --Robert A. Heinlein On Jun 23, 2010, at 11:39 AM, Schaub, Steve wrote: We currently use traditional windows fileservers, but are being presented with an opportunity to start using a NAS device. I've been reading up on NDMP, doesn't sound to me like NAS is the backup admin's friend. Can anyone who has gone down this road share any of the biggest pros/cons/gotchas? I seem to recall from several years ago that getting the backup data offsite was an issue, but the NAS vendor claims this is no longer true. Currently using half a dozen fileservers to manage about 20TB of user data. Thanks, Steve Schaub Systems Engineer, Windows BlueCross BlueShield of Tennessee - Please see the following link for the BlueCross BlueShield of Tennessee E-mail disclaimer: http://www.bcbst.com/email_disclaimer.shtm
Re: NAS vs traditional fileservers
We are in the same situation - possibly changing from Win Servers (using some kind of microsoft replication) with BA client backups to NAS systems . . .about +20tb of data also. So I'm also interested in any comments. I've been reading the vendor manuals, TSM doc's and Redbooks, this mailing list archive and anything else that Google finds. Here is what I think I've found out . . 2 ways to backup NAS: BA client on a CIFS share, and NDMP. NDMP: - uses full/incremental/differential backups - ndmp on netapp can be either file level or block/volume level - ndmp on celerra is only file level - file level ndmp backups are still file backups - lots of little files will STILL be a challenge! - a tsm ndmp pool cannot be migrated, reclaimed, movedata'ed - not sure about copy pools - it's the tsm management class that determines how long the backup is retained BA Client on a Share: - no journal backups (it's not a win filsystem!) - CIFS is slow - backups will take a long time - you do get to keep using your normal TSM mgt class policies - for netapp, there is a new snapdiff which provides journal like capabilities (saw some emails that this was very good!) The main point I've come away with is that switching to a NAS will not solve our backup problems . . .just change problems somewhat. I would appreciate any comments, additions, and especially CORRECTIONS. Thanks! Rick ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU wrote on 06/23/2010 11:39:35 AM: We currently use traditional windows fileservers, but are being presented with an opportunity to start using a NAS device. I've been reading up on NDMP, doesn't sound to me like NAS is the backup admin's friend. Can anyone who has gone down this road share any of the biggest pros/cons/gotchas? I seem to recall from several years ago that getting the backup data offsite was an issue, but the NAS vendor claims this is no longer true. Currently using half a dozen fileservers to manage about 20TB of user data. Thanks, Steve Schaub Systems Engineer, Windows BlueCross BlueShield of Tennessee - Please see the following link for the BlueCross BlueShield of Tennessee E-mail disclaimer: http://www.bcbst.com/email_disclaimer.shtm - The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message.
Re: NAS vs traditional fileservers
-TSM NDMP support will give you full or differentials only. No file level backups. You CAN do file-level restores. The nasty bit: however many versions of files you want to keep, you have to keep your NDMP fulls that far back. (Can you say buy stock in tape media companies and budget for a bigger library?) -Besides the excessive amount of media you need in order to keep multiple versions of 20TB full dumps, it will change the way you do restores. The only person who will have access to the restore capability is a TSM admin with SYSTEM level authority. That is very inconvenient for some of my customers, where the filesever admins can do their own restores by starting the TSM client from their console. -I have no vested interest, I don't sell hardware, but I would opt for the Netapp if possible because of the SNAPDIFF support. Why other vendors haven't provided that API I can't figure out. That is definitely the only true solution to the backup problem. -Whether you can create copy pools or not, depends on how you set up the TSM NDMP definitions. How you set up the TSM NDMP definitions depends on whether you have your tape drives direct-connected to the TSM server, or you plan to do your NDMP dumps over TCP/IP. Read Chap. 7 in the TSM admin guide on using NDMP. Read it again. About the 3rd time, it will start to make sense. -If you are going to NAS, remember to keep your LUNS a reasonable size; you don't want to have to scan a TB if you back up with CIFS, or dump a TB if you decide to do it with NDMP. -I think NDMP is just a bad idea all over, if you don't have SNAPDIFF. You have a backup product with the architecture and capability to a) back up only changed files, b) keep different files with different retention rules, and c) dedup on the client end with TSM 6.2. You give all that up and go back to something totally primitive with NDMP. -What I have done for some of my customers is go the CIFS route, but use multiple proxy servers. Have server A do its own backups, plus a PROXY backup for one of the NAS shares. Have server B do its own backups, plus a PROXY backup for another one of the NAS shares. Etc. So yes CIFS is slow, but if multiple servers each do a bit, it all gets done, which it won't if you have just 1 machine trying to scan a zillion tiny files on all those shares. And by using PROXYNODE, the backups all end up as filespaces belonging to 1 TSM node. That lets you move/change the PROXY servers as your load moves, and makes it easy to find things when restoring. -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Richard Rhodes Sent: Wednesday, June 23, 2010 12:29 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] NAS vs traditional fileservers We are in the same situation - possibly changing from Win Servers (using some kind of microsoft replication) with BA client backups to NAS systems . . .about +20tb of data also. So I'm also interested in any comments. I've been reading the vendor manuals, TSM doc's and Redbooks, this mailing list archive and anything else that Google finds. Here is what I think I've found out . . 2 ways to backup NAS: BA client on a CIFS share, and NDMP. NDMP: - uses full/incremental/differential backups - ndmp on netapp can be either file level or block/volume level - ndmp on celerra is only file level - file level ndmp backups are still file backups - lots of little files will STILL be a challenge! - a tsm ndmp pool cannot be migrated, reclaimed, movedata'ed - not sure about copy pools - it's the tsm management class that determines how long the backup is retained BA Client on a Share: - no journal backups (it's not a win filsystem!) - CIFS is slow - backups will take a long time - you do get to keep using your normal TSM mgt class policies - for netapp, there is a new snapdiff which provides journal like capabilities (saw some emails that this was very good!) The main point I've come away with is that switching to a NAS will not solve our backup problems . . .just change problems somewhat. I would appreciate any comments, additions, and especially CORRECTIONS. Thanks! Rick ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU wrote on 06/23/2010 11:39:35 AM: We currently use traditional windows fileservers, but are being presented with an opportunity to start using a NAS device. I've been reading up on NDMP, doesn't sound to me like NAS is the backup admin's friend. Can anyone who has gone down this road share any of the biggest pros/cons/gotchas? I seem to recall from several years ago that getting the backup data offsite was an issue, but the NAS vendor claims this is no longer true. Currently using half a dozen fileservers to manage about 20TB of user data. Thanks, Steve Schaub Systems Engineer, Windows BlueCross BlueShield of Tennessee - Please see the following link for the BlueCross BlueShield of
Re: NAS vs traditional fileservers
I am using NDMP on EMC Celera. I have done reclaim and movedata, but not migrate. Expires on NDMP runs very fast as it only looks at whole backups (full or differential). Instead of looking at hundreds of thousand little files, in expires the entire backup. -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Richard Rhodes Sent: Wednesday, June 23, 2010 9:29 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: NAS vs traditional fileservers We are in the same situation - possibly changing from Win Servers (using some kind of microsoft replication) with BA client backups to NAS systems . . .about +20tb of data also. So I'm also interested in any comments. I've been reading the vendor manuals, TSM doc's and Redbooks, this mailing list archive and anything else that Google finds. Here is what I think I've found out . . 2 ways to backup NAS: BA client on a CIFS share, and NDMP. NDMP: - uses full/incremental/differential backups - ndmp on netapp can be either file level or block/volume level - ndmp on celerra is only file level - file level ndmp backups are still file backups - lots of little files will STILL be a challenge! - a tsm ndmp pool cannot be migrated, reclaimed, movedata'ed - not sure about copy pools - it's the tsm management class that determines how long the backup is retained BA Client on a Share: - no journal backups (it's not a win filsystem!) - CIFS is slow - backups will take a long time - you do get to keep using your normal TSM mgt class policies - for netapp, there is a new snapdiff which provides journal like capabilities (saw some emails that this was very good!) The main point I've come away with is that switching to a NAS will not solve our backup problems . . .just change problems somewhat. I would appreciate any comments, additions, and especially CORRECTIONS. Thanks! Rick ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU wrote on 06/23/2010 11:39:35 AM: We currently use traditional windows fileservers, but are being presented with an opportunity to start using a NAS device. I've been reading up on NDMP, doesn't sound to me like NAS is the backup admin's friend. Can anyone who has gone down this road share any of the biggest pros/cons/gotchas? I seem to recall from several years ago that getting the backup data offsite was an issue, but the NAS vendor claims this is no longer true. Currently using half a dozen fileservers to manage about 20TB of user data. Thanks, Steve Schaub Systems Engineer, Windows BlueCross BlueShield of Tennessee - Please see the following link for the BlueCross BlueShield of Tennessee E-mail disclaimer: http://www.bcbst.com/email_disclaimer.shtm - The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message.
Re: NAS vs traditional fileservers
On Wed, Jun 23, 2010 at 11:51:14AM -0500, Prather, Wanda wrote: -I think NDMP is just a bad idea all over, if you don't have SNAPDIFF. You have a backup product with the architecture and capability to a) back up only changed files, b) keep different files with different retention rules, and c) dedup on the client end with TSM 6.2. You give all that up and go back to something totally primitive with NDMP. I would agree. Plus, NDMP just feels badly bolted onto the side of TSM. And we ran into this as well, while NDMP is a standard, everyone does is just differently enough that you get into that ball of headaches. We have a rather large client where we're having to do the proxy-run the BA client on a box that has the space NFS mounted dance because while whatever appliance they have does NDMP, it does it just differently enough that we couldn't get it to work with our current TSM setup. So, if you're thinking of NDMP you really need to try it first to make sure it actually works before committing to it. Like my collegue pointed out, we've been trying SNAPDIFF with some IBM re-branded NetApp boxes and seem to be having good luck with it so far. -- Thomas L. Kula | tk...@umich.edu | 734.764.6531 Information and Technology Services University of Michigan
Re: NAS vs traditional fileservers
We're in the middle of doing something similar. We have 17TB of windows file/print data being backed up by 5 servers, total of 33M files. Several of the volumes are almost 2TB with several million files and all of the problems associated with that. So the windows guy is moving all of this to CIFS and we'll (hopefully) end up with several smaller volumes. We did some testing using TSM 6.1.3.4 and NDMP full/diff to TS1120 tape. Backup times for 2 of the 3 test volumes was not that great, around 18MB/sec. The third volume backed up in half the time. According to the Netapp guy, some kind of contention/hotspot on the filer. This is backing up filer-server, not filer-tape. And filer-server allows you to do all of the traditional housekeeping tasks on the storage pools. Looked like it would be doable, until we added up all of the problems: 1. As mentioned elsewhere, the differentials, though just a fraction of the fulls estimate their size as the same as the fulls, so disk pools for the differentials were out, meaning all of the dozens of differentials every night would need a tape drive. A big scheduling headache, but not a show-stopper. 2. We tested TOC to get individual file restore capability. Performance was terrible; over an hour to restore one 50MB file. Only good news here is that increasing the size and number of files restored did not have an equivalent increase in restore time and the proposal was to keep enough snapshots to restore back two weeks. So the individual restore would be a last resort. 3. It appeared the tape compression on NDMP data was not nearly as good as on normal backups, leading to an increase in the number of tapes needed. 4. You will need a filer at your DR site to perform restores there. There was not enough upside to counteract the downsides for us, so we are going to use the SNAPDIFF feature for this application and use NDMP for a couple of big applications that were using image backups. NDMP ended up being over twice as fast for these. Sam Sheppard San Diego Data Processing Corp. (858)-581-9668 -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Schaub, Steve Sent: Wednesday, June 23, 2010 8:40 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] NAS vs traditional fileservers We currently use traditional windows fileservers, but are being presented with an opportunity to start using a NAS device. I've been reading up on NDMP, doesn't sound to me like NAS is the backup admin's friend. Can anyone who has gone down this road share any of the biggest pros/cons/gotchas? I seem to recall from several years ago that getting the backup data offsite was an issue, but the NAS vendor claims this is no longer true. Currently using half a dozen fileservers to manage about 20TB of user data. Thanks, Steve Schaub Systems Engineer, Windows BlueCross BlueShield of Tennessee - Please see the following link for the BlueCross BlueShield of Tennessee E-mail disclaimer: http://www.bcbst.com/email_disclaimer.shtm
Re: NAS vs traditional fileservers
The NAS vendor is recommending that the NAS box both dedup and compress the files on it. This sounds good for space, but I'm thinking that this will cause NDMP backup to take even longer. I'm think if I do a NDMP full of +20tb of data and that data is all compressed, it's the same as uncompressing all that data to send it to TSM. ALso, the dedup would need to be un-deduped before sending it. Any thoughts on this? Rick Sheppard, Sam sshepp...@sddpc. ORG To Sent by: ADSM: ADSM-L@VM.MARIST.EDU Dist Stor cc Manager ads...@vm.marist Subject .EDU Re: NAS vs traditional fileservers 06/23/2010 01:04 PM Please respond to ADSM: Dist Stor Manager ads...@vm.marist .EDU We're in the middle of doing something similar. We have 17TB of windows file/print data being backed up by 5 servers, total of 33M files. Several of the volumes are almost 2TB with several million files and all of the problems associated with that. So the windows guy is moving all of this to CIFS and we'll (hopefully) end up with several smaller volumes. We did some testing using TSM 6.1.3.4 and NDMP full/diff to TS1120 tape. Backup times for 2 of the 3 test volumes was not that great, around 18MB/sec. The third volume backed up in half the time. According to the Netapp guy, some kind of contention/hotspot on the filer. This is backing up filer-server, not filer-tape. And filer-server allows you to do all of the traditional housekeeping tasks on the storage pools. Looked like it would be doable, until we added up all of the problems: 1. As mentioned elsewhere, the differentials, though just a fraction of the fulls estimate their size as the same as the fulls, so disk pools for the differentials were out, meaning all of the dozens of differentials every night would need a tape drive. A big scheduling headache, but not a show-stopper. 2. We tested TOC to get individual file restore capability. Performance was terrible; over an hour to restore one 50MB file. Only good news here is that increasing the size and number of files restored did not have an equivalent increase in restore time and the proposal was to keep enough snapshots to restore back two weeks. So the individual restore would be a last resort. 3. It appeared the tape compression on NDMP data was not nearly as good as on normal backups, leading to an increase in the number of tapes needed. 4. You will need a filer at your DR site to perform restores there. There was not enough upside to counteract the downsides for us, so we are going to use the SNAPDIFF feature for this application and use NDMP for a couple of big applications that were using image backups. NDMP ended up being over twice as fast for these. Sam Sheppard San Diego Data Processing Corp. (858)-581-9668 -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Schaub, Steve Sent: Wednesday, June 23, 2010 8:40 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] NAS vs traditional fileservers We currently use traditional windows fileservers, but are being presented with an opportunity to start using a NAS device. I've been reading up on NDMP, doesn't sound to me like NAS is the backup admin's friend. Can anyone who has gone down this road share any of the biggest pros/cons/gotchas? I seem to recall from several years ago that getting the backup data offsite was an issue, but the NAS vendor claims this is no longer true. Currently using half a dozen fileservers to manage about 20TB of user data. Thanks, Steve Schaub Systems Engineer, Windows BlueCross BlueShield of Tennessee - Please see the following link for the BlueCross BlueShield of Tennessee E-mail disclaimer: http://www.bcbst.com/email_disclaimer.shtm - The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message.
Re: Changing management class wihtout retransferring all data
Potential exceptions to this (unlikely as they may be): - If the old management class has MODE=MODIFIED and the new management class has MODE=ABSOLUTE, that will drive backups of all the files. - If the old management class has a relatively high FREQUENCY setting compared to the new management class, that could drive unexpected backups of files. Best regards, Andy Andy Raibeck IBM Software Group Tivoli Storage Manager Client Product Development Level 3 Team Lead Internal Notes e-mail: Andrew Raibeck/Hartford/i...@ibmus Internet e-mail: stor...@us.ibm.com IBM Tivoli Storage Manager support web page: http://www.ibm.com/support/entry/portal/Overview/Software/Tivoli/Tivoli_Storage_Manager The only dumb question is the one that goes unasked. The command line is your friend. Good enough is the enemy of excellence. ADSM: Dist Stor Manager ADSM-L@vm.marist.edu wrote on 2010-06-23 09:56:11: From: Prather, Wanda wprat...@icfi.com To: ADSM-L@vm.marist.edu Date: 2010-06-23 10:09 Subject: Re: Changing management class wihtout retransferring all data Sent by: ADSM: Dist Stor Manager ADSM-L@vm.marist.edu If you change the management class (for example by adding an INCLUDE statement to bind a file to a different management class), the next time you run a backup you will see files rebound n in the statistics. TSM will just change the management class for the files it finds (files that still exist on the hard drive). It will not resend the data. There is not a way to change the management class for inactive files that no longer exist on the hard drive. -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Alexander Födisch Sent: Wednesday, June 23, 2010 9:49 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Changing management class wihtout retransferring all data Hi, is there a possibility to change the management class without transfering the data again to TSM server? We have to change the management class of approx. 50TB of data (12 millions files) and we don't want to backup all the data again. Thanks. Alex
Re: newbie question
LOL! I think Photoshop was easier. But if anyone is worried, I'm attending Tivoli training starting next week. (wish I could attend Photoshop training!) On 6/22/2010 2:36 PM, Joe Crnjanski wrote: Welcome to the world of TSM. Now you know how I feel trying to learn Photoshop CS5 (as a hobby) !!! Joe Crnjanski Infinity Network Solutions Inc. Phone: 416-235-0931 x226 Fax: 416-235-0265 Web:www.infinitynetwork.com -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Dana Holland Sent: Tuesday, June 22, 2010 11:13 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: newbie question Okay, great - thanks for the info (to everyone). On 6/22/2010 10:04 AM, Prather, Wanda wrote: Yes, you just download the versions of the client that are suitable for RHEL4. Version 5 clients work fine with Version 6 server. -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Dana Holland Sent: Tuesday, June 22, 2010 11:01 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] newbie question Yes, that's the page I've been looking at. However, bootinfo -K returns 64. And prtconf returns the following - so I think I'm okay after all. Not sure why I thought this was a 32-bit machine (except that I have 4 other AIX machines, and 25 RedHat Linux machines and have been doing system upgrades on all of them at the same time). But that brings me to another question - I was looking at the client requirements. For RedHat Linux, it looks like TSM 6 is going to required RedHat 5. I have several production servers at RHEL 4/4.5 - the software application isn't certified for RHEL 5. Is that going to work? r...@tivoli /#prtconf System Model: IBM,7038-6M2 Machine Serial Number: 10B9D3C Processor Type: PowerPC_POWER4 Processor Implementation Mode: POWER 4 Processor Version: PV_4_2 Number Of Processors: 2 Processor Clock Speed: 1200 MHz CPU Type: 64-bit Kernel Type: 64-bit LPAR Info: 1 NULL Memory Size: 16384 MB Good Memory Size: 16384 MB Platform Firmware level: 3K050405 Firmware Version: IBM,RG050405_d79e05_r Console Login: enable Auto Restart: true Full Core: false On 6/22/2010 8:43 AM, BEYERS Kurt wrote: Dana, You find all the server requirements at http://www-01.ibm.com/software/tivoli/products/storage-mgr/platforms.htm l?S_CMP=rnav The memory constraint of a 32bit OS will be a possible bottleneck of course for the DB2 server. Regards, Kurt -Oorspronkelijk bericht- Van: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] Namens Prather, Wanda Verzonden: dinsdag 22 juni 2010 15:31 Aan: ADSM-L@VM.MARIST.EDU Onderwerp: Re: [ADSM-L] newbie question What platform is your server? Windows? -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Dana Holland Sent: Tuesday, June 22, 2010 9:22 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] newbie question While I'm still waiting for IBM to correct my support contract so that I can talk to them about this (ahem...) - will Tivoli 6 run on a 32-bit system? When we purchased the software, I could have sworn that the server I have was sufficient. But all the documentation that I've found lately just mentions 64-bit systems. I'm getting a little nervous since there's no way we're going to get the funds for a new server. *** Disclaimer *** Vlaamse Radio- en Televisieomroeporganisatie Auguste Reyerslaan 52, 1043 Brussel nv van publiek recht BTW BE 0244.142.664 RPR Brussel http://www.vrt.be/disclaimer __ Information from ESET NOD32 Antivirus, version of virus signature database 5218 (20100622) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 5218 (20100622) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 5219 (20100622) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
Re: NAS vs traditional fileservers
If you want to embarass a filer head with a bunch of SATA behind it (or the company that made it), give the filer head access to some fast tape drives and issue an NDMP backup. The filer will likely get very very busy. (People using the share will likely suffer slowness.) The good part about NDMP is that you can effectively offload the work to the data mover. The bad part is that once the files from many filerservers have been migrated to NAS, NDMP will sit and eat tapes like candy. Generating offsite copies use the data mover as well, and this can be a sizable CPU hit for the filer as well. If you teach the end users how to restore from snaps/checkpoints, you can make that part of it self-service, and hopefully get fewer restore requests as a result. As usual, YMMV. [RC] From: Richard Rhodes rrho...@firstenergycorp.com To: ADSM-L@VM.MARIST.EDU Date: 06/23/2010 11:11 AM Subject: Re: [ADSM-L] NAS vs traditional fileservers Sent by: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU The NAS vendor is recommending that the NAS box both dedup and compress the files on it. This sounds good for space, but I'm thinking that this will cause NDMP backup to take even longer. I'm think if I do a NDMP full of +20tb of data and that data is all compressed, it's the same as uncompressing all that data to send it to TSM. ALso, the dedup would need to be un-deduped before sending it. Any thoughts on this? Rick Sheppard, Sam sshepp...@sddpc. ORG To Sent by: ADSM: ADSM-L@VM.MARIST.EDU Dist Stor cc Manager ads...@vm.marist Subject .EDU Re: NAS vs traditional fileservers 06/23/2010 01:04 PM Please respond to ADSM: Dist Stor Manager ads...@vm.marist .EDU We're in the middle of doing something similar. We have 17TB of windows file/print data being backed up by 5 servers, total of 33M files. Several of the volumes are almost 2TB with several million files and all of the problems associated with that. So the windows guy is moving all of this to CIFS and we'll (hopefully) end up with several smaller volumes. We did some testing using TSM 6.1.3.4 and NDMP full/diff to TS1120 tape. Backup times for 2 of the 3 test volumes was not that great, around 18MB/sec. The third volume backed up in half the time. According to the Netapp guy, some kind of contention/hotspot on the filer. This is backing up filer-server, not filer-tape. And filer-server allows you to do all of the traditional housekeeping tasks on the storage pools. Looked like it would be doable, until we added up all of the problems: 1. As mentioned elsewhere, the differentials, though just a fraction of the fulls estimate their size as the same as the fulls, so disk pools for the differentials were out, meaning all of the dozens of differentials every night would need a tape drive. A big scheduling headache, but not a show-stopper. 2. We tested TOC to get individual file restore capability. Performance was terrible; over an hour to restore one 50MB file. Only good news here is that increasing the size and number of files restored did not have an equivalent increase in restore time and the proposal was to keep enough snapshots to restore back two weeks. So the individual restore would be a last resort. 3. It appeared the tape compression on NDMP data was not nearly as good as on normal backups, leading to an increase in the number of tapes needed. 4. You will need a filer at your DR site to perform restores there. There was not enough upside to counteract the downsides for us, so we are going to use the SNAPDIFF feature for this application and use NDMP for a couple of big applications that were using image backups. NDMP ended up being over twice as fast for these. Sam Sheppard San Diego Data Processing Corp. (858)-581-9668 -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Schaub, Steve Sent: Wednesday, June 23, 2010 8:40 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] NAS vs traditional fileservers We currently use traditional windows fileservers, but are being presented with an opportunity to start using a NAS device. I've been reading up on NDMP, doesn't sound to me like NAS is the backup admin's friend. Can anyone who has gone down this road share any of the biggest pros/cons/gotchas? I seem to recall from several years ago that getting the backup data offsite was an issue, but the NAS vendor claims this is no longer true. Currently using half a dozen fileservers to manage about 20TB of user data. Thanks, Steve Schaub Systems Engineer, Windows BlueCross BlueShield of Tennessee
Large fileserver on VMware design questions
Hi gang One of my customers is implementing a consolidated fileserver. This will run in a two way MSCS Cluster. At the moment they are looking at one big filesystem though I will strenuously attempt to dissuade them from that course. Each machine in the cluster is a VM based on a different VMware physical server, running windows 2008 r2 64 bit. TSM client will run on the VMs. My proposed strategy is: - Daily incremental. With journalling. Standard cluster setup with one scheduler for each machine and one for the cluster resource. Journal database resides on the cluster disk. - Weekly VCB image of the cluster disk(s) to enable fast restore after disk failure. - Monthly incremental. Since journalling can't be used on more than one node-name, the monthly incremental will take days and is run by a separate scheduler in the cluster as follows:- -- VSS snapshot of the cluster disk is mounted -- backup is taken -- snapshot is deleted. -- NB VSS snaphots are machine-specific so a failover kills this Questions - Most changing documents are word/excel/powerpoint. Is subfile backup a good fit here on the daily client? What about overhead? - How does one handle the possibility of failover when taking the VCB image? The volume may be mounted on the other VM - can anybody help with scripts for the monthly VSS snapshot backup? Other than the one large filesystem issue is there any obvious flaw in my strategy? TSM Server is 5.5, I will install the 6.2.1 client but this server won't be upgraded for a while. Thanks for your input Steve. Steven Harris TSM Admin Paraparaumu NZ
Re: Large fileserver on VMware design questions
On 24 jun 2010, at 02:25, Steve Harris wrote: Hi gang One of my customers is implementing a consolidated fileserver. This will run in a two way MSCS Cluster. At the moment they are looking at one big filesystem though I will strenuously attempt to dissuade them from that course. Each machine in the cluster is a VM based on a different VMware physical server, running windows 2008 r2 64 bit. TSM client will run on the VMs. If they're going to use VMWare, why use a windows cluster. Can't they achieve the same with VMWare? My proposed strategy is: - Daily incremental. With journalling. Standard cluster setup with one scheduler for each machine and one for the cluster resource. Journal database resides on the cluster disk. Makes sense. But, I'm now assuming that the individual machines disks are fairly static, so why bother with the TSM incremental backups, and not live by weekly VCB backups alone for those? If you run in a cluster, there are some tweaks to the journal service to just trust the journal DB, rather than purge it in case of a fail-over. - Weekly VCB image of the cluster disk(s) to enable fast restore after disk failure. can do. - Monthly incremental. Since journalling can't be used on more than one node-name, the monthly incremental will take days and is run by a separate scheduler in the cluster as follows:- -- VSS snapshot of the cluster disk is mounted -- backup is taken -- snapshot is deleted. -- NB VSS snaphots are machine-specific so a failover kills this why? Use journaling for the cluster disks, with a dedicated hostname for the cluster. It might be a good idea to run a normal incremental once in a while, esp. if you don't do a normal incremental after a cluster failover. Questions - Most changing documents are word/excel/powerpoint. Is subfile backup a good fit here on the daily client? What about overhead? subfile incremetals are very useful for clients with 28k8 modem connections. I wouldn't bother in a normal data center environment with plenty of bandwidth. - How does one handle the possibility of failover when taking the VCB image? The volume may be mounted on the other VM - can anybody help with scripts for the monthly VSS snapshot backup? Other than the one large filesystem issue is there any obvious flaw in my strategy? Yes, TSM client 6.2 is not supported with the 5.5 server ;-) TSM Server is 5.5, I will install the 6.2.1 client but this server won't be upgraded for a while. Thanks for your input Steve. Steven Harris TSM Admin Paraparaumu NZ -- Met vriendelijke groeten/Kind regards, Remco Post
