Hi John I create backup sets weekly and have done some successful restores using the command below.
dsmc restore backupset "/dev/rmt/0" -loc=tape Not sure if this helps though as I'm pretty new to all this. Thanks Farren Minns John Naylor <[EMAIL PROTECTED]>@VM.MARIST.EDU> on 10/12/2001 14:38:20 Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: Re: How many concurrent backup sets? Nick, I am with you. Collocation should improve the way you can plan to use backup sets. Collocation at filespace level would certainly speed up restores as you could multi stream without media contention. I have recently been creating backupsets as an alternative to full backups, and I do have an observation which people need to be aware of. Creating backup sets is processor intensive, all those database entries for the active data to find. So make sure you have enough processor power especially if you inted creating more than one backupset concurrently. If you are running TSM single threaded (default) then you may need to look at MPthreading. By the way I have not had any reply to my question about the syntax for restoring a complete backup set to a test box. As you can restore individually selected filespaces I would have thought it was possible, but am prepared to be told it is not, if others have tried to get that sneaky backupset restore syntax to work to do this and failed. This was the gist of my question I have created single filespace backup sets and restored them ok by changing the node name in the dsm.opt file of the test box to the same as the node from which the backup set was generated. But If I try to restore a whole node backupset including all filespaces, I just cannot get it to work and the examples in the manual do not cover this. Is this possible? If anyone has done this I would be grateful for the syntax The syntax below, works for a single filespace restore to a netware client load dsmc rest backupset -repl=n -su=y server1.6446543 server1\data: testbox\data:\ Nick Laflamme <[EMAIL PROTECTED]> on 12/08/2001 11:56:27 AM Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: (bcc: John Naylor/HAV/SSE) Subject: Re: How many concurrent backup sets? At 09:19 AM 12/6/2001 -0500, Joe Cascanette wrote: >Depending on your server setup there will be a fight for tapes. Turning >collocation ON for your onsite pools would greatly increase the time to >create backup sets. I have 4 backup sets running every 2nd day at once (I >have 10 drives which leaves 2 drive available to do restores.) I have also >noticed that you are unable to perform storage pool backups during the >creation of backup sets (it keeps canceling the process). Since you're speaking with the voice of experience, I'm in no position to doubt this, but at first glance, this seems counter-intuitive, or worse. Can anyone wave their hands for a few minutes and explain why collocation retards creating backup sets? :-) >Joe Cascanette >The Cumis Group Limited Nick Laflamme speaking for no one these days.... >PS - each backup set will use its own tape(s), I have a PRM (and others do >as well) to correct this problem. > > > >-----Original Message----- >From: John Naylor [mailto:[EMAIL PROTECTED]] >Sent: Thursday, December 06, 2001 5:36 AM > >After one weekend of selective full backups increased the size of the >database by 20% , I have managed to talk management round to replacing >them with backupsets. >So all I have to do now is fit them into the available window. >So the question is, Has anyone noticed any constraints on the number of >generate backup sets that can be run concurrently, before they start >impacting on each other? >Is availability of tape drives going to be the only real constraint? >Has anyone wriiten backupsets to file devices to overcome drive shortages? >Any problems with this? >Thanks ********************************************************************** The information in this E-Mail is confidential and may be legally privileged. It may not represent the views of Scottish and Southern Energy plc. It is intended solely for the addressees. Access to this E-Mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any unauthorised recipient should advise the sender immediately of the error in transmission. Scottish Hydro-Electric, Southern Electric, SWALEC and S+S are trading names of the Scottish and Southern Energy Group. **********************************************************************