Restore rates for TSM Nodes

[supermoe]

Today's buzz words are Business Continuity and Disaster Recovery...



My organization recently had a failure that required us to restore a single drive on a single server. Not tiny, but not that large either. Well, the restore to this WINDOWS client completed 30 hours later. Next, we saw poor rates on a AIX BMR Restore for a DR test.



As luck would have it, I just attended the TSM DRM class and learned a little about TSM SysBack (for UNIX/AIX restores), Cristie BMR (for WINDOWS boot-up processes) and TSM Backup Sets (to reduce tape mounts on WINDOWS data).



We're going to demo TSM SysBack soon for the UNIX guys. As far as our WINDOWS boxes, I'm thinking a combo of Cristie BMR to speed up the boot to a DR server, followed by a Backup Set restore may the fastest way to restore that we may have at our utilization - for the most critical servers.



I'd appreciate insight to your methods to see if I'm on the right track. What's your opinions of the best methods to restore UNIX & WINDOWS boxes? What's your opinion of TSM SysBack & Cristie BMR? Any negatives?



Thanks, Dave.

 

[KB]

Dave,



30 hours for a Windows box restore seems very long. Can you share some more details? It sounds like there are some underlying issues that need to be taken care of before getting into BMR helper products.



Back to Sysback: My experience with it was very good. You need a good understanding of AIX and the NIM environment. TSM becomes the respository for the mksysbs. There are many day-to-day system management benefits of having the NIM environment in place.

 

[sgabriel62]

Sysback is good to use, but if you maintain your golden images and mksysb you should do just fine without it. Here at the FARM, we are heavy in NIM as you can image and yes TSM maintains the image copies. We have our OS team recovery the servers using the images. Then TSM is used to recover the incrementals. WE rarely use Backupsets for restores. Backupsets are good for point in time restores, if this is the direction you are wanting to take. Keep in mind the recovery of backup sets are not singular in nature.

In repect to your Windows clients, your hardware configurations are at a mismatch. There is no way a windows box will take 30 hours to recover unless you have a database attached that is at least 40TB is size. Bare Metal Recovery is a very good tool to use. But you will still need TSM to recover incrementals. Our windows team have created a home grown tool to recover the servers. This accomodates for multiple drives, SAN attached arrays, etc... Keep in mind BMRs are for equal platforms or greater.

Good luck in your Demos. Let us know how they turned out



Steve

 

[itdrew]

sqabriel62,



We have a windows cluster here that takes about 30 hours to restore the data resources, at least from an incremental restore. It has 5.5 million files on it, only about 1 TB of data. We are trying to figure out hte best approach to using TSM on this server. Right now there are forces at work trying to remove TSM from at least this server and perhaps others.

Would doing backupsets make sense on this windows node or should we be using CBMR to image the data drives?



Back to Sysback. We use the mksysb approach and it works well for us. My old job we used Sysback and it was integrated into TSM. Both work well, but I think NIM with Sysback is the better solution becasue you are actally managing the BMR environment with a software tool rather then doing it manually by creating and managing mksysb DVDs.

 

[supermoe]

I appreciate the replies. We are still in the process of setting up the demos for Cristie & SysBack, but I'm seeing there are many customized approaches out there that will meet each individual need.



As far as the story behind our 30 hour Windows restore, I had my normal daily cycle running concurrently with the restore and saw that there were LONG gaps in tape mounts while the cycle was as it busiest periods (which, unfortunately, is most of the night). We run TSM on z/OS, so perhaps we are more affected by system contention than most of you guys, since we are sharing our mainframe resources with other systems. I plan to address this with my IBM/TSM consultant next month.



Thanks.