Re: Bug or request for design?
Since the problem you indicate is beyond the first-failure (ever heard of FFDC -- first-failure data capture), you really cannot expect the subsequent results to be predictable. The current behavior seems reasonable, to me; you cannot do a restore -- (and) hopefully, you also cannot do any other functions, either. You could request the design change (to prevent further client operations -- yet still keep the window open so you can see - and respond to - the error message). I would consider it a bug if any functions affected by INCLEXCL were allowed to proceed; the fact that restore "shows no files" is one way of doing that for the restore function -- what about backup/archive/retrieve?!? - Original Message - From: "Loon, E.J. van - SPLXM" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, March 18, 2002 1:18 AM Subject: Bug or request for design? > Hi *SM-ers! > I would like to know your opinion on something: > I opened a PNR for the following TSM client behavior: > The TSM client (AIX and NT tested) doesn't list any restorable objects when > the options file contains an error. > Try the following on AIX: rename your include/exclude file and start the TSM > client. It returns the error: ANS1036S Invalid option 'INCLEXCL' found in > options file. Click on OK and now click the restore button on the main GUI. > No files are listed! > This was quite disturbing for our UNIX people! When you correct the > include/exclude and you restart the GUI all files are listed again. > To my opinion, this is clearly a bug, but this was the response form the > Tivoli lab: > With both the command line and the GUI, the TSM client informed the user of > the option file problem and location. If the option file problem is > resolved, normal client behavior is returned. This appears to be a request > for a design change. > What do you think? Is it a bug or am I a nit-picker? > Kindest regards, > Eric van Loon
Re: versioning for user's files
You're on the right track... 1. VE/VD/RE/RO parms would be */*/42/42 -- that gives you point-in-time restore for any file over the past 6 weeks; do the math, and monitor the actual usage -- most shops experience less than 10% turnover per work-day, we did our sizing based on 5% (even that was abit on the high side). Using these parameters gives you exactly what you have today, without re-sending files that don't change (using the "standard" progressive incremental backup in TSM)... and you'll save over 90% of tape real estate in the process! 2. Monthly backup sets, with two year retention; this gives you the monthly snapshot of all "active" versions -- again, exactly matches your current situation -- and, again, without sending the data over the network. Hope this helps. Don France Technical Architect - Tivoli Storage Manager Professional Association of Contract Employees (P.A.C.E.) San Jose, CA mailto:[EMAIL PROTECTED] - Original Message - From: "Ken Long" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, March 17, 2002 5:21 PM Subject: versioning for user's files > Hello all... > > We're migrating our NetWare servers, currently backed up with ArcServe, to > W2K servers which will be backed up with TSM. These NetWare servers > contain programs, users' home directories, and shared directories. > > The existing NetWare server backup is a full backup every day, all to one > DLT tape. The number of tapes in rotation provides for going about six > weeks, or 30 backups, before a tape is reused. Also, at the end of each > month the tape is removed from the rotation and held for two years. > > My challenge is to provide a reasonable level of backup availability with > TSM. All I've backed up with TSM thus far are application servers where > users (other than administrators) don't have access. We keep 7 versions on > those servers. > > Our NetWare users sometimes ask for restores of files more than a year old, > and their requests have been fulfilled. I'm struggling to come up with a > version scheme which will provide a similar level of service. > > It seems a bit extreme, but my first thought is to keep 30 versions and do > a monthly backupset of the W2K file server. But that 30 versions is having > a nasty effect on calculations of the resulting TSM database size. > > What kind of versioning do you set for user files, shared documents, etc., > which are, in my mind, more volatile than application server files because > users are involved? Any examples of the model you use would be > appreciated. > > Thanks... Ken
Re. War stories: Restores > 200GB ?
There are several keys to speed in restoring a large number files with TSM; they are: 1.. If using WindowsNT/2000 or AIX, be sure to use DIRMC, storing primary pool on disk, migrate to FILE on disk, then copy-pool both (this avoids tape mounts for the directories not stored in TSM db due to ACL's); I've seen *two* centralized ways to implement DIRMC -- (1) using client-option-set, or (2) establish the DIRMC management class as the one with the longest retention (in each affected policy domain); 2.. Restore the directories first, using -DIRSONLY (this minimizes NTFS db-insert thrashing); 3.. Consider multiple, parallel restores of high-level directories -- despite potential contention for tapes in common, you want to keep the data flowing on at least one session to maximize restore speed; 4.. Consider using CLASSIC restore, rather than no-query restore -- this will minimize tape mounts, as classic restore analyzes which files to request and has the server sort the tapes needed -- though tape mounts may not be an issue with your high-performance configuration; 5.. If you must use RAID-5, realize that you will spend TWO write cycles for every write; if using EMC RAID-S (or ESS), you may want to increase write-cache to as large as allowed (or turn it off, altogether). Using 9 or 15 physical disks will help. A client of mine just had a server disk failure last weekend; it had local disk configured with RAID-5 (hardware RAID controller attached to Dell-Win2000 server) -- after addressing items 1 to 3, above, we were able to saturate the 100Mbps network, achieving 10-15 GB/Hr for the entire restore -- only delays incurred were attributable to tape mounts... this customer had an over-committed silo, so tapes not in silo had to be checked-in on demand. 316 GB restored in approx. 30 hours. Their data was stored under 10 high-level directories, so we ran two restore sessions in parallel -- only had two tape drives -- and disabled other client schedules during this exercise. For your situation, 250 GB and millions of files, and assuming DIRMC (item #1, above), you should be able to see 5 - 10 GB/Hr -- 50 hours at 5 GB/Hr, 25 hours at 10 GB/Hr. So you are looking at two or three days, typically. Large numbers of small files is the "Achilles Heal" of any file-based backup/restore operation -- restore is the slowest (since you are fighting with the file system of the client OS) because of the way file systems traverse directories and reorganize branches "on the fly", it's important to minimize the "re-org" processing (in NTFS, by populating the branches with leaves AFTER first creating all the branches). We did some benchmarks and compared notes with IBM; on another client, we developed the basic expectation that 2-7 GB/Hr was the "standard" for comparison purposes -- you can exceed that number by observing the first 3 recommended configuration items, above. How to mitigate this: (a) use image backup (now available for Unix, soon to be available on Win2000) in concert with file-level progressive incremental; and (b) limit your file server file systems to either 100 GB or "X" million files, then start a separate file system or server upon reaching that threshold... You need to test for your environment to determine what is the acceptable standard to implement. Hope this helps. Don France Technical Architect - Tivoli Certified Consultant Professional Association of Contract Employees (P.A.C.E.) San Jose, CA
