restore master to another box

Is it possible to Restore Master db from a backup to a box/ instance with
another name? Will it cause any problems?
sql2k sp3
TIA, ChrisR
It's possible, but kind of a risky proposition, and it really depends on what
you're trying to accomplish, why you're moving the database, other databases
involved, server and database configuration, etc. Check BOL "Restoring the
master Database from a Current Backup" and "Copying Databases to Other
Servers" for details.
You also might want to look at sqlservercentral.com - a couple of links I
found are
http://www.sqlservercentral.com/colu...toremaster.asp and
http://www.sqlservercentral.com/foru...messageid=8387
Personally, I install SQL Server on the destination server and detatch /
attatch the databases from old to new server. There used to be a Knowlege
Base article Q245133 that had code to generate scripts to recreate the
logins, but I couldn't find it. Let me know if you need it and I'll mail the
code to you - mstuart_spamtastesgood@.gates.com - drop the _spamtastesgood, of
course :-)
Mike
"ChrisR" wrote:

> Is it possible to Restore Master db from a backup to a box/ instance with
> another name? Will it cause any problems?
> --
> sql2k sp3
> TIA, ChrisR
>
>
|||For the moment Im only trying to do some Disaster Recovery planning.
"Mike" <mstuart_spamtastesgood@.gates.com> wrote in message
news:1BDC103A-A9E2-48F1-B93F-2C28C2118EA9@.microsoft.com...
> It's possible, but kind of a risky proposition, and it really depends on
what
> you're trying to accomplish, why you're moving the database, other
databases
> involved, server and database configuration, etc. Check BOL "Restoring
the
> master Database from a Current Backup" and "Copying Databases to Other
> Servers" for details.
> You also might want to look at sqlservercentral.com - a couple of links I
> found are
> http://www.sqlservercentral.com/colu...toremaster.asp and
>
http://www.sqlservercentral.com/foru...=24&messageid=
8387
> Personally, I install SQL Server on the destination server and detatch /
> attatch the databases from old to new server. There used to be a Knowlege
> Base article Q245133 that had code to generate scripts to recreate the
> logins, but I couldn't find it. Let me know if you need it and I'll mail
the
> code to you - mstuart_spamtastesgood@.gates.com - drop the _spamtastesgood,
of[vbcol=seagreen]
> course :-)
> Mike
> "ChrisR" wrote:
with[vbcol=seagreen]
|||First and foremost, backup all your databases and test your backups! There's
nothing worse (professionally, anyway) than thinking you've got good backups
and you don't when you need them. Ask me how I know...
Read BOL on recovering master and practice recovering. You should be able
to copy your environment onto a second server for testing purposes by:
1 - installing SQL Server and service packs on another server,
2 - stop SQL Server on the test server,
3 - copy the system data and log files to another location,
4 - stop SQL Server on your source server and copy all data and log files
from source to test environment,
5 - then restart SQL Server.
You'll also need backups of the other system databases (model and msdb).
Probably won't need to worry about pubs or Northwind unless you've got some
custom code in those databases you want to keep.
You'll also want to script out the logins and passwords - see the KB article
I referred to earlier. Depending on the number of changes to your login
accounts, you might even want to script a job to run and recreate the file
auto-magically.
Assuming you're not running earlier that SQL 7.0, you won't need to worry
about scripting out CREATE and ALTER database statements to add space to your
data and log files (I'm probably getting the terminology wrong - it's been a
very long time since SQL 4.2 and 6.5!!), but you'll want to know where you
created your database data, log and backup files so you don't have to go
searching everywhere when the pressure is on and the boss is looking over
your shoulder.
Finally, document on paper in clear, readable text with pictures (if
necessary) how to go about restoring your environment. You might even want
to have a coworker 'monkey test' it for you (can a monkey read your
directions and successfully do whatever you wrote down).
It sounds like extreme overkill, but at 2:00 in the AM and the payroll
server is down and you're the person they come to, you will definitely look
like a hero if you can pull it off, and you may lose your job if you can't.
Good luck!
Mike
"ChrisR" wrote:

