Veritas-bu

[Veritas-bu] Relocating data on volumes.

2002-12-03 19:52:15
Subject: [Veritas-bu] Relocating data on volumes.
From: Mark.Donaldson AT experianems DOT com (Donaldson, Mark)
Date: Tue, 3 Dec 2002 17:52:15 -0700
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C29B2F.6378BB20
Content-Type: text/plain

You've pretty much got it there.  One nice thing about v4.5 of NB is it
allows something like 10 copies of an image - simplifying this some.  If you
can make your intermediate duplication to a disk then you can not worry the
pool stuff (no pools for disks) and the duplications don't tie up as many
drives.  

Yes, I agree, one nice thing about ADSM was the consolidation stuff.

-M

-----Original Message-----
From: Brian Chase [mailto:vaxzilla AT jarai DOT org]
Sent: Tuesday, December 03, 2002 5:31 PM
To: Veritas Backup
Subject: Re: [Veritas-bu] Relocating data on volumes.


On Tue, 3 Dec 2002, Brian Chase wrote:

> I've a tape that contains images with an infinite retention period; it
> has been placed in a FROZEN state due to a media write error.  The tape
> seems to read fine, but I'd like to get the good images off of it and
> onto another tape.  Is there a convenient way to move the images from
> the bad volume onto another good volume in the same volume pool?

Oh goodness, what a load of $%!* it is to do this under NetBackup.
It seems to be possible using the bpduplicate and bpexpdate commands,
but it looks like one has to be very careful as there are a number of
pitfalls.

For one, which I found as a rather unpleasant surprise, NetBackup only
allows for only a single duplicate[1].  So, in the case above, if I've
got an offsite duplicate of images on my FROZEN tape, I can't make
another duplicate of those images as a "first step" of moving the data
off the frozen tape without deleting the references to the offsite copy.

