Restore from another node

dannyblair

ADSM.ORG Member
Joined
Aug 13, 2009
Messages
58
Reaction score
0
Points
0
I need some help here. I have seen numerous posts about this but none seem to help me.

I need to restore the complete file system and system state from SERVER-A to SERVER-B.

SERVER-A is up and is a production server. SERVER-B is a test server. Both on windows server 2003. Using TSM 5.5.

1. I have tried putting SERVER-A in SERVER-B's dsm.opt. I have also tried the virtualnodename option.
2. The GUI seems to see the files from server-a ( and when I restore via GUI it restores is back to SERVER-A not SERVER-B) but the command line does not. When I q filespace, I see the its listed but //server-a/ and when i try to restore c:, "there is no backupset for c:" but I CAN restore //server-a/c$. That works but I cannot get the system state to restore.

Its obvious I am doing something wrong here. Can someone help me out?
Thanks..
 
I need to restore the complete file system and system state from SERVER-A to SERVER-B.

SERVER-A is up and is a production server. SERVER-B is a test server. Both on windows server 2003. Using TSM 5.5.

No can do - you cannot restore system state from a virtual node. You need to restore from the node itself.
 
No can do - you cannot restore system state from a virtual node. You need to restore from the node itself.

Not sure I follow. I cannot restore systemstate from one machine to another? They both have the same nodename in dsm.opt.
 
Not sure I follow. I cannot restore systemstate from one machine to another? They both have the same nodename in dsm.opt.

Yes you cannot. That trick you did does not work for system state - restoring from node a to b. System state restore is designed for BMR ON THE NODE itself. TSM will not allow a virtual restore.
 
Last edited:
Yes you connot. That trick you did does not work for system state - restoring from node a to b. System state restore is designed for BMR ON THE NODE itself. TSM will not allow a virtual restore.

Wow. OK well that is a big deal. Thanks for the info.
 
Humm, it looks like it has been done before:
http://www.adsm.org/forum/showthread.php?t=9488

The way I read the post is that the restore would not be successful.

I have tried this and the only way I could see good results is restoring on the node itself. There maybe some Microsoft security features that would not allow you to change or restore system state remotely.
 
Hi,

IF I have understood the problem (and the question) well, then I have to disagree.
What I have just tested (and it works):

1. two servers (TSM nodes) - ClientA, ClientB, both W2k3 32bit, TSM client 5.5.2.12
2. backed up SystemState of ClientA
3. shut down the ClientA machine (so next steps are on CLientB machine)
4. changed "nodename" option in the ClientB dsm.opt (so it presents itself as ClientA)
5. started the GUI on ClientB (it sees files of the ClientA)
6. tried to restore the system state - FAIL (unable to find file ... or something like that)
7. started CLI (dsmc) - logged in as ClientA
8. used "restore systemstate" command - no problem - reboot needed
9. rebooted - voila! - ClientA Windows lives on ClientB machine -> SystemState restore successfull

P.S. both machines were ESX VMs, so the same HW

Harry
 
Harry,
Exacly what I WANT to do, only problem is I cannot bring down SERVER-A. But you hit the nail on the head with what I thought the process would be.
 
Hi,

well, shutting down the Server-A is not "a must", but be sure to reboot the Server-B (now the copy of Server-A) in the isolated network :) You do not want these two to meet :)

Harry
 
Right, I am not going to actually let it join the domain after reboot. The issue seems to be though, is that the system restore will not work with the original machine up.
 
Hi,

it is not the problem - restore of the systemstate works with the original machine up - it is normal file-level restore, windows just knows it is a SystemState, so the files are saved (restored) to alternate location and replaced during reboot - so no problem there (just tested that).
Problem you may encounter using command line from another node is as follows:
when running backup of C: drive on ClientA, then it is saved into filespace \\ClientA\c$ - use "q files" command to check.
The ClientA in the filespace name is not the nodename, it is the HOSTNAME of the machine.
So when you try to use "restore C:" on machine with hostname ClientB and you use nodename ClientA, then it still tries to restore the \\ClientB\c$ filespace - which is not there.
So your restore command (for drive C: - I do not like automatic emoticons replacement here) should be:

restore \\ClientA\c$\* -sub=yes c:

Harry
 
Hi, please help with Win 2003 systemstate restore on other server. Unfortunately procedure described bellow did not succeded to restore data. We did not see systemstate backup on other server. The original one is down. There were data on original server available, but if we try to restore from other server, there is no data. We have tsm v6.1. windows server. The backup is done using b systemstate.
Thanks in advance for any help!
 
Hi,

this is not related to the server level. You have to use the same or higher TSM client package - so use the newest you can find (6.2.3.3 should be the newest these days).
Can you show us the "q node <old_server_nodename> f=d" from the server and then output from these commands (on the client)
q sess (so we can see you are using correct nodename)
q files (so we can see the filespaces on the server)
your restore attempt (where it shows "not found" message)


Harry
 
Back
Top