Way too far back. The owner of the server went out of town for a while. The files/directories went missing over 2-weeks ago. No DBb goes back that far.
Either way, the problem is primarily on the client side (except for V6.1 - see my next post) From: "Mueller, Ken" <kmuel...@mcarta.com> To: ADSM-L@VM.MARIST.EDU Date: 12/11/2009 10:20 AM Subject: Re: [ADSM-L] Restoring LARGE server Sent by: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> Have you considered setting up a separate TSM instance specifically to handle this emergency? Use the TSM database backup from just prior to all those files being marked inactive. That way you can leverage NQR to get these big boys. -Ken -----Original Message----- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Zoltan Forray/AC/VCU Sent: Thursday, December 10, 2009 2:10 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: Restoring LARGE server AFAIK, NQR isn't something you can "pick and choose" - if it was, I would. >From the book: When you enter an unrestricted wildcard source file specification on the restore command and do not specify any of the options: inactive, latest, pick, fromdate, todate, or |volinformation, the client uses a no query restore method for restoring files and directories from the server. This method is called no query restore because instead of querying the server for each object to be restored, a single restore request is sent to the server. In this case, the server returns the files and directories to the client without further action by the client. The client merely accepts the data coming from the server and restores it to the destination named on the restore command. What is killing me is having to restore inactive file (the server corruption completely killed a big directory that the OS says is now "empty" so the TSM backup marked everything "inactive"). In my opinion, these restrictions for NQR plus the issue of not having an equivalent of MEMORYEFFICIENT for restores, is a major problem/weakness in TSM. I have spent the past 3+ days (and will be working throughout the weekend) to restore these files. I keep having to drill further and further into each directory structure to guess which directory I can attempt to restore. Every time I click on a directory and attempt a restore, the process runs for 30-minutes transferring 2G or more of meta-data before it eventually fails on "insufficient memory" or I am lucky enough to pick one that restores. Then I have to start all over again, keep track of where I am and what I was able to restore, drill further down, rinse-lather-repeat! Besides the 22M objects, there is 700GB of data to process/wander through. What good is having 50M objects of backups if I can't restore them in a reasonable fashion? From: "Laughlin, Lisa" <lisa.laugh...@oa.mo.gov> To: ADSM-L@VM.MARIST.EDU Date: 12/09/2009 11:15 AM Subject: Re: [ADSM-L] Restoring LARGE server Sent by: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> How about using just the CLI and the no-query restore option? thanks! lisa > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf > Of Ochs, Duane > Sent: Wednesday, December 09, 2009 9:57 AM > To: ADSM-L@VM.MARIST.EDU > Subject: Re: [ADSM-L] Restoring LARGE server > > Zoltan, > Have you attempted a Point in Time restore from command line? That > might help with the number of inactive files you are experiencing. > If that is not an option, you may have to go a couple directories at a > time. > > I have only had experience restoring up to 9M files and the one time I > did it used PIT and worked fine, turned maxmp up to 4. It certainly > took a while. But it did complete. > > What OS are you using on the client ? > > > Duane > > > > > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf > Of Zoltan Forray/AC/VCU > Sent: Wednesday, December 09, 2009 7:51 AM > To: ADSM-L@VM.MARIST.EDU > Subject: Restoring LARGE server > > Trying to restore a LARGE Windows server. Over 40M objects. Client is > 6.1 > > As you can imagine, we have had to use the journal as well as > MEMORYEFFICIENT to perform backups. > > If I read correctly, MEMORYEFFICIENT is ONLY for backups. Obviously > the journal is of no value since the restore is to a new > machine/location. > > The other issue gumming up the works is that the backups have been > failing (drive array problems/corruption) and thus TSM has marked > almost everything > as "inactive". A first, NQR restore (just selected the drive) attempt > only > restored 90GB (of 600G+) before "finishing successfully". But when I > choose to pick inactive as well as active, the NQR is disabled. > > The server transfers down 1GB of metadata before the client chokes on > "insufficient memory". > > So, how am I supposed to restore this many objects, besides picking one > directory at a time, which is not to say that some directories are > large enough to also cause a "not enough memory" situation? > > Suggestions on how to handle this?
