As I was reading this, I immediatley thought, hoho, if he can get the
admins to properly classify their data. Then you wrote:
On another front, am I too optimistic to think that local client
administrators will appropriately classify their data? Your experiences
on this front too will be helpful - particularly those universities out
there who have little control over your clients.
This has been a constant thorn in my side. Trying to get people to think
about restore requirements. Despite many meetings, explanations,
arguments etc.. it pretty much without fail ends up coming back as 'back
it all up, and keep it all for the same anount of time.' I have very
rarely been succesfull in getting any kind of division of 'importance'
of data beyond 'os' 'app' and 'data'.
So , I would say YES.
Matt.
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Steve Harris
Sent: Sunday, September 12, 2004 11:57 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Second level collocation
Hi All,
I'm contemplating the detailed design of the 30-odd major sites that I
will be installing.
These range from hundreds of nodes down to tens of nodes in size. The
biggest will run on AIX or Solaris servers, but most will be on Windows.
(As an aside I'd prefer Linux, but it costs three or more times what
windows does in support costs). I'd like as standardized a design as
possible to keep the complexity down.
I've defined 5 "recovery levels" RL1 through RL5, and there will be five
domains available. A server with any data classified at recovery level 1
will reside in domain RL1 and have access to mgmtclasses RL1 to RL5.
A server not in RL1 with any data classified at recovery level 2 will
reside in domain RL2 and have access to mgmtclasses RL2 to RL5, and so
on. Hopefully, only the critical portions of the data on any given
client will be classified at the higher levels, and the rest will back
up to lower levels.
Recovery level 1 implies a full server recovery (from a TSM point of
view) for a single server in 8 hours or less. This will require
filespace level collocation. RL2 is 24 hours and requires node level
collocation. RL3 is 48 hours. RL4 is 72 hours and RL5 is > 1 week.
The idea is that the individual system admins can classify their own
data. RL1 is for very critical production, 2 for Critical production, 3
for normal production, 4 for test/dev and non-critical production and 5
for retired nodes.
Now the question is how to organize the collocation. I'd prefer from a
wear and tear point of view not to mount every tape every night (mostly
SDLT), so I was thinking of front-ending the collocated storage pools
with non-collocated pools, so that the collocation happens when the
front-end pool gets to a certain size, or maybe is scheduled over the
weekend.
Now I realize that tape to tape pool movement is single threaded until
5.3 comes out, but other than that limitation, can anyone see any reason
why this would not work ? Will it have the desired effect? Is anyone
doing this?
On another front, am I too optimistic to think that local client
administrators will appropriately classify their data?
Your experiences on this front too will be helpful - particularly those
universities out there who have little control over your clients.
TIA
Steve.
Steve Harris
Systems Admin Consultant
Enterprise Backup Project
Queensland Health, Brisbane Australia
************************************************************************
***********
This email, including any attachments sent with it, is confidential and
for the sole use of the intended recipient(s). This confidentiality is
not waived or lost, if you receive it and you are not the intended
recipient(s), or if it is transmitted/received in error.
Any unauthorised use, alteration, disclosure, distribution or review of
this email is prohibited. It may be subject to a statutory duty of
confidentiality if it relates to health service matters.
If you are not the intended recipient(s), or if you have received this
email in error, you are asked to immediately notify the sender by
telephone or by return email. You should also delete this email and
destroy any hard copies produced.
************************************************************************
***********
___________________________ Disclaimer Notice __________________________
This message and any attachments are confidential and should only be read by
those to whom they are addressed. If you are not the intended recipient, please
contact us, delete the message from your computer and destroy any copies. Any
distribution or copying without our prior permission is prohibited.
Internet communications are not always secure and therefore Powergen Retail
Limited does not accept legal responsibility for this message. The recipient is
responsible for verifying its authenticity before acting on the contents. Any
views or opinions presented are solely those of the author and do not
necessarily represent those of Powergen Retail Limited.
Registered addresses:
Powergen Retail Limited, Westwood Way, Westwood Business Park, Coventry, CV4
8LG.
Registered in England and Wales No: 3407430
Telephone +44 (0) 2476 42 4000
Fax +44 (0) 2476 42 5432
|
