Migrating TSM Server from Windows to Linux
Hi All, What's in your opnion the best way (or easiest) way to migrate a Windows TSM Server to a RHEL platform? I've already got a couple of suggestions from other people and I'm curious wether they are confirmed or not. BTW we are also migrating the TSM Server from 5.2 to 5.4/5.5 at that stage. Met vriendelijke groet, with kind regards, Richard van Denzel.
An invalid path was used on Netware
Hi all, Sometimes the incremental backup of one of our customers Netware clients is aborted. There is a summary in the dsmsched.log of how many files are backed up etc. At exactly the same second an error is logged in dsmerror.log: 12/01/2007 16:20:02 (TSAFS.NLM 6.51.5 291) An invalid path was used. 12/01/2007 16:20:02 (TSAFS.NLM 6.51.5 291) An invalid path was used. I searched the list archive and the rest of the web but couldn't find any useful information. Anyone seen this before? (Client Netware 5.70.5, client version 5.4.1.4, Server on AIX 5.3, server version 5.3.4.1) Alexander
Re: ANR8314E Library is Full Error
Mel, In case it needs to run an AUDIT LIBRARY, would it be with CHELKLABEL=YES or CHECKLABEL=BARCODE? Because, CHECKLABEL=YES may take hours to complete the audit as it mounts and checks the label of each volume... -Rama -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Dennis, Melburn (IT Solutions US) Sent: Thursday, December 06, 2007 4:04 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] ANR8314E Library is Full Error Actually if all that was added was extra slots in the second frame, all that needs to be run is an audit library command. This will force your library to reaudit your current inventory including the new empty slots. If new drives were added as well, just define the new paths and drives to the existing library. No need to delete paths/drives/library for this. I've done it several times when we've upgraded our scalar 10k with new cabinets. Mel Dennis Backup Systems Engineer Siemens IT Solutions and Services, Inc. PGST Data Center Operations 4400 Alafaya Trail MC Q1-108 Orlando, FL 32826 Tel.: 407-736-2360 Mob: 321-356-9366 Fax: 407-243-0260 mailto:[EMAIL PROTECTED] www.usa.siemens.com/it-solutions -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Stapleton, Mark Sent: Thursday, December 06, 2007 2:44 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] ANR8314E Library is Full Error From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Maura Adams Thanks for the info. I just heard back from IBM support and because our second frame to the library was added after our original install, TSM does not see it. We need to take an outage and delete/define all paths, library, drives and check all tapes back in. A little bit ugly. Not ugly at all, and no outage is required if you do this at night, since tape drives are usually quiet during that time anyway. Write a batch file that does the following: delete path (all tape drives) delete path (for library) delete drive (all tape drives) delete library (library) define library define path (for library) define drive (all tape drives) define path (all tape drives) checkin libv (library) search=yes status=scratch checkl=barcode checkin libv (library) search=yes status=private checkl=barcode Call the batch file library_redo. Run the file as a macro. This should all run within a minute or two. Do it while all tape drives are quiet. -- Mark Stapleton Berbee (a CDW company) System engineer 7145 Boone Avenue North, Suite 140 Brooklyn Park MN 55428-1511 763-592-5963 www.berbee.com This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing.
Re: Migrating TSM Server from Windows to Linux
Hi, As discussed many many times earlier, search the list archives for answers. In short, to migrate all your data cross platform you need to do exports/imports. There is no other way. //Henrik -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Richard van Denzel Sent: den 7 december 2007 16:11 To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Migrating TSM Server from Windows to Linux Hi All, What's in your opnion the best way (or easiest) way to migrate a Windows TSM Server to a RHEL platform? I've already got a couple of suggestions from other people and I'm curious wether they are confirmed or not. BTW we are also migrating the TSM Server from 5.2 to 5.4/5.5 at that stage. Met vriendelijke groet, with kind regards, Richard van Denzel. --- The information contained in this message may be CONFIDENTIAL and is intended for the addressee only. Any unauthorised use, dissemination of the information or copying of this message is prohibited. If you are not the addressee, please notify the sender immediately by return e-mail and delete this message. Thank you.
Re: Vista oddness
Ok, I'll give that a try. -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Wanda Prather Sent: Friday, December 07, 2007 2:35 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Vista oddness Don't know myself, but someone else posted a while back that the System State on Vista is many GB. That is consistent with what you are seeing - a scheduled backup will do the System State, whether things have changed or not. And selecting the C: drive will not do the system state. As a test, try your backup from thh GUI again, but this time select System STate as well as the C: drive, see if the results change... And please post back the results! On 12/6/07, Tyree, David [EMAIL PROTECTED] wrote: We are testing Vista and I'm seeing something odd. TSM seems to want to do almost a full backup every time it runs automatically. I'm running the 5.5.0 client on a VMware (6.0) Vista Ultimate box that is talking to a TSM server running 5.4.1 on Windows. The backup on the Vista machine is automated using the DSMCAD service. The incremental backup kicks off at the correct time, but it ends up doing a full backup. I've looked through the dsmsched log on the Vista machine and I'm seeing where it has contacted the TSM server and picked up the schedule name and the action. The schedule name is correct and the action is set to incremental. And several lines in the dsmsched log mention Incremental backup of '\\is-vista-test-d\c$' finished. The log shows everything just like what I would expect to say, the issue is that it ends up backing up almost 8 gigs of files each time the backup runs. I've run scheduled incremental backups almost back to back on the machine and it picks up 8 gigs each time. The machine is just sitting there between backups; I'm not doing anything on the machine in between. If I open the GUI and tag the c drive for incremental backup it goes out and looks at all the files on the drive and backs up a few dozen files and it done. Just like I would expect it to. If I go to the baclient folder and run dsmc incr from the command line it ends up doing what looks like a full backup. In the last couple of hours I had a scheduled backup run that moved about 8 gigs worth of files. Right after that finished I did a c drive backup from the GUI. It moved a few hundred megs of files. Right behind that I did the dsmc incr. So far it's moved over 4 gig of files and is still running. Anybody got a idea what's going on here? PS, Vista looks good. Except most of our software doesn't run. The UAC (User Account Control) is a real piece of work. And they have moved everything around so you can't find what you're looking for. But at least it looks good David Tyree Interface Analyst South Georgia Medical Center 229.333.1155 Confidential Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
AW: AW: NetApp backup takes too long
Netapp (or EMC NAS) devices do not allow to run journaling agents. Regards Stefan Holzwarth -Ursprüngliche Nachricht- Von: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Im Auftrag von Steve Stackwick Gesendet: Donnerstag, 6. Dezember 2007 16:41 An: ADSM-L@VM.MARIST.EDU Betreff: Re: AW: NetApp backup takes too long You could also investigate journaling on the Windows server. If the number of files changing daily is small, journaling could cut down on the noodle through the filesystem delay that you're seeing. Steve On 12/6/07, Stefan Holzwarth [EMAIL PROTECTED] wrote: We had a similiar setup and used 5 backupjobs for each volume at the same time. For every volume of the nas server we split the work logicaly. So batch 1 took all directories starting with a-e, bath 2 all from f to h, We could backup our nas device in about 12 hours with 11mio files. Regards Spex -Ursprüngliche Nachricht- Von: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Im Auftrag von Haberstroh, Debbie (IT) Gesendet: Donnerstag, 6. Dezember 2007 14:55 An: ADSM-L@VM.MARIST.EDU Betreff: NetApp backup takes too long Good morning, I could use some suggestions for improving the backup time for our Network Appliance. Below is the write up that my Sys Admin submitted describing the problem. Thanks for the help. Situation: We have a Network Appliance (NAS) hosting approximately 8 million Windows files (CIFS). Due to disk constraints, we are not able to use snapshots and due to some other customer induced limitations, we cannot use NDMP for backups. We have implemented a proxy/redirection server that backs up the CIFS files via a unc path name to a TSM 5.33 host running AIX. Our issue is in walking through 8 million files per night in a backup job. The nightly backup delta is approximately 40GB. However, just to access and check 8 million files to see if they meet the backup criteria is taking too much time. The CIFS backup is split into 3 separate batch jobs that run simultaneously. The longest job (about 3 million files) takes almost 20 hours to run. Would NIC teaming gain us any time savings during the backup? I feel the bottleneck may be our AIX system since the Windows server has to get the meta data for the CIFS file, check it against the TSM database, and determine if that file needs to be backed up. That is a lot of traffic between Windows host, TSM server, and Network Appliance for every single file. During the backup time, the CPU is at about 70% on the Windows host, and the NIC is rarely higher than 50%. TSM Server Information: We are running TSM 5.3.3 on AIX 5.3. The server is an IBM 7026-6H1, 4 processors and only 2 Gb Ram. The TSM database is almost 200 Gb with 300 clients. Windows Server Information: We are currently using the Windows TSM client version 5.33c under Windows 2003 Server Standard Edition on an HP DL380 dual 2.8 GHz Xeon processor with 2.5 GB of RAM. We have three batch files running the DSMC command line utility scheduled by the Windows scheduler. We have a dual port HP NC7781 NIC card. We are using only one port connected at 1GB. Debbie Haberstroh -- Stephen Stackwick Jacob Sundstrom, Inc. 401 East Pratt St., Suite 2214 Baltimore, MD 21202-3003 (410) 539-1135 * (866) 539-1135 [EMAIL PROTECTED]
Re: Vista oddness
I did a backup using the GUI and selected system state along with the C: drive. The backup was 8 gig when it finished. I went back and did a C: drive only and it was only a few hundred meg. Then I did a system state only and got the 8 gig again. That system state in Vista is just crazy. I need to go back and really look at some of my servers and see just how big the system state backups are. I'll also take a close look at a few Win XP Pro desktops that I'm backing up and see what the numbers look like. -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Wanda Prather Sent: Friday, December 07, 2007 2:35 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Vista oddness Don't know myself, but someone else posted a while back that the System State on Vista is many GB. That is consistent with what you are seeing - a scheduled backup will do the System State, whether things have changed or not. And selecting the C: drive will not do the system state. As a test, try your backup from thh GUI again, but this time select System STate as well as the C: drive, see if the results change... And please post back the results! On 12/6/07, Tyree, David [EMAIL PROTECTED] wrote: We are testing Vista and I'm seeing something odd. TSM seems to want to do almost a full backup every time it runs automatically. I'm running the 5.5.0 client on a VMware (6.0) Vista Ultimate box that is talking to a TSM server running 5.4.1 on Windows. The backup on the Vista machine is automated using the DSMCAD service. The incremental backup kicks off at the correct time, but it ends up doing a full backup. I've looked through the dsmsched log on the Vista machine and I'm seeing where it has contacted the TSM server and picked up the schedule name and the action. The schedule name is correct and the action is set to incremental. And several lines in the dsmsched log mention Incremental backup of '\\is-vista-test-d\c$' finished. The log shows everything just like what I would expect to say, the issue is that it ends up backing up almost 8 gigs of files each time the backup runs. I've run scheduled incremental backups almost back to back on the machine and it picks up 8 gigs each time. The machine is just sitting there between backups; I'm not doing anything on the machine in between. If I open the GUI and tag the c drive for incremental backup it goes out and looks at all the files on the drive and backs up a few dozen files and it done. Just like I would expect it to. If I go to the baclient folder and run dsmc incr from the command line it ends up doing what looks like a full backup. In the last couple of hours I had a scheduled backup run that moved about 8 gigs worth of files. Right after that finished I did a c drive backup from the GUI. It moved a few hundred megs of files. Right behind that I did the dsmc incr. So far it's moved over 4 gig of files and is still running. Anybody got a idea what's going on here? PS, Vista looks good. Except most of our software doesn't run. The UAC (User Account Control) is a real piece of work. And they have moved everything around so you can't find what you're looking for. But at least it looks good David Tyree Interface Analyst South Georgia Medical Center 229.333.1155 Confidential Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
Re: Vista oddness
The XP system state is about 300MB, much like a Win2K system. It's Vista where the weirdness kicks in... On 12/7/07, Tyree, David [EMAIL PROTECTED] wrote: I did a backup using the GUI and selected system state along with the C: drive. The backup was 8 gig when it finished. I went back and did a C: drive only and it was only a few hundred meg. Then I did a system state only and got the 8 gig again. That system state in Vista is just crazy. I need to go back and really look at some of my servers and see just how big the system state backups are. I'll also take a close look at a few Win XP Pro desktops that I'm backing up and see what the numbers look like. -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Wanda Prather Sent: Friday, December 07, 2007 2:35 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Vista oddness Don't know myself, but someone else posted a while back that the System State on Vista is many GB. That is consistent with what you are seeing - a scheduled backup will do the System State, whether things have changed or not. And selecting the C: drive will not do the system state. As a test, try your backup from thh GUI again, but this time select System STate as well as the C: drive, see if the results change... And please post back the results! On 12/6/07, Tyree, David [EMAIL PROTECTED] wrote: We are testing Vista and I'm seeing something odd. TSM seems to want to do almost a full backup every time it runs automatically. I'm running the 5.5.0 client on a VMware (6.0) Vista Ultimate box that is talking to a TSM server running 5.4.1 on Windows. The backup on the Vista machine is automated using the DSMCAD service. The incremental backup kicks off at the correct time, but it ends up doing a full backup. I've looked through the dsmsched log on the Vista machine and I'm seeing where it has contacted the TSM server and picked up the schedule name and the action. The schedule name is correct and the action is set to incremental. And several lines in the dsmsched log mention Incremental backup of '\\is-vista-test-d\c$' finished. The log shows everything just like what I would expect to say, the issue is that it ends up backing up almost 8 gigs of files each time the backup runs. I've run scheduled incremental backups almost back to back on the machine and it picks up 8 gigs each time. The machine is just sitting there between backups; I'm not doing anything on the machine in between. If I open the GUI and tag the c drive for incremental backup it goes out and looks at all the files on the drive and backs up a few dozen files and it done. Just like I would expect it to. If I go to the baclient folder and run dsmc incr from the command line it ends up doing what looks like a full backup. In the last couple of hours I had a scheduled backup run that moved about 8 gigs worth of files. Right after that finished I did a c drive backup from the GUI. It moved a few hundred megs of files. Right behind that I did the dsmc incr. So far it's moved over 4 gig of files and is still running. Anybody got a idea what's going on here? PS, Vista looks good. Except most of our software doesn't run. The UAC (User Account Control) is a real piece of work. And they have moved everything around so you can't find what you're looking for. But at least it looks good David Tyree Interface Analyst South Georgia Medical Center 229.333.1155 Confidential Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
backup duration
Hello, Is there a query I can run to get a total backup time on each node that is assigned to one particular schedule ? This will help me decide who took the longest time to complete its back up and give it its own schedule. Thank you in advance. Avy Wong Business Continuity Administrator Mohegan Sun 1 Mohegan Sun Blvd Uncasville, CT 06382 (860)862-8164 (cell) (860)961-6976
Re: Vista oddness
Hi, Well, no wonder why Microsoft already are deduplicating their Systemstate backups with System Recovery Tool, SRT, an add on to DPM2007. I wont argue how well they do this but at least they try. //Henrik -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Tyree, David Sent: den 7 december 2007 15:47 To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Vista oddness I did a backup using the GUI and selected system state along with the C: drive. The backup was 8 gig when it finished. I went back and did a C: drive only and it was only a few hundred meg. Then I did a system state only and got the 8 gig again. That system state in Vista is just crazy. I need to go back and really look at some of my servers and see just how big the system state backups are. I'll also take a close look at a few Win XP Pro desktops that I'm backing up and see what the numbers look like. -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Wanda Prather Sent: Friday, December 07, 2007 2:35 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Vista oddness Don't know myself, but someone else posted a while back that the System State on Vista is many GB. That is consistent with what you are seeing - a scheduled backup will do the System State, whether things have changed or not. And selecting the C: drive will not do the system state. As a test, try your backup from thh GUI again, but this time select System STate as well as the C: drive, see if the results change... And please post back the results! On 12/6/07, Tyree, David [EMAIL PROTECTED] wrote: We are testing Vista and I'm seeing something odd. TSM seems to want to do almost a full backup every time it runs automatically. I'm running the 5.5.0 client on a VMware (6.0) Vista Ultimate box that is talking to a TSM server running 5.4.1 on Windows. The backup on the Vista machine is automated using the DSMCAD service. The incremental backup kicks off at the correct time, but it ends up doing a full backup. I've looked through the dsmsched log on the Vista machine and I'm seeing where it has contacted the TSM server and picked up the schedule name and the action. The schedule name is correct and the action is set to incremental. And several lines in the dsmsched log mention Incremental backup of '\\is-vista-test-d\c$' finished. The log shows everything just like what I would expect to say, the issue is that it ends up backing up almost 8 gigs of files each time the backup runs. I've run scheduled incremental backups almost back to back on the machine and it picks up 8 gigs each time. The machine is just sitting there between backups; I'm not doing anything on the machine in between. If I open the GUI and tag the c drive for incremental backup it goes out and looks at all the files on the drive and backs up a few dozen files and it done. Just like I would expect it to. If I go to the baclient folder and run dsmc incr from the command line it ends up doing what looks like a full backup. In the last couple of hours I had a scheduled backup run that moved about 8 gigs worth of files. Right after that finished I did a c drive backup from the GUI. It moved a few hundred megs of files. Right behind that I did the dsmc incr. So far it's moved over 4 gig of files and is still running. Anybody got a idea what's going on here? PS, Vista looks good. Except most of our software doesn't run. The UAC (User Account Control) is a real piece of work. And they have moved everything around so you can't find what you're looking for. But at least it looks good David Tyree Interface Analyst South Georgia Medical Center 229.333.1155 Confidential Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. --- The information contained in this message may be CONFIDENTIAL and is intended for the addressee only. Any unauthorised use, dissemination of the information or copying of this message is prohibited. If you are not the addressee, please notify the sender immediately by return e-mail and delete this message. Thank you.
Re: Vista oddness
On Fri, 7 Dec 2007 16:01:45 +0100, Henrik Wahlstedt [EMAIL PROTECTED] said: Well, no wonder why Microsoft already are deduplicating their Systemstate backups with System Recovery Tool, SRT, an add on to DPM2007. I wont argue how well they do this but at least they try. Mmm. Do stupid wasteful things in the published APIs, and unroll them in a proprietary tool. I'll bet a nickel the DPM folks have access to the internal docs. It makes me think of the policy MS had on office apps: the windows APIs they published were known to be hobbled, and the MS applications crew (Office, etc) got access to the undocumented APIs which actually functioned with reasonable efficiency. I wonder what percentage of MS personell are actively engaged in creating chaff and obstacles for the software ecosystem around the OS. Someone is a wizard at PR, to convince all those folks they're not doing negative work. If they weren't, the suicide rate in Redmond would be far worse. - Allen S. Rout
bu solaris 10 tsm 5.4.1.0.2
I must bu a solaris 10 server and I want to exclude some filesystems and files. This is the result of df -k: Filesystemkbytesused avail capacity Mounted on /dev/md/dsk/d0 53516942 8158310 4482346316%/ /devices 0 0 0 0%/devices ctfs 0 0 0 0%/system/contract proc 0 0 0 0%/proc mnttab 0 0 0 0%/etc/mnttab swap 415890401688 41587352 1% /etc/svc/volatile objfs 0 0 0 0%/system/object /platform/sun4u-us3/lib/libc_psr/libc_psr_hwcap2.so.1 53516942 8158310 4482346316% /platform/sun4u-us3/lib /libc_psr.so.1 /platform/sun4u-us3/lib/sparcv9/libc_psr/libc_psr_hwcap2.so.1 53516942 8158310 4482346316% /platform/sun4u-us3/lib /sparcv9/libc_psr.so.1 fd 0 0 0 0%/dev/fd swap 41587432 80 41587352 1%/tmp swap 41634560 47208 41587352 1%/var/run /dev/md/dsk/d3 53516942 38479537 1450223673%/liveupgrade /dev/md/dsk/d79848233812 921922 1% /global/.devices/[EMAIL PROTECTED] /dev/md/dsk/d69848233813 921921 1% /global/.devices/[EMAIL PROTECTED] /dev/md/oracle_software/dsk/d700 41297394 2193376 38691045 6%/global/oracle /dev/md/oracle_bu/dsk/d600 103259614 15546478 8668054016%/oracle_bu /dev/md/oracle_db/dsk/d400 413057122 38198640 37072791110% /global/oracle_db /dev/md/oracle_redo/dsk/d500 156245944 17083320 13760016812% /global/oracle_redo In the dsm.opt file I specified domain all-local ; In the dsm.sys file I specified: exclude.fs /liveupgrade exclude.dir /cdrom exclude.dir /global/oracle_db/oradata exclude.dir /global/oracle_redo/oradata exclude.dir /proc exclude.dir /tmp exclude.dir /var/tmp when I start the TSM-GUI /cdrom, /global/oracle_db/oradata, /global/oracle_redo/oradata, /var/tmp are excluded (so that's good); but /tmp, /liveupgrade are not excluded and the directory proc (under /) is even not visible??? What must I do/change to make all my excludes successful. (I read that when I use all-local, the /tmp directory is not included but this is not visible in the GUI (is this correct?)). If you need more details don't hesitate to ask. Many thanks in advance.
Re: FILE devclass tactics?
On Fri, 7 Dec 2007 14:47:03 -0500, Matthew Glanville [EMAIL PROTECTED] said: But then utilize the true underlying free/full disk space to determine the high/low migration settings instead of the # of volumes. This is much much harder than you might think. For example, the config I was aiming for would have had three 1.7TB filesystems used for a devclass, volumes shared out from a library manager, volumes used by any of 20-some TSM servers. No single TSM server would have a sense of the total space pressure. And of course migrate all volumes for one 'node or filespace' at once to avoid that tape swapping issue. It sounds too easy to do. Oh, I want it, but I don't think it's easy. Not so long as they want to keep the code bases for FILE devclasses essentially similar to the other serial media. - Allen S. Rout
Re: Vista oddness
Joanne, Thanks very much for the detailed response. We really need relief on this. We have a couple of thousand Windows systems, and they will eventually be upgrading to Vista. As they do so, they will uncover this huge problem; A problem for them, in that their backups will run longer and they will be storing much more data than they need; and also a problem for the TSM server administrators as they put an increasingly huge load on the network and TSM server infrastructure. This solution, as it is now, is virtually unworkable for us. The clock is ticking, and we need relieve ASAP. Waiting for the next major release is too long, IMHO. It would have been nice if this were addressed with the initial support for Vista in TSM, but that's water over the dam now. Thanks for listening. ..Paul At 11:40 AM 12/7/2007, Joanne T Nguyen wrote: David, You are seeing the correct behavior. If you have the default domain backup, system state will be part of the backup. On Vista, system state is in GB because we're backing up the windows\winsxs and system32\driverstore folder. Please see the link below where MS describes in-box writers. System state consists of all the bootable system state and system services writers. Though 8GB seems high. Our testing shows about 5GB. http://msdn2.microsoft.com/en-us/library/aa819131.aspx For Windows 2003, TSM implements a way to back up the system files component of the system state only if something is changed. So it is possible to backup only about 30-40 files the 2nd time and thereafter if no fixes or SP were applied after the initial system state backup. During Vista development, we noticed some files were always changed so instead of spending the cycle to compare each file. which are in 30,000-40,000 files now, we decided to backup all the time. This is one area we will revisit. If you have vshadow tool from the MS VSS SDK, you can do vshadow -wm2 to see all the files that should be part of the backup. Please let me know if you have further questions. Regards, Joanne Nguyen TSM Client Development Tyree, David [EMAIL PROTECTED] .ORG To Sent by: ADSM: ADSM-L@VM.MARIST.EDU Dist Stor cc Manager [EMAIL PROTECTED] Subject .EDU Re: Vista oddness 12/07/2007 06:47 AM Please respond to ADSM: Dist Stor Manager [EMAIL PROTECTED] .EDU I did a backup using the GUI and selected system state along with the C: drive. The backup was 8 gig when it finished. I went back and did a C: drive only and it was only a few hundred meg. Then I did a system state only and got the 8 gig again. That system state in Vista is just crazy. I need to go back and really look at some of my servers and see just how big the system state backups are. I'll also take a close look at a few Win XP Pro desktops that I'm backing up and see what the numbers look like. -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Wanda Prather Sent: Friday, December 07, 2007 2:35 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Vista oddness Don't know myself, but someone else posted a while back that the System State on Vista is many GB. That is consistent with what you are seeing - a scheduled backup will do the System State, whether things have changed or not. And selecting the C: drive will not do the system state. As a test, try your backup from thh GUI again, but this time select System STate as well as the C: drive, see if the results change... And please post back the results! On 12/6/07, Tyree, David [EMAIL PROTECTED] wrote: We are testing Vista and I'm seeing something odd. TSM seems to want to do almost a full backup every time it runs automatically. I'm running the 5.5.0 client on a VMware (6.0) Vista Ultimate box that is talking to a TSM server running 5.4.1 on Windows. The backup on the Vista machine is automated using the DSMCAD service. The incremental backup kicks off at the correct time, but it ends up doing a full backup. I've looked through the dsmsched log on the Vista machine and I'm seeing where it has contacted the TSM server and picked up the schedule name and the action. The schedule name is correct and the action is set to incremental. And several lines in the dsmsched log mention Incremental backup of '\\is-vista-test-d\c$' finished. The log shows everything just like what I would expect to say, the issue is that it ends up backing up almost 8 gigs of files each time the backup runs. I've run scheduled incremental backups almost back to back on the machine and it picks up 8
Re: FILE devclass tactics?
I have the exact same complaints about the 'FILE' devclass... If only they would implement a different concept for it's hi/low/migration settings and migrate things better. I wish it would use a volume per 'connection/node/filespace/group' depending on collocation setting, utilizing your 'size' that you specify. But then utilize the true underlying free/full disk space to determine the high/low migration settings instead of the # of volumes. And of course migrate all volumes for one 'node or filespace' at once to avoid that tape swapping issue. It sounds too easy to do. Matt G. ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU wrote on 12/07/2007 12:26:45 PM: Anybody who's using FILE devclasses to accept backups willing to discuss their config, how they got there, and what they like and dislike? I'm working out how to use FILE devclasses effectively, and am a little exasperated. I started off with fairly small maxcap (2G) , and a large maxscratch. My migration was hammered because the migration process switched source volume without particularly considering what other FILE volumes might be emptied onto the tape it had mounted. Reading the docs, this seems to be a core architectural choice, and I can understand how they got there from the serial media way of treating volumes. But it hurts a lot, in this environment. My biggest bottleneck is tape drive hours: Every tape change looks to me like some 11G of data not moved (3min x 60M/min) ; Even if I've got only 500 of my 1100-mumble nodes affected in a day's work, even if it's just one additional mount per node, that's 25 tape-drive-hours eaten up in unneccesary mounts. And all of those estimate numbers are conservative. Ick. Ick ickety ick. At this moment I've made fairly large volumes (50G) sized to be larger than the second standard deviation of a single node's nightly backup, and set node collocation on the FILE devclass, plus a maxscratch significantly larger than the node count. I was anticipating this would leave me with homogenous volumes. D'oh, forgot about resourceutilization. Next I intend to set maxscratch as higher than nodecount*5. So, I'm going to define a stgpool with maxscratch 750, 50G volumes: titularly assigning 37.5 TB of data. Hah. Using this strategy makes a hash of any kind of quota or cap on a given TSM server's use of a shared disk resource. Of course, it's still possible that if I have 4 FILE volumes occupied with only FOONODE data, I'll still do them out of order, and have to mount FOONODE's tape volume four times. In this case, I'm not winning anything by going from nodecount to nodecount*5. It appears, from the docs, that this is what will happen. But I'm going to test and make sure. It seems that this would be a non-issue if the migration process were sensible to the fact that it's extremely low cost to remount FILE volumes. So, what am I doing wrong? Is there a big red button marked Don't Be An Idiot which I'm failing to push? If I can't fix these issues, I will have to ditch the FILE devclass notion; I can't justify spending an additional $20-30K on drives... MMmm. Maybe I should have a _smaller_ disk stgpool migrating into the FILE devclass, Eeek. Double the I/Os in a night? I like to over-engineer, but that's a little much even for me. - Allen S. Rout
Re: Migrating TSM Server from Windows to Linux
There is also no guarantee that you can export/import from 5.2 to 5.5. It ought to work, but there have been issues in the past with export/import across server release levels. The upgrade from Windows 5.2 to 5.4.1 is fast and easy (haven't tried 5.5). I recommend you do the upgrade in place, THEN start your export/imports. It will avoid problems. . On 12/7/07, Richard van Denzel [EMAIL PROTECTED] wrote: Hi All, What's in your opnion the best way (or easiest) way to migrate a Windows TSM Server to a RHEL platform? I've already got a couple of suggestions from other people and I'm curious wether they are confirmed or not. BTW we are also migrating the TSM Server from 5.2 to 5.4/5.5 at that stage. Met vriendelijke groet, with kind regards, Richard van Denzel.
Re: Vista oddness
David, You are seeing the correct behavior. If you have the default domain backup, system state will be part of the backup. On Vista, system state is in GB because we're backing up the windows\winsxs and system32\driverstore folder. Please see the link below where MS describes in-box writers. System state consists of all the bootable system state and system services writers. Though 8GB seems high. Our testing shows about 5GB. http://msdn2.microsoft.com/en-us/library/aa819131.aspx For Windows 2003, TSM implements a way to back up the system files component of the system state only if something is changed. So it is possible to backup only about 30-40 files the 2nd time and thereafter if no fixes or SP were applied after the initial system state backup. During Vista development, we noticed some files were always changed so instead of spending the cycle to compare each file. which are in 30,000-40,000 files now, we decided to backup all the time. This is one area we will revisit. If you have vshadow tool from the MS VSS SDK, you can do vshadow -wm2 to see all the files that should be part of the backup. Please let me know if you have further questions. Regards, Joanne Nguyen TSM Client Development Tyree, David [EMAIL PROTECTED] .ORG To Sent by: ADSM: ADSM-L@VM.MARIST.EDU Dist Stor cc Manager [EMAIL PROTECTED] Subject .EDU Re: Vista oddness 12/07/2007 06:47 AM Please respond to ADSM: Dist Stor Manager [EMAIL PROTECTED] .EDU I did a backup using the GUI and selected system state along with the C: drive. The backup was 8 gig when it finished. I went back and did a C: drive only and it was only a few hundred meg. Then I did a system state only and got the 8 gig again. That system state in Vista is just crazy. I need to go back and really look at some of my servers and see just how big the system state backups are. I'll also take a close look at a few Win XP Pro desktops that I'm backing up and see what the numbers look like. -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Wanda Prather Sent: Friday, December 07, 2007 2:35 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Vista oddness Don't know myself, but someone else posted a while back that the System State on Vista is many GB. That is consistent with what you are seeing - a scheduled backup will do the System State, whether things have changed or not. And selecting the C: drive will not do the system state. As a test, try your backup from thh GUI again, but this time select System STate as well as the C: drive, see if the results change... And please post back the results! On 12/6/07, Tyree, David [EMAIL PROTECTED] wrote: We are testing Vista and I'm seeing something odd. TSM seems to want to do almost a full backup every time it runs automatically. I'm running the 5.5.0 client on a VMware (6.0) Vista Ultimate box that is talking to a TSM server running 5.4.1 on Windows. The backup on the Vista machine is automated using the DSMCAD service. The incremental backup kicks off at the correct time, but it ends up doing a full backup. I've looked through the dsmsched log on the Vista machine and I'm seeing where it has contacted the TSM server and picked up the schedule name and the action. The schedule name is correct and the action is set to incremental. And several lines in the dsmsched log mention Incremental backup of '\\is-vista-test-d\c$' finished. The log shows everything just like what I would expect to say, the issue is that it ends up backing up almost 8 gigs of files each
FILE devclass tactics?
Anybody who's using FILE devclasses to accept backups willing to discuss their config, how they got there, and what they like and dislike? I'm working out how to use FILE devclasses effectively, and am a little exasperated. I started off with fairly small maxcap (2G) , and a large maxscratch. My migration was hammered because the migration process switched source volume without particularly considering what other FILE volumes might be emptied onto the tape it had mounted. Reading the docs, this seems to be a core architectural choice, and I can understand how they got there from the serial media way of treating volumes. But it hurts a lot, in this environment. My biggest bottleneck is tape drive hours: Every tape change looks to me like some 11G of data not moved (3min x 60M/min) ; Even if I've got only 500 of my 1100-mumble nodes affected in a day's work, even if it's just one additional mount per node, that's 25 tape-drive-hours eaten up in unneccesary mounts. And all of those estimate numbers are conservative. Ick. Ick ickety ick. At this moment I've made fairly large volumes (50G) sized to be larger than the second standard deviation of a single node's nightly backup, and set node collocation on the FILE devclass, plus a maxscratch significantly larger than the node count. I was anticipating this would leave me with homogenous volumes. D'oh, forgot about resourceutilization. Next I intend to set maxscratch as higher than nodecount*5. So, I'm going to define a stgpool with maxscratch 750, 50G volumes: titularly assigning 37.5 TB of data. Hah. Using this strategy makes a hash of any kind of quota or cap on a given TSM server's use of a shared disk resource. Of course, it's still possible that if I have 4 FILE volumes occupied with only FOONODE data, I'll still do them out of order, and have to mount FOONODE's tape volume four times. In this case, I'm not winning anything by going from nodecount to nodecount*5. It appears, from the docs, that this is what will happen. But I'm going to test and make sure. It seems that this would be a non-issue if the migration process were sensible to the fact that it's extremely low cost to remount FILE volumes. So, what am I doing wrong? Is there a big red button marked Don't Be An Idiot which I'm failing to push? If I can't fix these issues, I will have to ditch the FILE devclass notion; I can't justify spending an additional $20-30K on drives... MMmm. Maybe I should have a _smaller_ disk stgpool migrating into the FILE devclass, Eeek. Double the I/Os in a night? I like to over-engineer, but that's a little much even for me. - Allen S. Rout
