This is a MIME message. If you are reading this text, you may want to
consider changing to a mail reader or gateway that understands how to
properly handle MIME multipart messages.
--=__PartF1D02C55.2__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
With another twist you could ....
Use a Quantum DX100 enabled in Tape Library Emulation mode and use
Vault to "copy" from the DX virtual tapes to actual tape media.
Scott J.
>>> Matt Beal <matt.beal AT lightsurf DOT com> 4/28/2004 2:10:21 PM >>>
You have a point about losing a library - this method was set up
rather
quickly when we realized our incrementals were only going about 50
KB/s
and were going to trash our tape drives if we didn't do something.
It turns out that bpimmedia doesn't help me too much - at the same
time,
my comment about a source storage unit in bpduplicate was premature
anyway. I need the various incrementals to go to different volume
pools,
so I have to do them in separate batches.
I think what I need to do is follow the duplication(s) with the
listing
of bpimmedia, looking up each backup id, and expiring the ones that
have
a copy already on the destination (tape) storage unit. Then I could
increase the retention of the disk-based backups to a week or two for
additional safety.
matt
On Wed, 2004-04-28 at 11:12, Mark.Donaldson AT cexp DOT com wrote:
> Use bpimmedia to query the image IDs on the disk STU, sort by
timestamp
> (numeric part after the underscore), break the list into segments and
use
> bpduplicate with the -bidfile option to duplicate the sets of backup
id's.
>
> You can then feed the backup id list into bpexpdate to expire the
on-disk
> copy and it won't duplicate again (or check with bpimagelist to see
how many
> copies you have before duplication and cull out any with enough
copies
> already).
>
> There's a hazard in your method if you lose your library for a couple
of
> days - If you can't duplicate it 72 hours, you're not going to get it
on
> tape.
>
> $.02
>
> -M
>
> -----Original Message-----
> From: Matt Beal [mailto:matt.beal AT lightsurf DOT com]
> Sent: Wednesday, April 28, 2004 11:37 AM
> To: Mark.Donaldson AT cexp DOT com
> Cc: jrmajor AT TexasChildrensHospital DOT org; Thomas.Tschida AT udlp DOT com;
> veritas-bu AT mailman.eng.auburn DOT edu
> Subject: RE: [Veritas-bu] SSO with disk?
>
>
> You can do this more or less automatically. My incrementals run too
> slowly to go to tape, so I write them to a disk storage unit first,
with
> a retention of 3 days. I then run (as a daily cron job):
>
> /usr/openv/netbackup/bin/admincmd/bpduplicate \
> -dstunit bkp-master01-hcart2-robot-tld-0 -policy <policy> \
> -st INCR -dp <pool> -set_primary 1 -rl 3 -hoursago 72
>
> This sets the tape copy as the primary for restores, and sets a new
> retention of 30 days.
>
> You have to be sure your global max backup copies is set to a low
value
> (i.e. 2) or else subsequent bpduplicates will make more copies.
>
> This is not perfect, however. I have to have multiple bpduplicate
lines
> in the script, since I only want to duplicate the incrementals for
the
> policies that were written to disk first. I wish bpduplicate
supported a
> flag to duplicate any images on a given storage unit, but alas ...
>
> matt
>
> On Wed, 2004-04-28 at 08:11, Mark.Donaldson AT cexp DOT com wrote:
> > You can duplicate the image on disk to tape, then expire the disk
copy -
> the
> > image DB tracks everything just fine. No, it's not automatic like
the
> disk
> > staging in v5.0 but it works well.
> >
> > -M
> >
> > -----Original Message-----
> > From: veritas-bu-admin AT mailman.eng.auburn DOT edu
> > [mailto:veritas-bu-admin AT mailman.eng.auburn DOT edu]On Behalf Of
Major,
> > Rusty
> > Sent: Wednesday, April 28, 2004 8:49 AM
> > To: Thomas Tschida; veritas-bu AT mailman.eng.auburn DOT edu
> > Subject: RE: [Veritas-bu] SSO with disk?
> >
> >
> > From my understanding, 4.5 doesn't support true disk-disk-tape.
Sure, you
> > could backup to a disk STU, then backup these images to tape
without a
> > problem. But 4.5 doesn't have a way to relate the meta file info
between
> the
> > backups to disk and the backup to tapes.
> > What I'm trying to say is that your restore process will now be two
steps:
> > find the image backed up from disk STU, restore it, then find the
file and
> > restore it. It might even involve importing and other trickery to
get it
> to
> > work how you want.
> >
> > 5.0 is supposed to support this technology, but that's about all I
know of
> > it. Besides that, 5.0, according to the list, is not really a good
> solution
> > at this point.
> >
> > If you're really interested in doing d-d-t right now, check out
ADIC's
> > Pathlight VX, or other similar products.
> >
> > Rusty
> >
> > > -----Original Message-----
> > > From: Gary Andresen [mailto:gary.andresen AT pnwdata DOT com]
> > > Sent: Tuesday, April 27, 2004 6:34 PM
> > > To: 'Thomas Tschida'; veritas-bu AT mailman.eng.auburn DOT edu
> > > Subject: RE: [Veritas-bu] SSO with disk?
> > >
> > >
> > > Short answer no.
> > >
> > > Disk storage units are disk storage (with a file system)
> > > directly attached
> > > to a media server (granted the disks could be on a SAN) and
> > > would not be
> > > shared. To keep your dup traffic off the net you would want
> > > to make sure
> > > the disk STU and the tape are on the same media server.
> > >
> > > Potentially you could use CFS from VERITAS where the media
> > > servers used a
> > > cluster file system between them. However making the CFS
> > > cluster with the
> > > media servers involved could be a somewhat interesting
configuration
> > > challenge :--).
> > >
> > > Gary Andresen
> > > Impossible Happens, Plan Ahead
> > > Pacific Northwest Data Inc.
> > > Tel: 503.701.5185
> > > Fax: 503.692.3910
> > > gary.andresen AT pnwdata DOT com
> > > www.pnwdata.com
> > >
> > > > -----Original Message-----
> > > > From: veritas-bu-admin AT mailman.eng.auburn DOT edu
[mailto:veritas-bu-
> > > > admin AT mailman.eng.auburn DOT edu] On Behalf Of Thomas Tschida
> > > > Sent: Tuesday, April 27, 2004 1:51 PM
> > > > To: veritas-bu AT mailman.eng.auburn DOT edu
> > > > Subject: [Veritas-bu] SSO with disk?
> > > >
> > > > Hello all,
> > > >
> > > > we are looking at migrating to Disk-Disk-Tape. We will likely
run
> > > > primary backups to disk, and then duplicate to tape. We
> > > have a library
> > > > with 12 drives and SSO for all drives. Does anyone know if
> > > disk based
> > > > storage units can take advantage of SSO, or should we keep the
SSO
> > > > licenses associated with the tape drives so the media
> > > servers can take
> > > > advantage when running duplicates?
> > > >
> > > > Any recommendations or info is appreciated.
> > > >
> > > > Tom Tschida
> > > > United Defense
> > > >
> > > >
> > > > _______________________________________________
> > > > Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> > > > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> > >
> > >
> > > _______________________________________________
> > > Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> > > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> > >
> >
> > _______________________________________________
> > Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> > _______________________________________________
> > Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
--=__PartF1D02C55.2__=
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1"=
>
<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR></HEAD>
<BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Tahoma">
<DIV>With another twist you could ....</DIV>
<DIV> </DIV>
<DIV>Use a Quantum DX100 enabled in Tape Library Emulation mode =
and use Vault to "copy" from the DX virtual tapes to actual tape media.</DI=
V>
<DIV> </DIV>
<DIV>Scott J.</DIV>
<DIV><BR><BR>>>> Matt Beal <matt.beal AT lightsurf DOT com> =
4/28/2004 2:10:21 PM >>><BR></DIV>
<DIV style=3D"COLOR: #000000">You have a point about losing a library - =
this method was set up rather<BR>quickly when we realized our incrementals =
were only going about 50 KB/s<BR>and were going to trash our tape drives =
if we didn't do something.<BR><BR>It turns out that bpimmedia doesn't help =
me too much - at the same time,<BR>my comment about a source storage unit =
in bpduplicate was premature<BR>anyway. I need the various incrementals to =
go to different volume pools,<BR>so I have to do them in separate =
batches.<BR><BR>I think what I need to do is follow the duplication(s) =
with the listing<BR>of bpimmedia, looking up each backup id, and expiring =
the ones that have<BR>a copy already on the destination (tape) storage =
unit. Then I could<BR>increase the retention of the disk-based backups to =
a week or two for<BR>additional safety.<BR><BR>matt<BR><BR>On Wed, =
2004-04-28 at 11:12, Mark.Donaldson AT cexp DOT com wrote:<BR>> Use
bpimmedia =
to query the image IDs on the disk STU, sort by timestamp<BR>> (numeric =
part after the underscore), break the list into segments and use<BR>> =
bpduplicate with the -bidfile option to duplicate the sets of backup =
id's.<BR>> <BR>> You can then feed the backup id list into bpexpdate =
to expire the on-disk<BR>> copy and it won't duplicate again (or check =
with bpimagelist to see how many<BR>> copies you have before duplication=
and cull out any with enough copies<BR>> already).<BR>> <BR>> =
There's a hazard in your method if you lose your library for a couple =
of<BR>> days - If you can't duplicate it 72 hours, you're not going to =
get it on<BR>> tape.<BR>> <BR>> $.02<BR>> <BR>> -M<BR>> =
<BR>> -----Original Message-----<BR>> From: Matt Beal [<A href=3D"mai=
lto:matt.beal AT lightsurf DOT com]">mailto:matt.beal AT lightsurf DOT
com]</A><BR>> =
Sent: Wednesday, April 28, 2004 11:37 AM<BR>> To: Mark.Donaldson AT cexp DOT
co=
m<BR>> Cc: jrmajor AT TexasChildrensHospital DOT org; Thomas.Tschida AT udlp
DOT com;<=
BR>> veritas-bu AT mailman.eng.auburn DOT edu<BR>> Subject: RE:
[Veritas-bu]=
SSO with disk?<BR>> <BR>> <BR>> You can do this more or less =
automatically. My incrementals run too<BR>> slowly to go to tape, so I =
write them to a disk storage unit first, with<BR>> a retention of 3 =
days. I then run (as a daily cron job):<BR>> <BR>> /usr/openv/netback=
up/bin/admincmd/bpduplicate \<BR>> -dstunit bkp-master01-hcart2-robot-tl=
d-0 -policy <policy> \<BR>> -st INCR -dp <pool> -set_primary=
1 -rl 3 -hoursago 72<BR>> <BR>> This sets the tape copy as the =
primary for restores, and sets a new<BR>> retention of 30 days.<BR>> =
<BR>> You have to be sure your global max backup copies is set to a low =
value<BR>> (i.e. 2) or else subsequent bpduplicates will make more =
copies.<BR>> <BR>> This is not perfect, however. I have to have =
multiple bpduplicate lines<BR>> in the script, since I only want to =
duplicate the incrementals for the<BR>> policies that were written to =
disk first. I wish bpduplicate supported a<BR>> flag to duplicate any =
images on a given storage unit, but alas ...<BR>> <BR>> matt<BR>> =
<BR>> On Wed, 2004-04-28 at 08:11, Mark.Donaldson AT cexp DOT com
wrote:<BR>>=
; > You can duplicate the image on disk to tape, then expire the disk =
copy -<BR>> the<BR>> > image DB tracks everything just fine. =
No, it's not automatic like the<BR>> disk<BR>> > staging in v5.0 =
but it works well.<BR>> > <BR>> > -M<BR>> > <BR>> =
> -----Original Message-----<BR>> > From: veritas-bu-admin@mailman=
.eng.auburn.edu<BR>> > [<A href=3D"mailto:veritas-bu-admin AT mailman DOT
en=
g.auburn.edu]On">mailto:veritas-bu-admin AT mailman.eng.auburn DOT edu]On</A> =
Behalf Of Major,<BR>> > Rusty<BR>> > Sent: Wednesday, April =
28, 2004 8:49 AM<BR>> > To: Thomas Tschida; veritas-bu AT mailman.eng DOT
au=
burn.edu<BR>> > Subject: RE: [Veritas-bu] SSO with disk?<BR>> =
> <BR>> > <BR>> > From my understanding, 4.5 doesn't =
support true disk-disk-tape. Sure, you<BR>> > could backup to a disk =
STU, then backup these images to tape without a<BR>> > problem. But =
4.5 doesn't have a way to relate the meta file info between<BR>> =
the<BR>> > backups to disk and the backup to tapes.<BR>> > =
What I'm trying to say is that your restore process will now be two =
steps:<BR>> > find the image backed up from disk STU, restore it, =
then find the file and<BR>> > restore it. It might even involve =
importing and other trickery to get it<BR>> to<BR>> > work how =
you want.<BR>> > <BR>> > 5.0 is supposed to support this =
technology, but that's about all I know of<BR>> > it. Besides that, =
5.0, according to the list, is not really a good<BR>> solution<BR>> =
> at this point.<BR>> > <BR>> > If you're really interested =
in doing d-d-t right now, check out ADIC's<BR>> > Pathlight VX, or =
other similar products.<BR>> > <BR>> > Rusty<BR>> > =
<BR>> > > -----Original Message-----<BR>> > > From: Gary =
Andresen [<A href=3D"mailto:gary.andresen AT pnwdata DOT
com]">mailto:gary.andrese=
n AT pnwdata DOT com]</A><BR>> > > Sent: Tuesday, April 27, 2004 6:34 =
PM<BR>> > > To: 'Thomas Tschida'; veritas-bu AT mailman.eng.auburn DOT
ed=
u<BR>> > > Subject: RE: [Veritas-bu] SSO with disk?<BR>> > =
> <BR>> > > <BR>> > > Short answer no.<BR>> > =
> <BR>> > > Disk storage units are disk storage (with a file =
system) <BR>> > > directly attached<BR>> > > to a media =
server (granted the disks could be on a SAN) and <BR>> > > would =
not be<BR>> > > shared. To keep your dup traffic off the net you =
would want <BR>> > > to make sure<BR>> > > the disk STU =
and the tape are on the same media server.<BR>> > > <BR>> > =
> Potentially you could use CFS from VERITAS where the media <BR>> =
> > servers used a<BR>> > > cluster file system between =
them. However making the CFS <BR>> > > cluster with the<BR>> =
> > media servers involved could be a somewhat interesting configurat=
ion<BR>> > > challenge :--).<BR>> > > <BR>> > > =
Gary Andresen <BR>> > > Impossible Happens, Plan Ahead <BR>> =
> > Pacific Northwest Data Inc. <BR>> > > Tel: 503.701.5185 =
<BR>> > > Fax: 503.692.3910 <BR>> > > gary.andresen@pnwda=
ta.com <BR>> > > <A href=3D"http://www.pnwdata.com";>www.pnwdata.co=
m</A><BR>> > > <BR>> > > > -----Original Message-----<=
BR>> > > > From: veritas-bu-admin AT mailman.eng.auburn DOT edu [<A
=
href=3D"mailto:veritas-bu-";>mailto:veritas-bu-</A><BR>> > > > =
admin AT mailman.eng.auburn DOT edu] On Behalf Of Thomas Tschida<BR>> > =
> > Sent: Tuesday, April 27, 2004 1:51 PM<BR>> > > > To: =
veritas-bu AT mailman.eng.auburn DOT edu<BR>> > > > Subject: =
[Veritas-bu] SSO with disk?<BR>> > > > <BR>> > > > =
Hello all,<BR>> > > > <BR>> > > > we are looking =
at migrating to Disk-Disk-Tape. We will likely run<BR>> > > =
> primary backups to disk, and then duplicate to tape. We =
<BR>> > > have a library<BR>> > > > with 12 drives =
and SSO for all drives. Does anyone know if <BR>> > > disk =
based<BR>> > > > storage units can take advantage of SSO, or =
should we keep the SSO<BR>> > > > licenses associated with the =
tape drives so the media <BR>> > > servers can take<BR>> > =
> > advantage when running duplicates?<BR>> > > > =
<BR>> > > > Any recommendations or info is appreciated.<BR>>=
> > > <BR>> > > > Tom Tschida<BR>> > > > =
United Defense<BR>> > > > <BR>> > > > <BR>> =
> > > _______________________________________________<BR>> =
> > > Veritas-bu maillist - Veritas-bu AT mailman.eng DOT
aub=
urn.edu<BR>> > > > <A href=3D"http://mailman.eng.auburn.edu/mai=
lman/listinfo/veritas-bu">http://mailman.eng.auburn.edu/mailman/listinfo/ve=
ritas-bu</A><BR>> > > <BR>> > > <BR>> > > =
_______________________________________________<BR>> > > =
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT
edu<BR>>=
> > <A href=3D"http://mailman.eng.auburn.edu/mailman/listinfo/verita=
s-bu">http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu</A><BR>>=
> > <BR>> > <BR>> > ____________________________________=
___________<BR>> > Veritas-bu maillist - Veritas-bu@mailm=
an.eng.auburn.edu<BR>> > <A href=3D"http://mailman.eng.auburn.edu/mai=
lman/listinfo/veritas-bu">http://mailman.eng.auburn.edu/mailman/listinfo/ve=
ritas-bu</A><BR>> > _______________________________________________<B=
R>> > Veritas-bu maillist - Veritas-bu AT mailman DOT
eng.auburn=
.edu<BR>> > <A href=3D"http://mailman.eng.auburn.edu/mailman/listinfo=
/veritas-bu">http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu</A><=
BR>_______________________________________________<BR>Veritas-bu maillist&n=
bsp; - Veritas-bu AT mailman.eng.auburn DOT edu<BR><A
href=3D"http://mailman=
.eng.auburn.edu/mailman/listinfo/veritas-bu">http://mailman.eng.auburn.edu/=
mailman/listinfo/veritas-bu</A><BR></DIV></BODY></HTML>
--=__PartF1D02C55.2__=--
|
