I'm sure restoring master/msdb on the same server should
be no issue. But restoring on separate hardware might
have these issues (if you know others please tell me):
1: File path (drive letter, file path) different for the
location of the database on the replacement server;
2: Security issues. The separate Windows installation is
sure to have different SID, and since SQL Server security
is tightly integrated with Windows security, what might be
broken, what will the restore take care of, and what needs
to be manually fixed up-and how? (BTW, our installation
uses mixed mode security)
Regarding issue 1: I have experienced that restoring over
an existing database causes the file locations to be
automatically fixed up by the restore, taking the file
locations from the database being overwritten rather than
the locations saved in the backup. Will this work for
master/msdb?
I don't know what to expect regarding issue #2.
Any help appreciated! Thanks!Hi
Try the following:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;224071
John
"Scott" <anonymous@.discussions.microsoft.com> wrote in message
news:094d01c3fd71$ab484d80$a601280a@.phx.gbl...
> I'm sure restoring master/msdb on the same server should
> be no issue. But restoring on separate hardware might
> have these issues (if you know others please tell me):
> 1: File path (drive letter, file path) different for the
> location of the database on the replacement server;
> 2: Security issues. The separate Windows installation is
> sure to have different SID, and since SQL Server security
> is tightly integrated with Windows security, what might be
> broken, what will the restore take care of, and what needs
> to be manually fixed up-and how? (BTW, our installation
> uses mixed mode security)
> Regarding issue 1: I have experienced that restoring over
> an existing database causes the file locations to be
> automatically fixed up by the restore, taking the file
> locations from the database being overwritten rather than
> the locations saved in the backup. Will this work for
> master/msdb?
> I don't know what to expect regarding issue #2.
> Any help appreciated! Thanks!
>|||OK, thank you, these seem to indicate my concerns were
right.
However, all the documentation you pointed me at seems to
assume the original databases are operational; they are
read, or even modified, by these procedures, and
transferred as operational databases.
I need procedures for FAILED systems, i.e., only the
backups are available, not the databases themselves.
Any more help, anyone?
Thanks!
>--Original Message--
>Hi
>Try the following:
>http://support.microsoft.com/default.aspx?scid=kb;EN-
US;224071
>John
>"Scott" <anonymous@.discussions.microsoft.com> wrote in
message
>news:094d01c3fd71$ab484d80$a601280a@.phx.gbl...
>> I'm sure restoring master/msdb on the same server should
>> be no issue. But restoring on separate hardware might
>> have these issues (if you know others please tell me):
>> 1: File path (drive letter, file path) different for
the
>> location of the database on the replacement server;
>> 2: Security issues. The separate Windows installation
is
>> sure to have different SID, and since SQL Server
security
>> is tightly integrated with Windows security, what might
be
>> broken, what will the restore take care of, and what
needs
>> to be manually fixed up-and how? (BTW, our installation
>> uses mixed mode security)
>> Regarding issue 1: I have experienced that restoring
over
>> an existing database causes the file locations to be
>> automatically fixed up by the restore, taking the file
>> locations from the database being overwritten rather
than
>> the locations saved in the backup. Will this work for
>> master/msdb?
>> I don't know what to expect regarding issue #2.
>> Any help appreciated! Thanks!
>
>.
>|||Hi
I have never tried it, but if you can restore the database into another
database then you can get the files, so you can then follow the procedure.
John
<anonymous@.discussions.microsoft.com> wrote in message
news:357a01c3fd86$69962b40$a001280a@.phx.gbl...
> OK, thank you, these seem to indicate my concerns were
> right.
> However, all the documentation you pointed me at seems to
> assume the original databases are operational; they are
> read, or even modified, by these procedures, and
> transferred as operational databases.
> I need procedures for FAILED systems, i.e., only the
> backups are available, not the databases themselves.
> Any more help, anyone?
> Thanks!
>
> >--Original Message--
> >Hi
> >
> >Try the following:
> >http://support.microsoft.com/default.aspx?scid=kb;EN-
> US;224071
> >
> >John
> >
> >"Scott" <anonymous@.discussions.microsoft.com> wrote in
> message
> >news:094d01c3fd71$ab484d80$a601280a@.phx.gbl...
> >> I'm sure restoring master/msdb on the same server should
> >> be no issue. But restoring on separate hardware might
> >> have these issues (if you know others please tell me):
> >>
> >> 1: File path (drive letter, file path) different for
> the
> >> location of the database on the replacement server;
> >>
> >> 2: Security issues. The separate Windows installation
> is
> >> sure to have different SID, and since SQL Server
> security
> >> is tightly integrated with Windows security, what might
> be
> >> broken, what will the restore take care of, and what
> needs
> >> to be manually fixed up-and how? (BTW, our installation
> >> uses mixed mode security)
> >>
> >> Regarding issue 1: I have experienced that restoring
> over
> >> an existing database causes the file locations to be
> >> automatically fixed up by the restore, taking the file
> >> locations from the database being overwritten rather
> than
> >> the locations saved in the backup. Will this work for
> >> master/msdb?
> >>
> >> I don't know what to expect regarding issue #2.
> >>
> >> Any help appreciated! Thanks!
> >>
> >
> >
> >.
> >|||!!!
Yeah, that sound right. Ahh, Friday. Sorry for my fuzzy
head. And THANKS for your response.
Don't know the real state of our failed server, so I don't
know if we'll really have to do this. If we DO, I'll
respond and let you know.
Thanks again!
--Scott
>--Original Message--
>Hi
>I have never tried it, but if you can restore the
database into another
>database then you can get the files, so you can then
follow the procedure.
>John
><anonymous@.discussions.microsoft.com> wrote in message
>news:357a01c3fd86$69962b40$a001280a@.phx.gbl...
>> OK, thank you, these seem to indicate my concerns were
>> right.
>> However, all the documentation you pointed me at seems
to
>> assume the original databases are operational; they are
>> read, or even modified, by these procedures, and
>> transferred as operational databases.
>> I need procedures for FAILED systems, i.e., only the
>> backups are available, not the databases themselves.
>> Any more help, anyone?
>> Thanks!
>>
>> >--Original Message--
>> >Hi
>> >
>> >Try the following:
>> >http://support.microsoft.com/default.aspx?scid=kb;EN-
>> US;224071
>> >
>> >John
>> >
>> >"Scott" <anonymous@.discussions.microsoft.com> wrote in
>> message
>> >news:094d01c3fd71$ab484d80$a601280a@.phx.gbl...
>> >> I'm sure restoring master/msdb on the same server
should
>> >> be no issue. But restoring on separate hardware
might
>> >> have these issues (if you know others please tell
me):
>> >>
>> >> 1: File path (drive letter, file path) different for
>> the
>> >> location of the database on the replacement server;
>> >>
>> >> 2: Security issues. The separate Windows
installation
>> is
>> >> sure to have different SID, and since SQL Server
>> security
>> >> is tightly integrated with Windows security, what
might
>> be
>> >> broken, what will the restore take care of, and what
>> needs
>> >> to be manually fixed up-and how? (BTW, our
installation
>> >> uses mixed mode security)
>> >>
>> >> Regarding issue 1: I have experienced that restoring
>> over
>> >> an existing database causes the file locations to be
>> >> automatically fixed up by the restore, taking the
file
>> >> locations from the database being overwritten rather
>> than
>> >> the locations saved in the backup. Will this work
for
>> >> master/msdb?
>> >>
>> >> I don't know what to expect regarding issue #2.
>> >>
>> >> Any help appreciated! Thanks!
>> >>
>> >
>> >
>> >.
>> >
>
>.
>
min