Re: windows cluster issues client level 5.2.3
We don't used all-local at all in ours. Insteady we just put DOMAIN C: or DOMAIN C: D: depending on how many local (non cluster) disks you have. The only time we've ever had the local backup incorrectly backup the cluster disks was when we forgot and left "ALL-LOCAL" in the dsm.opt for the local backup. K Tim Brown <[EMAIL PROTECTED]> wrote: Have Windows 2003 Server cluster with 2 nodes PServer1 PServer2, Cluster is call PCLUSTER The TSM clients on PServer1 and PServer2 backup their respective c: drives and system information. The TSM Cluster service for noe PCLUSTER backs up drives q: d: Occassionally one of these two TSM Nodes will backup the cluster which I dont want to happen The DSM.OPT on these 2 servers has this coded Domain ALL-LOCAL -d: -q: Tim Brown Systems Specialist Central Hudson Gas & Electric 284 South Ave Poughkeepsie, NY 12601 Email: [EMAIL PROTECTED] Phone: 845-486-5643 Fax: 845-486-5921 __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Cristie BRM
As part of our testing (and feel free to use their 30-day evaluation for this, we did) we restored a Windows 2003 server originally on a 4-way Xeon with a raid array for the disk drives to a standard desktop single-cpu and IDE drive. It took a couple of passes to work out the required device drivers, but the total time spent was less than the time required to load (from original CD) Windows 2003 server on the same desktop system. Tom Kauffman NIBCO, Inc -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of TSM User Sent: Thursday, February 16, 2006 1:06 PM To: ADSM-L@VM.MARIST.EDU Subject: Cristie BRM Somebody used Cristie BMR, to recover a W2000 with different CPU? It worked correctly? Thank you 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: Fulls vs. incrementals for TSM DB
>> On Thu, 16 Feb 2006 12:08:27 -0500, Richard Sims <[EMAIL PROTECTED]> said: > Allen - The elevated number of tapes would be the biggest issue... I think I'd be using the same amount. Or rather: If I were writing to separate tape volumes every time, I'd be using the same amount. The comparison would be: DayFullsIncrementals 0 New tape for fullNew tape for full 1 New tape for fullNew tape for incr 2 New tape for fullNew tape for incr 3 New tape for fullNew tape for full However, I'm not doing it that way: I'm backing up all of my TSM DBs to remote server volumes, and guarding against media failure by copying them all over hell's half-acre. I'd win big, because my week's DB backup retention would go from 7xfull backup to (on the average) 3xfull, 6xincrementals. I'd probably cut my total DB backup storage by more than 50%. > But db incrementals do work well, so there's no functionality problem. Yeah, I don't think the use of the incrementals would be fragile, but I figured it needed a line-item, if only so it could be dismissed in style. Thanks, Richard! - Allen S. Rout
Cristie BRM
Somebody used Cristie BMR, to recover a W2000 with different CPU? It worked correctly? Thank you
Re: Information
On Feb 16, 2006, at 1:59 PM, LeBlanc, Patricia wrote: Can anyone tell me where I can find client/server compatibility information such as : If I'm running an old NT platform server with version 5.1..what version does my server have to be? And conversely, if I upgrade to server version 5.2, will it support an NT client running client version 5.1?? thanks Patricia - The first chapter in the client manuals has that info, and client/server requirements are online at the TSM Support page, http://www-306.ibm.com/software/sysmgmt/products/support/ IBMTivoliStorageManager.html The rule of thumb is "one release backward and forward" compatibility, supported, with lots of compatibility outside that range, unsupported. Richard Sims
Information
Can anyone tell me where I can find client/server compatibility information such as : If I'm running an old NT platform server with version 5.1..what version does my server have to be? And conversely, if I upgrade to server version 5.2, will it support an NT client running client version 5.1?? thanks
noch kleine Probleme
Hallo, leider hat uns der Anschluss der Tape-Library etwas in Verzug gebracht. Die TSM-Software läuft zwar prinzipiell auf dem neuen Server, aber die Plattenbereiche für die Sicherungsdaten müssen noch formatiert werden. Es kann nicht garantiert werden, dass die Sicherungen heute nacht laufen. Aus zeitlichen Gründen müssen wir auch das Update auf Version 5.3 verschieben. Wir bitten um Ihr Verständnis. -- Viele Gruesse, Dirk Kastens Universitaet Osnabrueck, Rechenzentrum (Computer Center) Albrechtstr. 28, 49069 Osnabrueck, Germany Tel.: +49-541-969-2347, FAX: -2470
Re: Fulls vs. incrementals for TSM DB
Allen - The elevated number of tapes would be the biggest issue... That poses more of a burden on your scratch supply. There's also more jeopardy for recovery if one of the incrementals is missing at recovery time. In human terms, it's also more confusing at recovery time to deal with more than one tape. Whereas db backups are principal participants in DR procedures, there's more tape juggling in the going out and coming back. But db incrementals do work well, so there's no functionality problem. Richard Sims
Fulls vs. incrementals for TSM DB
I'm soliciting comments about my thinking re: possibly doing incrementals of the TSM DB instead of some of the daily fulls I'm doing now. I'm braced for tomatoes, so fire away. :) My big DB2 backup customers are going through the exercise of measuring "How frequently do we really need to do fulls?". I'm hoping to convince them that daily fulls _plus_ some, in addition to retaining all the logs, can be scaled back some. But this made me think. I've never done that same exercise with my own DB backups; the TSM db. My infrastructure has more than 200G of TSM database running at the moment, split up into 12 servers. Currently, I start my TSM DB backups at a little after 0400, and have to struggle to get all the various copies and migrations complete by the time the backup window opens in the evening. Now, I'm making an unreasonable number of copies at the moment: one onsite copy and -THREE- offsite copies, two of which are electronically vaulted. While the percentage savings would be the same for any of us, my absolute savings are starting to feel compelling. My first response to scaling back was a shudder, but I'm trying to see it logically. If I trust the substrate, and do (say) an incremental DB backup 2 out of 3 days, or some similar such... How much exposure am I _really_ adding? If I go from daily fulls to every-Nth-day fulls, and run incrementals in between: + I add some amount (how much?) to DB restoration in the event of a disaster. Knee-jerk estimation is that the succesive incremental application isn't going to be huge in relation to the full. Perhaps linear with size? + I increase by some amount my exposure to media failure. This seems negligible. If I've got a reasonable number of extra copies of my DB backups, the chance of media failure is acceptably tiny. + I add exposure to several new code paths in the TSM server codebase. A bug in incremental application would mean I'd have to revert to the full, possibly increasing my lost-data period. That's probably negligible. I couldn't come up with any more negatives. Oh, + My TSM administrator will have the willies about it for a while. Accepting those risks, I win: + Dramatically smaller use of backup landing pad and offsite generation resources. + Dramatically smaller use of primary tape. + More wall-clock time to do e.g. expiration and such. Anybody see something I'm missing? - Allen S. Rout
Problem with samba share inc over linux
Hi everyone, I've migrated 300GB of fileshare from windows NT to SAMBA Version 3.0.9-1.3E.3. on Linux RH3AS 2.4.21-32.EL #1 SMP ia64 when I run an inclemental all the object under samba share looks [changed] from the log. I solve with "Copy Serialization.: Dynamic". The really problem is that at the second inc ALL the file under samba share are backuped again, and this appened every time a do an INC. -incrbydateI try whit -incrbydate but this is no good solution some file with old date putted on the share are not backupped. I want to runINC without "-incrbydate" like before in windows !! Someone have some IDEa or suggest?? I use IBM Tivoli Storage Manager Command Line Backup/Archive Client Interface - Version 5, Release 2, Level 4.0 build date: Fri Mar 18 10:51:27 2005 IBM Tivoli Storage Manager Server Version 5, Release 2, Level 2.2 MgmtClass Name : MC_UNIX Description : Space Management Technique : None Auto Migrate on Non-Usage : 0 Backup Required Before Migration: NO Destination for Migrated Files : SPACEMNGT Copy Group Copy Group Name: STANDARD Copy Type..: Backup Copy Frequency.: 0 day(s) Versions Data Exists...: 5 version(s) Versions Data Deleted..: 1 version(s) Retain Extra Versions..: 30 day(s) Retain Only Version: 60 day(s) Copy Serialization.: Dynamic Copy Mode..: Modified Copy Destination...: STG_UNIX Davide Fanizzo Banca Akros Network and Security admin == DISCLAIMER: This e-mail is for the sole use of the intended recipient and any file transmitted with it may contain material that is confidential and privileged. If you are not the intended recipient of this e-mail, please do not read this e-mail and delete this message and any file attached from your system and then notify us immediately by reply e-mail or by telephone. You should not copy or use this message and any file attached for any purpose, disclose the contents of the same to any other person or forward them without express permission by us. Considering the means of transmission, we do not undertake any liability with respect to the secrecy and confidentiality of the information contained in this e-mail and in its attachments. Il presente messaggio di posta elettronica h ad esclusivo utilizzo del destinatario indicato in indirizzo e gli eventuali documenti allegati potrebbero avere carattere riservato. Qualora non foste il destinatario del presente messaggio Vi preghiamo non leggerlo, di cancellarlo dal Vostro sistema assieme ad ogni documento ad esso allegato e di volerci avvertire immediatamente tramite posta elettronica o telefonicamente. E' vietata la duplicazione o l'utilizzo per qualunque fine del presente messaggio e di ogni documento ad esso allegato cosl come la relativa divulgazione, distribuzione o inoltro a terzi senza l'espressa autorizzazione del mittente. Il mittente, in ragione del mezzo di trasmissione utilizzato, non assume alcuna responsabilit` in merito alla segretezza e riservatezza delle informazioni contenute nel presente messaggio e nei relativi allegati. ==
Re: windows cluster issues client level 5.2.3
I've had this happen in a Windows 2000 cluster and TSM clients 5.1.7.1. and TSM server 5.3.2.1 on AIX It happens fairly consistently after moving a cluster group (containing disks and TSM scheduler for the cluster group) from one node to another. The solution for me has been to restart the TSM Scheduler service on the cluster node (which only backs up the local disks) AFTER moving a cluster group. It seems that the scheduler for local node/disks somehow picks up the disks belonging to the cluster group when the failover occurs. Restarting the scheduler resets it back to just the local disks. In my case, it's just another step to perform when doing cluster maintenance/management. Can be a bit of a pain, though when the node starts backing up hundreds of gigs of data unnecessarily. Tim Brown wrote: Have Windows 2003 Server cluster with 2 nodes PServer1 PServer2, Cluster is call PCLUSTER The TSM clients on PServer1 and PServer2 backup their respective c: drives and system information. The TSM Cluster service for noe PCLUSTER backs up drives q: d: Occassionally one of these two TSM Nodes will backup the cluster which I dont want to happen The DSM.OPT on these 2 servers has this coded Domain ALL-LOCAL -d: -q: Tim Brown Systems Specialist Central Hudson Gas & Electric 284 South Ave Poughkeepsie, NY 12601 Email: [EMAIL PROTECTED] Phone: 845-486-5643 Fax: 845-486-5921 -- Graham Stewart Network and Storage Services Manager, Information Technology Services University of Toronto Library 130 St. George Street Toronto, Ontario[EMAIL PROTECTED] Canada M5S 1A5Phone: 416-978-6337 | Fax: 416-978-1668
windows cluster issues client level 5.2.3
Have Windows 2003 Server cluster with 2 nodes PServer1 PServer2, Cluster is call PCLUSTER The TSM clients on PServer1 and PServer2 backup their respective c: drives and system information. The TSM Cluster service for noe PCLUSTER backs up drives q: d: Occassionally one of these two TSM Nodes will backup the cluster which I dont want to happen The DSM.OPT on these 2 servers has this coded Domain ALL-LOCAL -d: -q: Tim Brown Systems Specialist Central Hudson Gas & Electric 284 South Ave Poughkeepsie, NY 12601 Email: [EMAIL PROTECTED] Phone: 845-486-5643 Fax: 845-486-5921
Re: Offsite library via fiber (Specifically VTL)
Hi Leigh! We also choose a VTL solution (EMC's DL700) over a SATA box with a file device class because IBM couldn't come up with a reference site of similar size (180 TB) with a file device class. The only statement we could get from IBM was: "It will most likely work"... By the way, we are very happy with the virtual library concept and so are our customers. Kindest regards, Eric van Loon -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Leigh Reed Sent: woensdag 15 februari 2006 11:32 To: ADSM-L@VM.MARIST.EDU Subject: Re: Offsite library via fiber (Specifically VTL) Wanda I would be intrigued to know your thoughts on why you went specifically with a VTL with TSM and not a more generic 'low cost' disk arrangement with sequential files. It is a decision that I am trying to come to terms with myself and have not yet settled in my mind which I prefer. Apart from price, if you take into consideration ease of management/configuration and performance, what decision making processes did those 2 variables lead you through. Did you go with IBM TS7510 or EMC CDL or a n other ? I guess the last $64M question is, are you happy with the decision you made ? Many thanks Leigh -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Prather, Wanda Sent: 13 February 2006 19:31 To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Offsite library via fiber We're doing just that. Easy to set up if your offsite location is within fibre distance. Only we are putting the VTL (primary pool) OFFSITE and the 3584 (copy pool) ONSITE. Why? 1) Tapes jam. Drives break. The 3584 is very reliable, but still mechanical. Easier to have it onsite, near us, to manage. The VTL is essentially lights out, so it will live offsite. 2) IF we have a disaster, having the VTL offsite means we can do DR restores without being limited by the number of tape drives we have. Cool idea, huh? Means we only need 2 drives in our 3584. Collocation & tape mounts are no longer an issue. And another cool thing: 3) We're even putting a spare Windows server offsite with the VTL, and making it a backup domain controller. TSM is already installed on it, but inactive. If we have a disaster, all we have to do is restore the TSM DB. We can start restoring files then to any machine we can get IP connectivity to. Our domain is still up, we don't have to recover AD. I can hardly wait for the tornado! Wanda Prather "I/O, I/O, It's all about I/O" -(me) -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of David E Ehresman Sent: Friday, February 10, 2006 3:54 PM To: ADSM-L@VM.MARIST.EDU Subject: Offsite library via fiber We're thinking of a TSM upgrade that would include a VTL onsite library and an IBM 3584 library for copy pool tape. We would locate the 3584 in our offsite storage location and access it via fiber. The tapes would remain in the 3584 since they would already be offsite. Anyone have any experience with a setup like this? Daivd Ehresman University of Louisville ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. **
Re: 5.3.2.2 volume question
This sounds like APAR IC47950. If so, then until a fix is available, you can just update the volumes in question to scratch status via 'upd libv'. Regards, Bill Bill Kelly Auburn University OIT 334-844-9917 >>> [EMAIL PROTECTED] 02/16/06 7:52 AM >>> I recently upgraded to 5.3.2.2 server level, about 2 1/2 weeks ago. I have 2 tsm servers, tsm1 and tsm2, each share a 3589 library with 5 frames 60 drives. tsm1 is the library manager. We have been noticing lately that when we run a report to show private, scratches, dbb vols, we have a column of private tapes that increases everyday that are really supposed to be scratch tapes. What I have found is, when reclamation runs on tsm2 for primary tape pools, it marks the tape as deleted and ready for scratch like it should, but on tsm1, it still shows the tape as private, if you "q vol" on either tsm server, they know nothing about the tape, but again "q libvol" shows the tape as private like below: TSMLIB1 T01779 PrivateTSMCORP1 1,054 LTO I can check the tape out and recheck it in as scratch and it will be used as scratch from there out. I went back and checked our reports, and before the upgrade, we had 3-5 tapes in the status, now we have 140, If I look at the daily reports each day, it grows each day from the day we did the upgrade. So, has anybody else seen this with 5.3.2.2 or any other ideas on what might be causing this. This email and any files transmitted with it are confidential and intended solely for the use of the addressee. If you are not the intended addressee, then you have received this email in error and any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. Please notify us immediately of your unintended receipt by reply and then delete this email and your reply. Tyson Foods, Inc. and its subsidiaries and affiliates will not be held liable to any person resulting from the unintended or unauthorized use of any information contained in this email or as a result of any additions or deletions of information originally contained in this email.
Re: Archive large number of subdirs -> syntax
On Feb 16, 2006, at 8:50 AM, Bos, Karel wrote: For some reason, the dsmc archive command doesn't like the \...\ part. No reason it should - it's not a legal form for command line file specifications. See "Using wildcard characters" in the client manual. Richard Sims
Re: 5.3.2.2 volume question
Sorrythat was a typo on previous message, we have a 3584, not a 3589. > _ > From: Park, Rod > Sent: Thursday, February 16, 2006 7:53 AM > To: 'ADSM-L@VM.MARIST.EDU' > Subject: 5.3.2.2 volume question > > I recently upgraded to 5.3.2.2 server level, about 2 1/2 weeks ago. I > have 2 tsm servers, tsm1 and tsm2, each share a 3589 library with 5 > frames 60 drives. tsm1 is the library manager. We have been noticing > lately that when we run a report to show private, scratches, dbb vols, > we have a column of private tapes that increases everyday that are > really supposed to be scratch tapes. What I have found is, when > reclamation runs on tsm2 for primary tape pools, it marks the tape as > deleted and ready for scratch like it should, but on tsm1, it still > shows the tape as private, if you "q vol" on either tsm server, they > know nothing about the tape, but again "q libvol" shows the tape as > private like below: > > TSMLIB1 T01779 PrivateTSMCORP1 > 1,054 LTO > > I can check the tape out and recheck it in as scratch and it will be > used as scratch from there out. I went back and checked our reports, > and before the upgrade, we had 3-5 tapes in the status, now we have > 140, If I look at the daily reports each day, it grows each day from > the day we did the upgrade. So, has anybody else seen this with > 5.3.2.2 or any other ideas on what might be causing this. This email and any files transmitted with it are confidential and intended solely for the use of the addressee. If you are not the intended addressee, then you have received this email in error and any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. Please notify us immediately of your unintended receipt by reply and then delete this email and your reply. Tyson Foods, Inc. and its subsidiaries and affiliates will not be held liable to any person resulting from the unintended or unauthorized use of any information contained in this email or as a result of any additions or deletions of information originally contained in this email.
5.3.2.2 volume question
I recently upgraded to 5.3.2.2 server level, about 2 1/2 weeks ago. I have 2 tsm servers, tsm1 and tsm2, each share a 3589 library with 5 frames 60 drives. tsm1 is the library manager. We have been noticing lately that when we run a report to show private, scratches, dbb vols, we have a column of private tapes that increases everyday that are really supposed to be scratch tapes. What I have found is, when reclamation runs on tsm2 for primary tape pools, it marks the tape as deleted and ready for scratch like it should, but on tsm1, it still shows the tape as private, if you "q vol" on either tsm server, they know nothing about the tape, but again "q libvol" shows the tape as private like below: TSMLIB1 T01779 PrivateTSMCORP1 1,054 LTO I can check the tape out and recheck it in as scratch and it will be used as scratch from there out. I went back and checked our reports, and before the upgrade, we had 3-5 tapes in the status, now we have 140, If I look at the daily reports each day, it grows each day from the day we did the upgrade. So, has anybody else seen this with 5.3.2.2 or any other ideas on what might be causing this. This email and any files transmitted with it are confidential and intended solely for the use of the addressee. If you are not the intended addressee, then you have received this email in error and any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. Please notify us immediately of your unintended receipt by reply and then delete this email and your reply. Tyson Foods, Inc. and its subsidiaries and affiliates will not be held liable to any person resulting from the unintended or unauthorized use of any information contained in this email or as a result of any additions or deletions of information originally contained in this email.
Archive large number of subdirs -> syntax
Hi, During a desktop upgrade action all local data from users is moved to a folder in their home dir (Migrated Data). Now, management want to archive with delete this data. The command I want to use is Dsmc archive \\servername\x$\users1\...\Migrated Data\* -Description="XX" -delete files -optfile=X For some reason, the dsmc archive command doesn't like the \...\ part. Any ideas? Regards, Karel Dit bericht is vertrouwelijk en kan geheime informatie bevatten enkel bestemd voor de geadresseerde. Indien dit bericht niet voor u is bestemd, verzoeken wij u dit onmiddellijk aan ons te melden en het bericht te vernietigen. Aangezien de integriteit van het bericht niet veilig gesteld is middels verzending via internet, kan Atos Origin niet aansprakelijk worden gehouden voor de inhoud daarvan. Hoewel wij ons inspannen een virusvrij netwerk te hanteren, geven wij geen enkele garantie dat dit bericht virusvrij is, noch aanvaarden wij enige aansprakelijkheid voor de mogelijke aanwezigheid van een virus in dit bericht. Op al onze rechtsverhoudingen, aanbiedingen en overeenkomsten waaronder Atos Origin goederen en/of diensten levert zijn met uitsluiting van alle andere voorwaarden de Leveringsvoorwaarden van Atos Origin van toepassing. Deze worden u op aanvraag direct kosteloos toegezonden. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. On all offers and agreements under which Atos Origin supplies goods and/or services of whatever nature, the Terms of Delivery from Atos Origin exclusively apply. The Terms of Delivery shall be promptly submitted to you on your request.
Re: ASR woes
Dont commercialize this list pls! It wont solve Pauls ASR problems to use other products. Instead, maybe you should try to put some effort in helping him... Slipstreamed installation media with ASR recovery works fine, even if you have different boot controllers. That worked with ASR before CBMR invented disimilar hardware restore... To Pauls problem, sry, I have no clue, it been to long since I tested that feature. //Henrik -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Christian Svensson Sent: den 16 februari 2006 14:02 To: ADSM-L@VM.MARIST.EDU Subject: SV: ASR woes Hi Paul, Have you try ASR and Citrix? Now you got problems... But there is BMR software that is made for more advance environment that IBM recommends. Talk to your local IBM rep for more information. Thanks Christian -Ursprungligt meddelande- Från: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] För Paul van Dongen Skickat: den 16 februari 2006 13:45 Till: ADSM-L@VM.MARIST.EDU Ämne: ASR woes Hello TSMers, or more precisely, the intersection between the TSMers and WINDOWSers I spent the last 24 hours struggling with the ASR bare metal recovery process with W2K3 and TSM. Got some good things, and some strange things which I would like to share/comment, and also seek for some answers. Here's the story: First of all, I used TSM client 5.3.2.2 to backup all disks on the servers, including System State/System Services. Open Files backup also working fine. First machine to be recovered was a test machine with one disk split in two partitions (C: and T:). Restore went file, and ASR recreated my two partitions and restored C:. The T: partition was left empty, but this is a minor problem. After this degree of success, we went for the restoration of a MS Cluster node running SQL Server, on a brand-new IBM xSeries 366. Here begins the real story Problem #1: This machine uses SAS disks and matching RAID controller, for which I had to provide the drivers. When I pressed F6 during text-mode setup, it prompted for the driver, an went on, but then it wouldn't accept the ASR diskette anymore. I finally solved it by integrating the RAID controller driver into the W2K3 CD. Problem #2: The network cards present on the machine (6 in total) are not recognized by the standard Windows setup. After a call to MS's support, I got the answer that "only local restores are supported". After many hours and iteractions of "burn CD-RW (15 min)/boot the server (20 min)" I could get Windows to accept a set of network drivers integrated as OEM drivers pointed by the "Unattended Install" mode. I had some dark thoughts because the ASR process uses its own kind of response file, and soon enough I was feced with the effects of this. After the device detection, Windows setup would simply freeze. After some 10 minutes, I gave up I went to reboot the machine. By chance I pressed Enter and... oops!! Setup resumed Not too good to document, I think. "If setup freezes, get a cup of coffee an try pressing Enter several times" After that, Windows finally came back, but it started complaining on every boot that the cluster service could not be started because the quorum disk could not be accessed (Quite right, since the other node has it). But after 60 sec, cluster service restarts and the node joins the cluster normally. That is problem #3. The last problem# is by far the silliest The (standard) MS Sql server install placed in the registry the SHORT file names (intended for 16-bit programs that must use the old 8.3 naming convention). So, the directory named "Microsoft SQL Server" had a short name of MICROS~1 before the ASR process, and MICROS~2 after (because there was a "Microsoft MOM" directory which was restored earlier ad got MICROS~1). Obviously SQL Server wouldn't start, and I had to rename both directories to get it to work. I am currently trying (after some sleep) to solve these so I can get a decent automated process. If someone gets any light on these questions please let me know. Thanks to all, Paul van Dongen --- 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.
SV: ASR woes
Hi Paul, Have you try ASR and Citrix? Now you got problems... But there is BMR software that is made for more advance environment that IBM recommends. Talk to your local IBM rep for more information. Thanks Christian -Ursprungligt meddelande- Från: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] För Paul van Dongen Skickat: den 16 februari 2006 13:45 Till: ADSM-L@VM.MARIST.EDU Ämne: ASR woes Hello TSMers, or more precisely, the intersection between the TSMers and WINDOWSers I spent the last 24 hours struggling with the ASR bare metal recovery process with W2K3 and TSM. Got some good things, and some strange things which I would like to share/comment, and also seek for some answers. Here's the story: First of all, I used TSM client 5.3.2.2 to backup all disks on the servers, including System State/System Services. Open Files backup also working fine. First machine to be recovered was a test machine with one disk split in two partitions (C: and T:). Restore went file, and ASR recreated my two partitions and restored C:. The T: partition was left empty, but this is a minor problem. After this degree of success, we went for the restoration of a MS Cluster node running SQL Server, on a brand-new IBM xSeries 366. Here begins the real story Problem #1: This machine uses SAS disks and matching RAID controller, for which I had to provide the drivers. When I pressed F6 during text-mode setup, it prompted for the driver, an went on, but then it wouldn't accept the ASR diskette anymore. I finally solved it by integrating the RAID controller driver into the W2K3 CD. Problem #2: The network cards present on the machine (6 in total) are not recognized by the standard Windows setup. After a call to MS's support, I got the answer that "only local restores are supported". After many hours and iteractions of "burn CD-RW (15 min)/boot the server (20 min)" I could get Windows to accept a set of network drivers integrated as OEM drivers pointed by the "Unattended Install" mode. I had some dark thoughts because the ASR process uses its own kind of response file, and soon enough I was feced with the effects of this. After the device detection, Windows setup would simply freeze. After some 10 minutes, I gave up I went to reboot the machine. By chance I pressed Enter and... oops!! Setup resumed Not too good to document, I think. "If setup freezes, get a cup of coffee an try pressing Enter several times" After that, Windows finally came back, but it started complaining on every boot that the cluster service could not be started because the quorum disk could not be accessed (Quite right, since the other node has it). But after 60 sec, cluster service restarts and the node joins the cluster normally. That is problem #3. The last problem# is by far the silliest The (standard) MS Sql server install placed in the registry the SHORT file names (intended for 16-bit programs that must use the old 8.3 naming convention). So, the directory named "Microsoft SQL Server" had a short name of MICROS~1 before the ASR process, and MICROS~2 after (because there was a "Microsoft MOM" directory which was restored earlier ad got MICROS~1). Obviously SQL Server wouldn't start, and I had to rename both directories to get it to work. I am currently trying (after some sleep) to solve these so I can get a decent automated process. If someone gets any light on these questions please let me know. Thanks to all, Paul van Dongen
ASR woes
Hello TSMers, or more precisely, the intersection between the TSMers and WINDOWSers I spent the last 24 hours struggling with the ASR bare metal recovery process with W2K3 and TSM. Got some good things, and some strange things which I would like to share/comment, and also seek for some answers. Here's the story: First of all, I used TSM client 5.3.2.2 to backup all disks on the servers, including System State/System Services. Open Files backup also working fine. First machine to be recovered was a test machine with one disk split in two partitions (C: and T:). Restore went file, and ASR recreated my two partitions and restored C:. The T: partition was left empty, but this is a minor problem. After this degree of success, we went for the restoration of a MS Cluster node running SQL Server, on a brand-new IBM xSeries 366. Here begins the real story Problem #1: This machine uses SAS disks and matching RAID controller, for which I had to provide the drivers. When I pressed F6 during text-mode setup, it prompted for the driver, an went on, but then it wouldn't accept the ASR diskette anymore. I finally solved it by integrating the RAID controller driver into the W2K3 CD. Problem #2: The network cards present on the machine (6 in total) are not recognized by the standard Windows setup. After a call to MS's support, I got the answer that "only local restores are supported". After many hours and iteractions of "burn CD-RW (15 min)/boot the server (20 min)" I could get Windows to accept a set of network drivers integrated as OEM drivers pointed by the "Unattended Install" mode. I had some dark thoughts because the ASR process uses its own kind of response file, and soon enough I was feced with the effects of this. After the device detection, Windows setup would simply freeze. After some 10 minutes, I gave up I went to reboot the machine. By chance I pressed Enter and... oops!! Setup resumed Not too good to document, I think. "If setup freezes, get a cup of coffee an try pressing Enter several times" After that, Windows finally came back, but it started complaining on every boot that the cluster service could not be started because the quorum disk could not be accessed (Quite right, since the other node has it). But after 60 sec, cluster service restarts and the node joins the cluster normally. That is problem #3. The last problem# is by far the silliest The (standard) MS Sql server install placed in the registry the SHORT file names (intended for 16-bit programs that must use the old 8.3 naming convention). So, the directory named "Microsoft SQL Server" had a short name of MICROS~1 before the ASR process, and MICROS~2 after (because there was a "Microsoft MOM" directory which was restored earlier ad got MICROS~1). Obviously SQL Server wouldn't start, and I had to rename both directories to get it to work. I am currently trying (after some sleep) to solve these so I can get a decent automated process. If someone gets any light on these questions please let me know. Thanks to all, Paul van Dongen
