Re: Do you perform Windows SYSTEMSTATE backups?
I am very sorry, but I am a little bit confused by discussion about SYSTEMSTATE backup. We are backing up SYSTEMSTATE for Windows 2003 (all editions) and Windows 2008 (all editions) with the latest patches and VSS hot fixes without any problems (TSM Client 6.2.4.0 and TSM Server 5.5.6). We have restored successfully a few servers after real Windows disaster. In addition, we are testing Windows image restores periodically. As a small problem I can declare only huge number of files in Windows 2008 SYSTEMSTATE. It delays incremental backups checking all files without backing up them (finally must of the files are re-assigned with message like ANS4085I Assigned '82817' objects from previous systemstate backup to the new systemstate backup.) Grigori G. Solonovitch Senior Technical Architect Ahli United Bank Kuwait www.ahliunited.com.kw Please consider the environment before printing this E-mail -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Roger Deschner Sent: 26 07 2012 8:54 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Do you perform Windows SYSTEMSTATE backups? We do not back up the Windows System State, and I run a program to find them, delete them, and change the cloptset for offending nodes to one that forbids it. The problem started with Vista, and it hit us real hard. It's a problem that keeps on giving, as people gradually upgrade from XP to Win7 and from Server 2003 to Server 2008. A pet peeve of mine in this regard is that XP calls it System Object, and TSM very inflexibly enforces this semantic detail. If you assign a Vista+ node to a cloptset that contains DOMAIN -SYSTEMOBJECT you get a fatal error and no backup. If you assign an XP node to a cloptset that contains DOMAIN -SYSTEMSTATE you also get a fatal error. TSM should accept SYSTEMSTATE and SYSTEMOBJECT as aliases for one another. This would save me a ***___HUGE___*** amount of time and effort. The difference in whether or not you can handle it, is the TSM server version, as well as the client version. In general, neither V5 servers nor V5 clients can handle System State backup, while V6.2.3+ servers can deal with it reasonably well if the client is also V6.2.3+. This is IBM's recommendation. We have never found the System Object/State backup to be useful for a desktop node restore. OTOH if the node is a server, we have started to back up the System State to our new V6.2.3 server using V6.2.4+ clients. We continue to absolutely forbid System State backups on our old V5.5 servers. They simply cannot handle it. Roger Deschner University of Illinois at Chicago rog...@uic.edu My business, is to teach my aspirations to conform themselves to fact, not to try and make facts harmonize with my aspirations. -- Thomas Huxley, 1860 On Wed, 25 Jul 2012, Zoltan Forray wrote: We are constantly seeing problems with Windows VSS and systemstate backups. The recent black Tuesday updates has causes numerous Windows servers to start having backup problem where they previously worked just fine. In most cases they require the VSS hotfixes/fixpacks, etc. The quickest fix is to simply stop systemstate backups since VSS patches usually require reboots. I bought up the issue of have we ever restored the systemstate or any objects within and the response was No, Never. So I am wondering, how many folks here who backup Windows servers, include SYSTEMSTATE backups and why? -- *Zoltan Forray* TSM Software Hardware Administrator Virginia Commonwealth University UCC/Office of Technology Services zfor...@vcu.edu - 804-828-4807 Don't be a phishing victim - VCU and other reputable organizations will never use email to request that you reply with your password, social security number or confidential personal information. For more details visit http://infosecurity.vcu.edu/phishing.html 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: Do you perform Windows SYSTEMSTATE backups?
Roger, We do not backup desktop clients, but we do have working system state backups from servers (2000,2003, 2003R2, 2008, 2008R2) with server version 5.4.3.0 and various clientversions (though we did need to upgrade the clients on the 2008 family of servers to 5.5.3.3 - but then again, we do the DR trainings for a reason). We have not seen the issues you report in backing up our servers. Regards, Rick On Thu, Jul 26, 2012 at 8:54 AM, Grigori Solonovitch grigori.solonovi...@ahliunited.com wrote: I am very sorry, but I am a little bit confused by discussion about SYSTEMSTATE backup. We are backing up SYSTEMSTATE for Windows 2003 (all editions) and Windows 2008 (all editions) with the latest patches and VSS hot fixes without any problems (TSM Client 6.2.4.0 and TSM Server 5.5.6). We have restored successfully a few servers after real Windows disaster. In addition, we are testing Windows image restores periodically. As a small problem I can declare only huge number of files in Windows 2008 SYSTEMSTATE. It delays incremental backups checking all files without backing up them (finally must of the files are re-assigned with message like ANS4085I Assigned '82817' objects from previous systemstate backup to the new systemstate backup.) Grigori G. Solonovitch Senior Technical Architect Ahli United Bank Kuwait www.ahliunited.com.kw Please consider the environment before printing this E-mail -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Roger Deschner Sent: 26 07 2012 8:54 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Do you perform Windows SYSTEMSTATE backups? We do not back up the Windows System State, and I run a program to find them, delete them, and change the cloptset for offending nodes to one that forbids it. The problem started with Vista, and it hit us real hard. It's a problem that keeps on giving, as people gradually upgrade from XP to Win7 and from Server 2003 to Server 2008. A pet peeve of mine in this regard is that XP calls it System Object, and TSM very inflexibly enforces this semantic detail. If you assign a Vista+ node to a cloptset that contains DOMAIN -SYSTEMOBJECT you get a fatal error and no backup. If you assign an XP node to a cloptset that contains DOMAIN -SYSTEMSTATE you also get a fatal error. TSM should accept SYSTEMSTATE and SYSTEMOBJECT as aliases for one another. This would save me a ***___HUGE___*** amount of time and effort. The difference in whether or not you can handle it, is the TSM server version, as well as the client version. In general, neither V5 servers nor V5 clients can handle System State backup, while V6.2.3+ servers can deal with it reasonably well if the client is also V6.2.3+. This is IBM's recommendation. We have never found the System Object/State backup to be useful for a desktop node restore. OTOH if the node is a server, we have started to back up the System State to our new V6.2.3 server using V6.2.4+ clients. We continue to absolutely forbid System State backups on our old V5.5 servers. They simply cannot handle it. Roger Deschner University of Illinois at Chicago rog...@uic.edu My business, is to teach my aspirations to conform themselves to fact, not to try and make facts harmonize with my aspirations. -- Thomas Huxley, 1860 On Wed, 25 Jul 2012, Zoltan Forray wrote: We are constantly seeing problems with Windows VSS and systemstate backups. The recent black Tuesday updates has causes numerous Windows servers to start having backup problem where they previously worked just fine. In most cases they require the VSS hotfixes/fixpacks, etc. The quickest fix is to simply stop systemstate backups since VSS patches usually require reboots. I bought up the issue of have we ever restored the systemstate or any objects within and the response was No, Never. So I am wondering, how many folks here who backup Windows servers, include SYSTEMSTATE backups and why? -- *Zoltan Forray* TSM Software Hardware Administrator Virginia Commonwealth University UCC/Office of Technology Services zfor...@vcu.edu - 804-828-4807 Don't be a phishing victim - VCU and other reputable organizations will never use email to request that you reply with your password, social security number or confidential personal information. For more details visit http://infosecurity.vcu.edu/phishing.html 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
backup tape stgpool to tape stgpool pins recovery log
Hi John, The undocumented 'SHow LOGPIn' command works well: ** TSMsh logpi Dirty page Lsn=24594790.225.3369, Last DB backup Lsn=24594791.3.3978, Transaction table Lsn=24593189.104.932, Running DB backup Lsn=0.0.0, Log truncation Lsn=24593189.104.932 Lsn=24593189.104.932, Owner=DB, Length=64 Type=Update, Flags=C2, Action=SetRange, Page=21311247, Tsn=0:3.3964001625, PrevLsn=0.0.0, UndoNextLsn=0.0.0, UpdtLsn=24593188.36.1603 === Start=31967, Count=64 (1592112) Generating SM Context Report: (1592112) *** no sessions found *** (132) Generating SM Context Report: (132) *** no sessions found *** (1592111) Generating SM Context Report: (1592111) Session 689954:Type=Node, Id=NEREID.CIT.NIH.GOV (1592111) Platform=SUN SOLARIS, NodeId=609, Owner= (1592111) SessType=4, Index=15, TermReason=0 (1592111) RecvWaitTime=0.000 (samples=0) (1592111) Backup Objects ( bytes ) Inserted: 108 ( 0.12900381 ) (1592111) Backup Objects ( bytes ) Restored: 0 ( 0.0 ) (1592111) Archive Objects ( bytes ) Inserted: 0 ( 0.0 ) (1592111) Archive Objects ( bytes ) Retrieved: 0 ( 0.0 ) (1592111) Last Verb ( ConfirmResp ), Last Verb State ( Sent ) Session 689954 is assoicated with this transaction. ** There's some useful information in this output (nodename, session) thought most of it is for internal use. It is also one of the few places where you can find the NodeId (in line below the ) equated to the nodename -- handy for a couple of other undocumented commands where you get the nodeID but not nodename. Armed with this info you may be able to 'tune' your schedules to ease the apparent conflict. It may be helpful to issue this command every 'xx' minutes and pipe the output to a file...the only thing the output is missing is a timestamp. Susie -- Date:Wed, 25 Jul 2012 21:58:57 -0400 From:Dury, John C. jd...@duqlight.com Subject: backup tape stgpool to tape stgpool pins recovery log I have 2 sl500 tape libraries attached via dark fiber (which doesn't appear= to be getting anywhere close to the speeds it should but that's another is= sue) to an AIX TSM 5.5 server. One is copy storage pool and the other a pr= imary. I backup the primary to the copy storage pool daily. This process is= taking an extremely long time and seems to hang because there is at least = one extremely large file that while it is copying, pins the recovery log an= d does not finish before the recovery log is over 80% which then causes TSM= to slow to a crawl so I end up cancelling the backup storage pool process.= This is hanging my TSM server on a daily basis because the recovery keeps= getting pinned by the backup storage process. Is there any way at all I can find out what node or node and filespace, is = taking so long to backup so I can verify it really needs to be backed up at= all? --
Re: TSM V6.3 with IBM TS3200 I/O stations issue
Dear all : We were trying to use the TS-3200 I/O station to handle checkin and checkout of tape. After we change the TS3200 library to enable I/O station; then reboot the tape library and restart the TSM server. We still cannot checkout any tape to the I/O station. Anyone has idea how to trace where is the problems or anything I had missed. Best regards, Victor Shum
Re: TSM V6.3 with IBM TS3200 I/O stations issue
Hello What are you trying and what errors/messages are you getting? On Jul 26, 2012 1:06 PM, Victor Shum victors...@cadex.com.hk wrote: Dear all : We were trying to use the TS-3200 I/O station to handle checkin and checkout of tape. After we change the TS3200 library to enable I/O station; then reboot the tape library and restart the TSM server. We still cannot checkout any tape to the I/O station. Anyone has idea how to trace where is the problems or anything I had missed. Best regards, Victor Shum
Re: SQL Server 2012 support
Bill, I'm not fully up to speed on SharePoint backups, but what I do recall from the SP2007 era, is that you need to do a backup using the stsadm.exe tool to create a full backup of the farm, which includes the databases, but also several other stuff - so backing up only the databases won't cut it). Backing up SharePoint SQL databases with TDP *and* stsadm.exe will create havoc with transactionlog backups (no, the restores to be fully correct) as the LSNs of the transactionlogs won't match up. Can't find any information on SQL Server 2012, latest I find is 6.3.x versions, but that would only support up to 2008R2 with SPs. But I guess that's just what you found as well Cheers Rick On Jul 26, 2012 4:21 PM, Bill Boyer bjdbo...@comcast.net wrote: Is there a version of the TDP SQL Server that supports MS SQL Server 2012? I have some users putting up a Sharepoint 2010 Farm using SQL 2012 for the database. And while I'm on the subject, does the latest TDP Sharepoint/DocAve support SQL 2012 in the Farm? It's a SharePoint 2010 Farm. Bill Boyer DSS, Inc. (610) 927-4407 Enjoy life. It has an expiration date. - ??
SQL Server 2012 support
Is there a version of the TDP SQL Server that supports MS SQL Server 2012? I have some users putting up a Sharepoint 2010 Farm using SQL 2012 for the database. And while I'm on the subject, does the latest TDP Sharepoint/DocAve support SQL 2012 in the Farm? It's a SharePoint 2010 Farm. Bill Boyer DSS, Inc. (610) 927-4407 Enjoy life. It has an expiration date. - ??
Re: SQL Server 2012 support
Microsoft SQL Server 2012 toleration level support is planned for availability in the 4Q12 6.3.1 Fix Pack. Thanks, Del Bill, I'm not fully up to speed on SharePoint backups, but what I do recall from the SP2007 era, is that you need to do a backup using the stsadm.exe tool to create a full backup of the farm, which includes the databases, but also several other stuff - so backing up only the databases won't cut it). Backing up SharePoint SQL databases with TDP *and* stsadm.exe will create havoc with transactionlog backups (no, the restores to be fully correct) as the LSNs of the transactionlogs won't match up. Can't find any information on SQL Server 2012, latest I find is 6.3.x versions, but that would only support up to 2008R2 with SPs. But I guess that's just what you found as well Cheers Rick Is there a version of the TDP SQL Server that supports MS SQL Server 2012? I have some users putting up a Sharepoint 2010 Farm using SQL 2012 for the database. And while I'm on the subject, does the latest TDP Sharepoint/DocAve support SQL 2012 in the Farm? It's a SharePoint 2010 Farm.
Re: Do you perform Windows SYSTEMSTATE backups?
There is a known problem with TSM 5.5 servers backing up Win2K8 systemstate from 6.2.0+ clients. (5.5 servers with 5.5 clients don't have the problem; V6 servers with 5.5 clients don't have the problem. ) Starting at 6.2.0, the backup client tries by default to do a true incremental of systemstate, which means it has to keep track of which pieces of the system state get changed and link them together in case you do a systemstate restore. The resulting pointers are complex enough that it pretty much gets the 5.5 server tangled in its underwear, and a simple systemstate backup can bring the server to its knees if it's heavily used. (First symptom we saw, was that the Win2K8 clients that had been upgraded from 5.5 to 6.2 would take hours to back up systemstate if the server was busy doing backup stgpool or something else that required heavy use of the DB.) Two solutions: a) move the client to a V6 server, poof the problem goes away b) there is a new option (not in the manual) called systemstatebackupmethod; if you set SYSTEMSTATEBACKUPMETHOD FULL, the systemstate backup is done like it used to be in the 5.5 client (not as a true incremental) and you won't have the problem, you'll just have the huge Win2K8 systemstate backup as usual. Here's the info: http://www-01.ibm.com/support/docview.wss?uid=swg21470662myns=swgtivmynp=OCSSGSG7mync=E http://www-01.ibm.com/support/docview.wss?uid=swg1IC80331 w -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Rick Harderwijk Sent: Thursday, July 26, 2012 3:24 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Do you perform Windows SYSTEMSTATE backups? Roger, We do not backup desktop clients, but we do have working system state backups from servers (2000,2003, 2003R2, 2008, 2008R2) with server version 5.4.3.0 and various clientversions (though we did need to upgrade the clients on the 2008 family of servers to 5.5.3.3 - but then again, we do the DR trainings for a reason). We have not seen the issues you report in backing up our servers. Regards, Rick On Thu, Jul 26, 2012 at 8:54 AM, Grigori Solonovitch grigori.solonovi...@ahliunited.com wrote: I am very sorry, but I am a little bit confused by discussion about SYSTEMSTATE backup. We are backing up SYSTEMSTATE for Windows 2003 (all editions) and Windows 2008 (all editions) with the latest patches and VSS hot fixes without any problems (TSM Client 6.2.4.0 and TSM Server 5.5.6). We have restored successfully a few servers after real Windows disaster. In addition, we are testing Windows image restores periodically. As a small problem I can declare only huge number of files in Windows 2008 SYSTEMSTATE. It delays incremental backups checking all files without backing up them (finally must of the files are re-assigned with message like ANS4085I Assigned '82817' objects from previous systemstate backup to the new systemstate backup.) Grigori G. Solonovitch Senior Technical Architect Ahli United Bank Kuwait www.ahliunited.com.kw Please consider the environment before printing this E-mail -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Roger Deschner Sent: 26 07 2012 8:54 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Do you perform Windows SYSTEMSTATE backups? We do not back up the Windows System State, and I run a program to find them, delete them, and change the cloptset for offending nodes to one that forbids it. The problem started with Vista, and it hit us real hard. It's a problem that keeps on giving, as people gradually upgrade from XP to Win7 and from Server 2003 to Server 2008. A pet peeve of mine in this regard is that XP calls it System Object, and TSM very inflexibly enforces this semantic detail. If you assign a Vista+ node to a cloptset that contains DOMAIN -SYSTEMOBJECT you get a fatal error and no backup. If you assign an XP node to a cloptset that contains DOMAIN -SYSTEMSTATE you also get a fatal error. TSM should accept SYSTEMSTATE and SYSTEMOBJECT as aliases for one another. This would save me a ***___HUGE___*** amount of time and effort. The difference in whether or not you can handle it, is the TSM server version, as well as the client version. In general, neither V5 servers nor V5 clients can handle System State backup, while V6.2.3+ servers can deal with it reasonably well if the client is also V6.2.3+. This is IBM's recommendation. We have never found the System Object/State backup to be useful for a desktop node restore. OTOH if the node is a server, we have started to back up the System State to our new V6.2.3 server using V6.2.4+ clients. We continue to absolutely forbid System State backups on our old V5.5 servers. They simply cannot handle it. Roger Deschner University of Illinois at Chicago rog...@uic.edu My business, is to teach my aspirations to conform
AUTO: Tobias Kuebler ist außer Haus (Rückkehr am Mo, 07/30/2012)
Ich bin von Fr, 07/27/2012 bis Mo, 07/30/2012 abwesend. Vielen Dank für Ihre Nachricht. Ankommende E-Mails werden während meiner Abwesenheit nicht weitergeleitet, ich versuche Sie jedoch möglichst rasch nach meiner Rückkehr zu beantworten. Hinweis: Dies ist eine automatische Antwort auf Ihre Nachricht Re: [ADSM-L] Do you perform Windows SYSTEMSTATE backups? gesendet am 27.07.2012 04:13:59. Diese ist die einzige Benachrichtigung, die Sie empfangen werden, während diese Person abwesend ist.
