John,

Ok, I tried to keep things as simple and as general as possible in my
original append.  350 clients and 21 mount points is our total.  I really
should have said that we would need to restore a maximum of 100-200 clients
from either 9 or 12 mount points as described below.

We have 2 data centres with 4 x ADSM servers and 12 x 3590 in one DC, and 3
x ADSM servers and 9 x 3590 in the other DC.  In addition we have 350
*large* clients (HPUX, DEC UNIX, AIX and NT servers) in the two data
centres. Each client backs up to an ADSM server in the opposite data centre.
We have a handful of clients at remote sites which back up to ADSM.  In
total our ADSM servers receive about 1TB of compressed backup and archive
data per night.

Our worse case scenario is that we lose one of our DC.  In this case we lose
ADSM servers in addition to between 100-200 ADSM clients.  We would need to
recover the clients ASAP from the ADSM servers in the opposite DC.  We would
either have 12 or 9 x 3590 depending upon which DC we lost.

To speed things up I thought about setting up extra disk storage pools in
the hierarchy to retain small backup files on disk and use the 3590s for
restoring the larger files.

Richard.



On 15 March 2000 14:33, John Naylor
[SMTP:John.Naylor AT SCOTTISH-SOUTHERN.CO DOT UK] wrote:
> Richard,
> Why would you ever want to recover 350 clients at one time.
> What sort of disaster do you have in mind.
> Normally your clients will be spead over a number of physical sites, so
even if
> you lost a whole site through some natural disaster, then you only need
meet the
> restore time for the that your slowest site would take, and provided that
you
> have no sites with more than 20 clients your 21 mount points (what a
luxury!)
> should be fine.
> Or have I missed something ?
> John
>
>
>
>
> "Bates, Richard" <Richard.Bates AT VERTEX.CO DOT UK> on 13/03/2000 15:26:34
>
> 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:  disk storage for small files
>
>
>
> We are thinking of implementing disk storage pools for "small files" so
that
> restores during a disaster scenario are quicker.  This would involve
adding
> some extra disk stgpools into the hierarchy and tuning the maxsize
> parameter.  Migration of these extra pools would not occur.
>
> We already use collocation, however we are still unable to restore 350
> clients using 21 mount points (3590 drives) within our recovery time
> objectives.
>
> I have spoken to some other ADSM users and they all seem to look at me in
a
> rather strange way when I tell them what we are thinking of doing.  Does
> anyone use disk for permanently storing "small file" primary storage pool
> data?  If so, how low do you set your maxsize parameter.  Apart from the
> cost I can't think of any other disadvantages.  Copy storage pools are
> implemented to protect against disk failure.
>
> Richard.
>
>
> ***********************************************************
> The information contained in this e-mail is intended only
> for the individual to whom it is addressed. It may contain
> privileged and confidential information. If you have
> received this message in error or there are any problems,
> please notify the sender immediately and delete the message
> from your computer. The unauthorised use, disclosure,
> copying or alteration of this message is forbidden. Neither
> Vertex Data Science Limited nor any of its subsidiaries
> will be liable for direct, special, indirect or
> consequential damage as a result of any virus being passed
> on, or arising from alteration of the contents of this
> message by a third party.
>
> Vertex Data Science Limited (England and Wales No. 3153391)
> registered office Vertex House, Greencourts Business Park,
> 333 Styal Road, Manchester, M22 5TX
> ***********************************************************
>
>
>
>
>
>
> **********************************************************************
> 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 and Southern Electric are trading names of
> Scottish and Southern Energy Group
> **********************************************************************