Secondly, if you specify the destination volume pool to be the same as
the one in which the source volume resides, you risk throwing NetBackup
into a deadlock state in the case that it attempts to move data from the
source tape onto itself[2].  I don't think this is possible if the
source tape is in the FROZEN state, but I still find it ridiculous that
the software developers at VERITAS allowed such a trivially avoidable
deadlock to exist (especialy since they've bothered to document it!)

Thirdly, although bpduplicate does allow you to duplicate a whole tape,
there's the possibility that it will be duplicated to tape with
unrelated images on it, and possibly it will be split across more than
one tape.  Which, for the process of duplication in general, is not at
all a problem.  It does muck things up if you need to move a volume's
data to a temporary pool and then back.  As a result, you have to track
the individual backup images to make this work.

So, as best as I can determine, given that you want to move the data
off volume "001234" in volume pool "POOL_A" onto some other volume(s)
also in "POOL_A", the steps required are something along the lines of
the following:

   1. Generate a list of backup images on volume 001234.
   2. Duplicate these images to a temporary volume pool.
   3. Mark the duplicated images as the primary copy.
   4. Delete (expire) the backup images from the bad volume.
   5. Remove the bad tape from POOL_A.
   6. Duplicate the backup images from the temporary volume pool to POOL_A.
   7. Mark the duplicated images in POOL_A as the primary copy.
   8. Delete the backup images from the temporary volume pool.

GAH!!!!!

Also, the above won't work for any of the images for which there exists
an offsite copy of the image.  In that case you're probably better off
just recalling the offsite tape(s) and duplicating from that data.
Unfortunately, that causes me to pay a retrieval fee to our offsite
facility. Otherwise, you'll have to expire the offsite images before you
can do the above duplication fandango.  Doing that would be a bad idea.

God forbid I ever say anything nice about Tivoli's TSM, but at least
with it, the above operation only requires you to type in the command
"MOVE DATA 001234" to the administrative client.  It did all the other
necessary housekeeping for you.

-brian.

[1] VERITAS NetBackup DataCenter 3.4 Systems Administrator's Guide: UNIX,
    p.436.
[2] VERITAS NetBackup DataCenter 3.4 Systems Administrator's Guide: UNIX,
    p.438, the -dp option description.


_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

------_=_NextPart_001_01C29B2F.6378BB20
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [Veritas-bu] Relocating data on volumes.</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>You've pretty much got it there.&nbsp; One nice thing =
about v4.5 of NB is it allows something like 10 copies of an image - =
simplifying this some.&nbsp; If you can make your intermediate =
duplication to a disk then you can not worry the pool stuff (no pools =
for disks) and the duplications don't tie up as many drives.&nbsp; =
</FONT></P>

<P><FONT SIZE=3D2>Yes, I agree, one nice thing about ADSM was the =
consolidation stuff.</FONT>
</P>

<P><FONT SIZE=3D2>-M</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Brian Chase [<A =
HREF=3D"mailto:vaxzilla AT jarai DOT org">mailto:vaxzilla AT jarai DOT 
org</A>]</FONT>=

<BR><FONT SIZE=3D2>Sent: Tuesday, December 03, 2002 5:31 PM</FONT>
<BR><FONT SIZE=3D2>To: Veritas Backup</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [Veritas-bu] Relocating data on =
volumes.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>On Tue, 3 Dec 2002, Brian Chase wrote:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; I've a tape that contains images with an =
infinite retention period; it</FONT>
<BR><FONT SIZE=3D2>&gt; has been placed in a FROZEN state due to a =
media write error.&nbsp; The tape</FONT>
<BR><FONT SIZE=3D2>&gt; seems to read fine, but I'd like to get the =
good images off of it and</FONT>
<BR><FONT SIZE=3D2>&gt; onto another tape.&nbsp; Is there a convenient =
way to move the images from</FONT>
<BR><FONT SIZE=3D2>&gt; the bad volume onto another good volume in the =
same volume pool?</FONT>
</P>

<P><FONT SIZE=3D2>Oh goodness, what a load of $%!* it is to do this =
under NetBackup.</FONT>
<BR><FONT SIZE=3D2>It seems to be possible using the bpduplicate and =
bpexpdate commands,</FONT>
<BR><FONT SIZE=3D2>but it looks like one has to be very careful as =
there are a number of</FONT>
<BR><FONT SIZE=3D2>pitfalls.</FONT>
</P>

<P><FONT SIZE=3D2>For one, which I found as a rather unpleasant =
surprise, NetBackup only</FONT>
<BR><FONT SIZE=3D2>allows for only a single duplicate[1].&nbsp; So, in =
the case above, if I've</FONT>
<BR><FONT SIZE=3D2>got an offsite duplicate of images on my FROZEN =
tape, I can't make</FONT>
<BR><FONT SIZE=3D2>another duplicate of those images as a &quot;first =
step&quot; of moving the data</FONT>
<BR><FONT SIZE=3D2>off the frozen tape without deleting the references =
to the offsite copy.</FONT>
</P>

<P><FONT SIZE=3D2>Secondly, if you specify the destination volume pool =
to be the same as</FONT>
<BR><FONT SIZE=3D2>the one in which the source volume resides, you risk =
throwing NetBackup</FONT>
<BR><FONT SIZE=3D2>into a deadlock state in the case that it attempts =
to move data from the</FONT>
<BR><FONT SIZE=3D2>source tape onto itself[2].&nbsp; I don't think this =
is possible if the</FONT>
<BR><FONT SIZE=3D2>source tape is in the FROZEN state, but I still find =
it ridiculous that</FONT>
<BR><FONT SIZE=3D2>the software developers at VERITAS allowed such a =
trivially avoidable</FONT>
<BR><FONT SIZE=3D2>deadlock to exist (especialy since they've bothered =
to document it!)</FONT>
</P>

<P><FONT SIZE=3D2>Thirdly, although bpduplicate does allow you to =
duplicate a whole tape,</FONT>
<BR><FONT SIZE=3D2>there's the possibility that it will be duplicated =
to tape with</FONT>
<BR><FONT SIZE=3D2>unrelated images on it, and possibly it will be =
split across more than</FONT>
<BR><FONT SIZE=3D2>one tape.&nbsp; Which, for the process of =
duplication in general, is not at</FONT>
<BR><FONT SIZE=3D2>all a problem.&nbsp; It does muck things up if you =
need to move a volume's</FONT>
<BR><FONT SIZE=3D2>data to a temporary pool and then back.&nbsp; As a =
result, you have to track</FONT>
<BR><FONT SIZE=3D2>the individual backup images to make this work.</FONT=
>
</P>

<P><FONT SIZE=3D2>So, as best as I can determine, given that you want =
to move the data</FONT>
<BR><FONT SIZE=3D2>off volume &quot;001234&quot; in volume pool =
&quot;POOL_A&quot; onto some other volume(s)</FONT>
<BR><FONT SIZE=3D2>also in &quot;POOL_A&quot;, the steps required are =
something along the lines of</FONT>
<BR><FONT SIZE=3D2>the following:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; 1. Generate a list of backup images on =
volume 001234.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; 2. Duplicate these images to a =
temporary volume pool.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; 3. Mark the duplicated images as the =
primary copy.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; 4. Delete (expire) the backup images =
from the bad volume.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; 5. Remove the bad tape from =
POOL_A.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; 6. Duplicate the backup images from the =
temporary volume pool to POOL_A.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; 7. Mark the duplicated images in POOL_A =
as the primary copy.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; 8. Delete the backup images from the =
temporary volume pool.</FONT>
</P>

<P><FONT SIZE=3D2>GAH!!!!!</FONT>
</P>

<P><FONT SIZE=3D2>Also, the above won't work for any of the images for =
which there exists</FONT>
<BR><FONT SIZE=3D2>an offsite copy of the image.&nbsp; In that case =
you're probably better off</FONT>
<BR><FONT SIZE=3D2>just recalling the offsite tape(s) and duplicating =
from that data.</FONT>
<BR><FONT SIZE=3D2>Unfortunately, that causes me to pay a retrieval fee =
to our offsite</FONT>
<BR><FONT SIZE=3D2>facility. Otherwise, you'll have to expire the =
offsite images before you</FONT>
<BR><FONT SIZE=3D2>can do the above duplication fandango.&nbsp; Doing =
that would be a bad idea.</FONT>
</P>

<P><FONT SIZE=3D2>God forbid I ever say anything nice about Tivoli's =
TSM, but at least</FONT>
<BR><FONT SIZE=3D2>with it, the above operation only requires you to =
type in the command</FONT>
<BR><FONT SIZE=3D2>&quot;MOVE DATA 001234&quot; to the administrative =
client.&nbsp; It did all the other</FONT>
<BR><FONT SIZE=3D2>necessary housekeeping for you.</FONT>
</P>

<P><FONT SIZE=3D2>-brian.</FONT>
</P>

<P><FONT SIZE=3D2>[1] VERITAS NetBackup DataCenter 3.4 Systems =
Administrator's Guide: UNIX,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; p.436.</FONT>
<BR><FONT SIZE=3D2>[2] VERITAS NetBackup DataCenter 3.4 Systems =
Administrator's Guide: UNIX,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; p.438, the -dp option =
description.</FONT>
</P>
<BR>

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>Veritas-bu maillist&nbsp; -&nbsp; =
Veritas-bu AT mailman.eng.auburn DOT edu</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu"; =
TARGET=3D"_blank">http://mailman.eng.auburn.edu/mailman/listinfo/veritas=
-bu</A></FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C29B2F.6378BB20--

<Prev in Thread] Current Thread [Next in Thread>