BMR and dsm.opt Domain values

[GregE]

I've successfully done BMR with only native TSM, but today we did one and with a C:\ drive of 7GB, it only restored 500MB. TSM server showed completion, no errors. The Win2003 BMR'ed server was then rebooted and it rebooted itself continually, never coming up. I wouldn't have expected it to come up since it only restored 2900 files and 500MB of 7GB.

The only difference in this one and the successful one I've done, is that in the BMR file "tsmasr.opt" the DOMAIN on the successful one.....

DOMAIN SystemState
DOMAIN SystemServices
DOMAIN C:
DOMAIN D:

On this UNsuccessful one was....

DOMAIN SystemState
DOMAIN SystemServices
DOMAIN ALL-LOCAL

I'm wondering if when BMR'ing a client, it does not yet understand what "ALL-LOCAL" means since it's not yet built, and instead MUST have drive letters??

This is the only difference, and because there were no errors and TSM acted like it restored all it was supposed to, I'm curious if this DOMAIN ALL-LOCAL is the culprit?

Anyone run into this one?

 

[mallirajan]

I have done the BMR in Both windows and Linux Machine with TSM Server.

I want you to expalin the steps which you handled in configuring the BMR with h TSM Server.

In case of the configuring the Disaster setup have you mentioned the partitions to be taken backup.

Have you configured the Disrec.ini files to the target location.

At the time of recovery process have you used the Linux recovery mode or Windows recovery mode.

Have you selected the Exact Backup time from the TSM Server and the disrec files which you used at the time of Disaster Backup.

Please update these details so that i can go further

 

[GregE]

I have done the BMR in Both windows and Linux Machine with TSM Server.

I want you to expalin the steps which you handled in configuring the BMR with h TSM Server.

In case of the configuring the Disaster setup have you mentioned the partitions to be taken backup.

Have you configured the Disrec.ini files to the target location.

At the time of recovery process have you used the Linux recovery mode or Windows recovery mode.

Have you selected the Exact Backup time from the TSM Server and the disrec files which you used at the time of Disaster Backup.

Please update these details so that i can go further

I used the exact steps in the Backup-Archive User Guide. I've had success with BMR, but not this one server.

I'm not using Cristie, so there is no disrec.ini. I'm using documented TSM BA Client BMR steps.

 

[tmmckinn]

I can't speak to its effect on BMR, but the "all-local" domain specification in general will refer to all local resources, including all disk drives and all systemobjects/services/state. The latter will depend upon the target operating system.

According to the 5.4 client installation and user's guide:
----------------
all-local
Backs up all local hard drives, the systemobject domain (Windows XP), the systemstate domain (Windows Server 2003 and Windows Vista), and the systemservices domain (Windows Server 2003 and Windows Vista). This is the default.
----------------

Please note that it will depend upon your operating system if you specify parts of your domain instead of using all local.

I just can't help but wonder if tsm is getting confused by specifying systemstate and systemservices with all-local on top of that.

 

[GregE]

It's possible. I don't have a test now so I can't say for sure. Basically we were putting larger disks into a system, then were going to restore from TSM down to those disks and hand the owners their same system with larger disks. Didn't work out so well.

What was interesting is when putting the old system back the way it was, by installing Windows first and then pulling from TSM the system state, the number of files was exactly the same as for the attempted BMR, so apparently on the BMR, the systemstate is, in fact, all that it restored during that attempt.

Unfortunately we were on a time schedule to return that client to the owners so we have to abort the mission and put things back as they were and restore by first getting a network-ready Windows OS in place, then restoring. Not true BMR, of course, but we were running out of time and couldn't do any more testing. Had to do what we knew would work since it was after-hours and the day was wasted.