Interesting approach, Zlatko; I agree, this should work -- if one is very serious about restore SLA (and simulating Unix filespace-level collocation -- using node-level collocation with your suggestion); a simpler approach could accomplish the same effects: cap drive-letter size at 100 or 250 GB, or maybe even 500 GB, then start a new drive letter. (The drive-letter is a filespace on Windows platforms... until/unless you get into the DFS or NTFS virtual volume game and then it's not that much different).
If the customer restore SLA can "tolerate" 10-20 GB/Hr, a 300 GB cap with DIRMC "tricks" will be sufficient; just use high-level directories for "GrpData" and "UsrData" with multiple restore threads; using classic (rather than no-query) restore causes tape mounts to be sorted (more think time on the server), it's another performance trade-off (lots of tapes, collocation, lots of versions, large number of files being restored -- all interact to affect restore speed). I've supported several emergency server recovery situations, recent customer had DLT, no collocation, DIRMC (worked great), 316 GB was restored in 30 elapsed hours -- that would have been more like 20 hours if they hadn't over-committed the silo, requiring tape mounts for over 40 tapes in a 29 slot silo. Tim ==> BTW, if you are going to use NAS filer from IBM, you can run the backups (from the filer); so, with weekly (or monthly) full-image, in concert with daily (or weekly) differential-image, plus normal daily progressive-incremental (for file-level granularity), you'd get the fastest file restore *and* server recovery possible... probably saturate the network, getting 30 or 300 GB/hr (100Mbps vs. 1 Gbps). Also, have you looked at Snapshot and/or SnapMirror support?!? IBM NAS comes with TSM Agent at 4.2 level; IBMSnap, PSM & DoubleTake components allow you to protect the NAS-based data on the NAS (so you could mirror each drive-letter or network share) and run backups (image and file-level) directly from the NAS. This kind of online/nearline recovery could totally mitigate your restore SLA concerns; if your SLA states 99% of the time, recovery must be done in less than 4 hours, you are covered -- you only need tape restores for site-level or drive-level disaster, which becomes less than 1% of the failure instances, over time (after the first year). See the latest RedBook info about Snapshots & Replication with PSM & Double-Take -- built-in components of the IBM NAS, along with TSM client. Typical NAS customers get a bunch of snap/mirror capacity (sufficient for a number of days worth of Snapshots plus some RAID-1 protection of critical data, RAID-like striping for faster performance, etc.)... so, you probably won't need TSM tapes as much as in the old days where all the backup data resides (exclusively) on tapes. JBOD devices have gotten soooo cheap, it's not terribly expensive to keep 7 or 14 days of incremental snapshots online (in the ~snapshot directory, if using NetApp Snapshot, for example); once the end user is told where his snapshot data is stored, he stops calling in trouble tickets for restores less than the snapshot retention period! Check out the RedBooks on IBM NAS... up and coming, cheap (JBOD) solutions to large file servers. See this one, to start http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/sg246831.html Looks like you are in for some *actual* fun, with this project!!! Don France Technical Architect -- Tivoli Certified Consultant Tivoli Storage Manager, WinNT/2K, AIX/Unix, OS/390 San Jose, Ca (408) 257-3037 mailto:[EMAIL PROTECTED] Professional Association of Contract Employees (P.A.C.E. -- www.pacepros.com) -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of Zlatko Krastev Sent: Saturday, August 17, 2002 9:03 AM To: [EMAIL PROTECTED] Subject: Re: question on configuring large NT client for optimum restore proce ssing Tom, try to emulate virtualmountpoint through separate node names: - for each huge directory (acting as "virtualmountpoint") define a node. In dsm.opt file define -- exclude X:\...\* -- include X:\<the_dir>\...\* -- exclude.dir X:\<dir_1> -- exclude.dir X:\<dir_2> -- exclude.dir X:\<dir_3> - define other_dirs node with excludes for all "virtualmountpoints" and without first exclude and the include. Thus only the directory is included, existing known directories are exclude.dir-ed and not traversed. If new directory is created and forgotten to be excluded it will be traversed but only structure will be backed up and not files. Last node will backup all but "virtualmountpoint" directories. You can create several schedule services and add them to MSCS resource group for that (one-and-only) drive. Collocation will come from itself. Disclaimer: never solved such a puzzle nor tested it but ought to work. Zlatko Krastev IT Consultant Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: question on configuring large NT client for optimum restore proce ssing What's the preferred method of configuring a large NT fileserver for optimum data recovery speed? Can I do something with co-location at the filesystem (what IS a filesystem in NT/2000?) level? We're bringing in an IBM NAS to replace four existing NT servers and our recovery time for the existing environment stinks. The main server currently has something over 800,000 files using 167 GB (current box actually uses NT file compression, so it's showing as 80 GB on NT). We had to do a recovery last year (raid array died) and it ran to 40+ hours; I'm getting the feedback that over 20 hours will be un-acceptable. The TSM server and the client code are relatively recent 4.2 versions and will be staying at 4.2 for the rest of this year (so any neat features of TSM 5 would be nice to know but otherwise unuseable :-) To add to the fun and games, this will be an MS cluster environment. With 1.2 TB of disk on it. We do have a couple of weeks to play around and try things out before getting serious. One advantage to the MSCS is that disk compression is not allowed, so that should speed things up a bit on the restore. Tom Kauffman NIBCO, Inc
