------=_Part_21320_29303346.1133338888829
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
I would not mess with the production "working" master server. Wiping out
your active catalog on purpose and relying on bprecover to get it back
sounds ... risky. Not that I've ever seen bprecover fail, but I believe in
NOT tempting fate.
Is it possible to have a 'spare' server sitting around, with the same OS an=
d
hostname as the production master, but not registered in your DNS, or not
normally connected to the LAN at all? bprecover your pre-problems catalog t=
o
it and just let it sit there until it's needed. It wouldn't need to be too
powerful. Then if a restore is required, update /etc/hosts on the client (o=
r
the Windows equivelant) to point to your "standby" master server, do the
restore, then undo the /etc/hosts change. I've seen this done with an old
Ultra 5, and even on a VMware guest machine.
Of course, you'd also need a tape drive connected to this "standby" master
if/when you need it for a restore.
But apart from that, why are the imports failing? Bad tapes? If that's the
case, having a good catalog is not necesarily going to help.
Remember, with import you have to complete phase 1 import of all tapes in a
connected set before beginning pase 2.
Good luck,
Dean
On 11/30/05, WEAVER, Simon <simon.weaver AT astrium.eads DOT net> wrote:
>
> Hi everyone
> A week and a bit, I mentioned that all my tapes had expired through no
> fault of my own.
>
> Veritas has not been able to re-produce this and under their guidance,
> carried on running as I am, but having to import tapes BACK into Netbacku=
p!
>
> This is not going well! The majority of imports are failing, and I am
> becoming increasingly concerned about the entire system, and much more
> importantly, the previous backups!
>
> So, thinking about the situation, I wanted to know if this theory is
> possible.
>
> I still have a Catalogue Backup on a tape going back to 16th November 200=
5
> - prior to the problems.
>
> Rather than importing the tapes like I am doing, if I need to do a restor=
e
> from a Tape say that was run in September 05, could I revert the system B=
ACK
> to how it was prior to the problems I experienced. This Catalogue tape is
> currently suspended, and I have told NBU not to use this tape as a Catalo=
gue
> Backup (presently using 1 tape and 1 drive).
>
> Once the restore is done, I could use BPRECOVER to revert the system BACK
> to how it is now (ie: todays date).
>
> I am sure there is going to be a con here (for example, recovering back t=
o
> the 16th will mean the Netbackup Database will now wonder why there are n=
ew
> tapes in the Robot and probably send them to scratch!!
>
> I really am looking for some alternatives options here and open to some
> real help! Veritas have told me its the media thats the problem!
>
> This is not looking good :(
>
>
> *Simon Weaver*
> *Technical Support*
> *Windows Domain Administrator*
>
> *EADS Astrium***
> ***Tel: 02392-708598***
>
> *Email: Simon.Weaver AT Astrium.eads DOT net*
>
> This email is for the intended addressee only.
> If you have received it in error then you must not use, retain,
> disseminate or otherwise deal with it.
> Please notify the sender by return email.
> The views of the author may not necessarily constitute the views of EADS
> Astrium Limited.
> Nothing in this email shall bind EADS Astrium Limited in any contract or
> obligation.
>
> EADS Astrium Limited, Registered in England and Wales No. 2449259
> Registered Office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS,
> England
>
------=_Part_21320_29303346.1133338888829
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
I would not mess with the production "working" master server. Wip=
ing
out your active catalog on purpose and relying on bprecover to get it
back sounds ... risky. Not that I've ever seen bprecover fail, but I
believe in NOT tempting fate. <br>
<br>
Is it possible to have a 'spare' server sitting around, with the same
OS and hostname as the production master, but not registered in your
DNS, or not normally connected to the LAN at all? bprecover your
pre-problems catalog to it and just let it sit there until it's needed.
It wouldn't need to be too powerful. Then if a restore is required,
update /etc/hosts on the client (or the Windows equivelant) to point to
your "standby" master server, do the restore, then undo the /etc/=
hosts
change. I've seen this done with an old Ultra 5, and even on a VMware
guest machine.<br>
<br>
Of course, you'd also need a tape drive connected to this "standby&quo=
t; master if/when you need it for a restore.<br>
<br>
But apart from that, why are the imports failing? Bad tapes? If that's
the case, having a good catalog is not necesarily going to help. <br>
<br>
Remember, with import you have to complete phase 1 import of all tapes in a=
connected set before beginning pase 2.<br>
<br>
Good luck,<br>
Dean<br><br><div><span class=3D"gmail_quote">On 11/30/05, <b class=3D"gmail=
_sendername">WEAVER, Simon</b> <<a href=3D"mailto:[email protected]=
ads.net">simon.weaver AT astrium.eads DOT net</a>> wrote:</span><blockquote
cla=
ss=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 204, 204); marg=
in: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><span><font face=3D"Arial" size=3D"2">Hi=20
everyone</font></span></div>
<div><span><font face=3D"Arial" size=3D"2">A week and a bit, I=20
mentioned that all my tapes had expired through no fault of my=20
own.</font></span></div>
<div><span><font face=3D"Arial" size=3D"2"></font></span> </div>
<div><span><font face=3D"Arial" size=3D"2">Veritas has not been=20
able to re-produce this and under their guidance, carried on running as I a=
m,=20
but having to import tapes BACK into Netbackup!</font></span></div>
<div><span><font face=3D"Arial" size=3D"2"></font></span> </div>
<div><span><font face=3D"Arial" size=3D"2">This is not going=20
well! The majority of imports are failing, and I am becoming increasingly=
=20
concerned about the entire system, and much more importantly, the previous=
=20
backups!</font></span></div>
<div><span><font face=3D"Arial" size=3D"2"></font></span> </div>
<div><span><font face=3D"Arial" size=3D"2">So, thinking about=20
the situation, I wanted to know if this theory is possible.</font></span></=
div>
<div><span><font face=3D"Arial" size=3D"2"></font></span> </div>
<div><span><font face=3D"Arial" size=3D"2">I still have a=20
Catalogue Backup on a tape going back to 16th November 2005 - prior to the=
=20
problems.</font></span></div>
<div><span><font face=3D"Arial" size=3D"2"></font></span> </div>
<div><span><font face=3D"Arial" size=3D"2">Rather than=20
importing the tapes like I am doing, if I need to do a restore from a Tape =
say=20
that was run in September 05, could I revert the system BACK to how it was =
prior=20
to the problems I experienced. This Catalogue tape is currently suspended, =
and I=20
have told NBU not to use this tape as a Catalogue Backup (presently using 1=
tape=20
and 1 drive).</font></span></div>
<div><span><font face=3D"Arial" size=3D"2"></font></span> </div>
<div><span><font face=3D"Arial" size=3D"2">Once the restore is=20
done, I could use BPRECOVER to revert the system BACK to how it is now (ie:=
=20
todays date).</font></span></div>
<div><span><font face=3D"Arial" size=3D"2"></font></span> </div>
<div><span><font face=3D"Arial" size=3D"2">I am sure there is=20
going to be a con here (for example, recovering back to the 16th will mean =
the=20
Netbackup Database will now wonder why there are new tapes in the Robot and=
=20
probably send them to scratch!!</font></span></div>
<div><span><font face=3D"Arial" size=3D"2"></font></span> </div>
<div><span><font face=3D"Arial" size=3D"2">I really am looking=20
for some alternatives options here and open to some real help! Veritas have=
told=20
me its the media thats the problem!</font></span></div>
<div><span><font face=3D"Arial" size=3D"2"></font></span> </div>
<div><span><font face=3D"Arial" size=3D"2">This is not looking=20
good :(</font></span></div>
<div> </div>
<p><span lang=3D"en-gb"><b><font color=3D"#0000ff" face=3D"Arial" size=3D"2=
">Simon=20
Weaver</font></b><font face=3D"Arial"><br></font><b><font color=3D"#0000ff"=
face=3D"Arial" size=3D"2">Technical Support</font></b><font face=3D"Arial"=
><br></font><b><font color=3D"#0000ff" face=3D"Arial" size=3D"2">Windows Do=
main Administrator
</font></b><font face=3D"Arial"> </font></span></p>
<p><span lang=3D"en-gb"><b><i><font face=3D"Arial" size=3D"2">EADS=20
Astrium</font></i></b><i></i><font face=3D"Arial"><br></font><b></b><b><i><=
font face=3D"Arial" size=3D"2">Tel: 02392-70</font><font face=3D"Arial" siz=
e=3D"2">8598</font></i></b><i></i><font face=3D"Arial"> </font></span></p>
<p><span lang=3D"en-gb"><b><font color=3D"#ff0000" face=3D"Arial" size=3D"2=
">Email:=20
<a href=3D"mailto:Simon.Weaver AT Astrium.eads DOT net" target=3D"_blank"
onclick=
=3D"return top.js.OpenExtLink(window,event,this)">Simon.Weaver AT Astrium DOT
eads=
.net</a></font></b><font face=3D"Arial"> </font></span></p>
<div> </div>
<table><tbody><tr><td bgcolor=3D"#ffffff"><font color=3D"#000000">This emai=
l is for the intended addressee only.<br>
If you have received it in error then you must not use, retain, disseminate=
or otherwise deal with it.<br>
Please notify the sender by return email.<br>
The views of the author may not necessarily constitute the views of EADS As=
trium Limited.<br>
Nothing in this email shall bind EADS Astrium Limited in any contract or ob=
ligation.<br>
<br>
EADS Astrium Limited, Registered in England and Wales No. 2449259<br>
Registered Office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, En=
gland<br>
</font></td></tr></tbody></table>
</blockquote></div><br>
------=_Part_21320_29303346.1133338888829--
|
