.....(clip) so I was thinking of front-ending the collocated storage pools with non-collocated pools,...
Isn't that called a diskpool??!? ;>) Seriously, if you are worried about wear and tear, the easiest (and probably cheapest) way to solve that problem is just to put a big enough pool of inexpensive/ATA disks to hold the data until the weekend! No issues with single-threading, either. You can go ahead and make your offsite (non-collocated) copy pool backups while the data is still in the disk pool, so you don't have any exposure to failure in the disk pool. WandaWanda Prather "I/O, I/O, It's all about I/O" -(me) -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Steve Harris Sent: Sunday, September 12, 2004 6:57 PM To: [EMAIL PROTECTED] 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. **************************************************************************** *******