> For the moment Im only trying to do some Disaster Recovery planning.
>
> "Mike" <mstuart_spamtastesgood@.gates.com> wrote in message
> news:1BDC103A-A9E2-48F1-B93F-2C28C2118EA9@.microsoft.com...
> what
> databases
> the
> http://www.sqlservercentral.com/foru...=24&messageid=
> 8387
> the
> of
> with
>
>
|||Mike I appreciate your response. But do all of your instructions hold true
for a box with another name? Also, your are referring to copying system db
files. Will that get me around the downfalls of restoring master to a box
with another name?
"Mike" <mstuart_spamtastesgood@.gates.com> wrote in message
news:4D09B9F2-B7D8-4824-9809-2188E93999BC@.microsoft.com...
> First and foremost, backup all your databases and test your backups!
There's
> nothing worse (professionally, anyway) than thinking you've got good
backups
> and you don't when you need them. Ask me how I know...
> Read BOL on recovering master and practice recovering. You should be able
> to copy your environment onto a second server for testing purposes by:
> 1 - installing SQL Server and service packs on another server,
> 2 - stop SQL Server on the test server,
> 3 - copy the system data and log files to another location,
> 4 - stop SQL Server on your source server and copy all data and log files
> from source to test environment,
> 5 - then restart SQL Server.
> You'll also need backups of the other system databases (model and msdb).
> Probably won't need to worry about pubs or Northwind unless you've got
some
> custom code in those databases you want to keep.
> You'll also want to script out the logins and passwords - see the KB
article
> I referred to earlier. Depending on the number of changes to your login
> accounts, you might even want to script a job to run and recreate the file
> auto-magically.
> Assuming you're not running earlier that SQL 7.0, you won't need to worry
> about scripting out CREATE and ALTER database statements to add space to
your
> data and log files (I'm probably getting the terminology wrong - it's been
a
> very long time since SQL 4.2 and 6.5!!), but you'll want to know where you
> created your database data, log and backup files so you don't have to go
> searching everywhere when the pressure is on and the boss is looking over
> your shoulder.
> Finally, document on paper in clear, readable text with pictures (if
> necessary) how to go about restoring your environment. You might even
want
> to have a coworker 'monkey test' it for you (can a monkey read your
> directions and successfully do whatever you wrote down).
> It sounds like extreme overkill, but at 2:00 in the AM and the payroll
> server is down and you're the person they come to, you will definitely
look
> like a hero if you can pull it off, and you may lose your job if you
can't.[vbcol=seagreen]
> Good luck!
> Mike
>
> "ChrisR" wrote:
on[vbcol=seagreen]
"Restoring[vbcol=seagreen]
links I[vbcol=seagreen]
and[vbcol=seagreen]
http://www.sqlservercentral.com/foru...=24&messageid=[vbcol=seagreen]
/[vbcol=seagreen]
Knowlege[vbcol=seagreen]
mail[vbcol=seagreen]
_spamtastesgood,[vbcol=seagreen]
|||Chris,
I guess I don't understand what you mean by the other box. If I understand
correctly, you have your server (we'll say production for sake of arguement)
that you want to develop a DR plan for. You need to set up an environment to
develop and test a plan against. So, you need to go through the steps I
outlined earlier - including the system .mdf and .ldf files.
One thing I did forget (yikes!) was that the master database .mdf and .ldf
files that you copy from the production server will still think that the name
of the SQL Server instance is the name of the production server. Run
'sp_dropserver' and 'sp_addserver' (see BOL 'Renaming a Server') to change
the instance name to the name of the development / test server.
This isn't exactly a restore of 'master' in the strictest sense of the word.
Your master database contains all of the information that allows the SQL
Server engine to see all of the databases installed on that instance of SQL
Server. You're just copying the master database, and all of the other
databases from the production instance to the development / test instance of
SQL Server.
If my directions are still unclear, email me @.
mstuart_spamtastesgood@.gates.com (drop the 'spamtastesgood') with you number
and I'll try to clarify things for you.
Mike