| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 598.1 | It should work... | BACHUS::DEVOS | Manu Devos NSIS Brussels 856-7539 | Mon Apr 21 1997 01:59 | 11 |
| Hi,
To restore the filesystems of SYSTEM-A into SYSTEM-B,
first you should have created the NSR client SYSTEM-B,
even if it is NOT backup-ed. Secondly, the NSR setup of
SYSTEM-A should include SYSTEM-B in the "recover access"
field. Thirdly, you should either use the GUI nwrecover
or the command line on SYSTEM-B giving SYSTEM-A for client
(or recover -c SYSTEM-A for the cli).
Manu.
|
| 598.2 | | DECWET::KOWALSKI | Spent Time. Borrowed time. Stole time. Did time. | Mon Apr 21 1997 07:50 | 3 |
| Also, system B should have an architecture similar
to system A. If A is Windows NT and B is UNIX,
the recover A->B is not supported.
|
| 598.3 | futher explanation | DEKVC::YONGJOONCHOI | | Mon Apr 21 1997 18:24 | 6 |
|
Thanks
I am not fully understand
I mean restore of System A into System B by way of NSR Server
not System A into System B directory.
|
| 598.4 | server directed recovers is not designed into current product | DECWET::EVANS | NSR Engineering | Thu Apr 24 1997 16:04 | 3 |
| but will be in a future release. NT will have it first, then Unix later.
For now, one *must* initiate the recover from the client desiring the data.
|
| 598.5 | Here a real customer story ! | BACHUS::DEVOS | Manu Devos NSIS Brussels 856-7539 | Fri Apr 25 1997 03:03 | 42 |
| Hi Bruce,
>>> < server directed recovers is not designed into current product >
Just to allow you to know the consequence of this missing feature, I
am going to tell a real customer story that I had to debug...
Config: 2 Big 8400 in an ASE CLUSTER - One is NSR server, the other
Client, and two services production and test. The application consists
of an "Inter-banking messages store application"
Due to a stupid omission in a find command to delete old logfiles, the
files older than one week were removed out of the TWO systems during
the night !!! No need to explain that the disaster is hitting this big
server.
I was contacted, and adviced to load the Unix CDrom, then vrestore the
latest "vdump" tapes containing "/, /usr and /nsr". Then mmrecover with
the bootstrap information, then restore the last situation from the now
running NSR server. So far, so good ; four hours later the first system
was up and running as well as the application.
I adviced then to apply the same sequences of steps to the second
member of the cluster. Two hours later, I was again called to learn
that the first system has crashed during the time the second system was
in recovery from DECnsr. "Is it possible that the heavy traffic
generated by the recovery of the second system is causing the first
system to crash?" asked the customer. I said that I am going
immediately to see what happens
The problem was that the customer believed that he can recover the
"client" member from the nwrecover window opened on the "NSR server"
member. As the "recover access field" was giving access to each other,
the customer was recovering the client system on the server system
thinking that he was recovering the client !!!" So the crash ...
And a 24 hours interruption of this "Highly Available Server" !!!
Maybe some messages should warn the operator when it is trying to
restore data from one client into another one.
Manu.
|
| 598.6 | Work-around | SWETSC::WESTERBACK | Panta rei | Fri Apr 25 1997 03:13 | 9 |
| Re .4:
Not necessarily, one scenario is that if you're logged in to client B
and want to make a recover of files from drive X on client A to the
original location, you can map drive \\clientA\X to drive X on client B
then start the recover.
Hans
|