I am working on our first TSM based DR plan for our data centre. We currently have a successfully tested several times plan using system specific tools, such as Sysback/6000 for AIX, BRM for AS/400, ArcServe for Novell and WinNT. We have been asked to convert to TSM to consolidate all backups in one tool.
We have recently installed an NSM running TSM version 4.1.3.0, soon to be upgraded to 4.2.2.1 because that is the newest version certified for the NSM. It is attached to an LTO library. There is no HSM activated, but the TSM Server is backing up numerous clients that have to be restored in a DR scenario. Many of them are NT4.0, Windows 2000 and soon Windows XP servers of various sizes. There are also several AIX 4.3.3.ML09 servers. I have the TSM Server recovery down to probably the bare minimum time of 4-6 hours, depending on the power of the machine it is being recovered on. This does not include creating the disk pools, which can take another 12-18 hours but is not part of the critical path. The biggest Windows servers run Exchange or SQL Server, which tend to back up large blobs of data that are relatively easy to restore. Two of the AIX servers are p680's with 750 logical volumes, 500 filesystems and 1.5-2 terabytes of total data each, 250-350gb of data backed up nightly. For my current test, the DR media pool is 107 cartridges. I have to restore the data in stages. Neither the command line client nor the GUI will allow me to select all the filespaces I need at once for the first pass. The command line tells complains that it is too long and the GUI simply fails before starting if I choose too many filesystems. Even if one of them worked properly, I would have to pass at least 75 of those tapes to do the restore. This initial pass includes great chunks of the /home filesystem where things are changing every day. For my DR test, I am running on a p610 with a single, stand-alone LTO drive. It takes about 12 hours to pass those 75 tapes once. I will have to pass them 3-5 times for each restore. For the real DR test, I will have an F50 and 3 LTO drives, but I will be restoring at the same time as all the other critical servers, so I will be lucky to get a single drive to myself, and it is the LOAD, UNLOAD and LOCATE parts of the process that take up the bulk of the time. Actual data transfer is quite well optimized, once the data is located. I am currently looking at 2 possible ways to improve this. None of the servers will have direct attached backup/recovery devices of sufficient capacity, throughput, or reliability to be useful. We cannot afford enough drives to cover all the servers. All restores must be done via the TSM server. One possibility is to use BACKUP SETs. But I am concerned that BACKUP SETs are oriented to local restore scenarios and am not sure how easy they are to manage and restore from a central storage (NSM/TSM) point of view. There is also some concern about the additional TSM activity creating the BACKUP SETs would cause on an already fairly close to capacity NSM. The second option is to do full system ARCHIVES, but this would cause activity on both the NSM and the client, neither of which have available windows for this activity. Because either of these possibilities would, of necessity, be occasional (at best once a week), there is the additional issue of how easy it is to bring the system up to the most current backup after the restore. Would a multi-filespace simple restore be intelligent enough to pass only the last 7 days of tape or would it pass all tapes with those filespaces on them? A third possibility I have thought of recently is to isolate these very large servers in their own COPY POOLs, effectively co-locating only these servers, but I am not convinced this would reduce the number of tapes passed by the DR restores, and it would certainly increase the total number of tapes in the DR set and increase off-site reclamation activity, which already takes the better part of the day shift most days. Sorry for the long post. And thanks for any hints more experienced TSM users can provide. I have a 48 hour DR Test window in which to build the TSM Server, restore data to clients, hand the clients to the DBA's to rebuild the databases, and test the end user applications. In the past, we ran SYSBACK/6000 on the AIX servers and were usually home and cooled in 36 hours. But the AIX servers have been consolidated from 7 large servers to 2 enormous servers and the SYSBACK/6000 would also struggle to complete in the 48 hour window. The point of going with TSM was to try to improve on this. P.S. Where are the AS/400 clients? When we were sold the product, we were told it ran on AS/400. We foolishly assumed this meant the client first, server second ... <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Werner (Vern) Kliewer Sr. ITS Analyst Mid-Range Support Manitoba Public Insurance (204)-985-7745 [EMAIL PROTECTED] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
