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 <John.Naylor AT SCOTTISH-SOUTHERN.CO DOT UK>@VM.MARIST.EDU> on
10/12/2001 14:38:20
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
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 <dplaflamme AT ALUMNI.ND DOT EDU> on 12/08/2001 11:56:27 AM
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
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:John.Naylor AT SCOTTISH-SOUTHERN.CO DOT UK]
>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.
**********************************************************************
|
