------=_Part_5501_20605670.1141855267399
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
I agree.
We have been using bparchive for over 2 years now. We have over 30TB on
archive tapes. Since version 5.x we have been using the ITC feature to
archive to 2 sets of tapes, one of which is sent off-site. It has worked
well for us so far. Earlier with bpduplicate, the whole archive process use=
d
to take about 2 to 3x the time it takes now with ITC. The policy is set suc=
h
that if writing to one copy fails it fails the complete archive.
We randomly restore from different archive sets every quarter just to make
sure we have good archive. We normally run a full just before the archive
with 1 year retention just to be safe. The technote mentioned is a non-issu=
e
for us because we archive from a "nearline" server that holds inactive data=
,
that's shared out as read-only to the users. Its part of our ILM strategy,
Online->Nearline->Archive->Expire. Data not accessed in 6 months moves from
Online storage to Nearline where it stays read-only for another 6 months. I=
t
then gets archived to tapes and gets expired after 7 years. Its not an
automated process, like HSM, but something we setup internally. Has been
working well for us, though it involves a lot of documentation, home grown
scripts and other so called ILM tools. Still looking for a packaged solutio=
n
that does it all.
We did run into a major issue in 2004. It is to do with the feature called
"Checkpoint restart" that was introduced in NBU 5. If your client is a
windows server and your master/media server is Solaris and if you use
checkpoint restart for your user-archive policy, after a SUCCESSFUL archive
(i.e successful backup and files deleted) NBU fails to save the backup
image! We had to import the tapes to recreate the image. What a pain. Even
though they claim its fixed in their latest MPx release, we still do not us=
e
checkpoint restarts for any of our archvie jobs.
Refer this technote for details
http://seer.support.veritas.com/docs/272853.htm
-G
On 3/8/06, Mark.Donaldson AT cexp DOT com <Mark.Donaldson AT cexp DOT com>
wrote:
>
> I think you're overworrying this.
>
> bparchive, a misnomer, IMO, is just bpbackup with a twist.
>
> If, and only if, the backup to tape is successful then the primary file i=
s
> deleted. I've never fed it a directory, just files, so I've never
> stumbled
> on this little behavior described in the tech bulletin. We use this
> command
> constantly, to keep filesystems clean. It's a little like poor-man's HSM=
.
>
> For our most critical data, the stuff the SEC cares about, we do a double
> backup, first feeding the list of files to be backed up to bpbackup, then=
,
> if the return code is 0, feeding the same list to bparchive using a
> different tape pool. We could probably use ITC for this but when we
> started
> the process it wasn't available. I've never tested the bparchive & ITC
> interaction.
>
> Netbackup happily expiring your archive is what I'd expect. When you
> specify policy & schedule on your bparchive command you're selecting this
> behavior. Our SEC stuff writes to an 8-year retention. If you don't wan=
t
> to expire your data, then feed it to a policy/sched that has infinite
> retention.
>
> My only complaint about bparchive (other than the name is misleading) is
> that to restore or list the archived files (bprestore & bplist), you have
> to
> specify the "-A" flag. Why treat the restores any differently, I've
> always
> wondered.
>
> Anyway, my $.02.
>
> -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 Wayne T
> Smith
> Sent: Wednesday, March 08, 2006 9:04 AM
> To: veritas-bu AT mailman.eng.auburn DOT edu
> Subject: Re: [Veritas-bu] bparchive
>
>
> NetBackup "archive" has always been a pet-peeve of mine. Most people, I
> think, have images of the Smithsonian or Louvre when they think of the
> word "archive" and get a warm, fuzzy feeling about keeping important
> things, forever, in an archive. But NetBackup archive just gives me a
> chill! Allow me to explain, please ...
>
> Right now, you have your data, and it is backed up, with probably
> multiple copies in your backup/restore system(s). When you use
> NetBackup "archive", NetBackup makes a copy of the files and ERASES your
> primary copy. NetBackup now has the primary copy of your data, and it
> is a completely untested copy -- maybe you can restore it, maybe you
> can't. Now, unless and until you make copies of your archived data,
> you have no backups. Data with no backup is data that you can afford to
> lose. Oh yes, ... and NetBackup will happily expire your archive.
> Maybe that's good ... maybe not. Finally, there is no connection
> between your original system and data and the data in NetBackup, except
> the rather independent NetBackup catalog and any manual records you
> might make. Those NetBackup catalog entries are based on the machine
> that last held the data, not the application that might find the data
> important.
>
> To answer your questions. (1) bparchive is probably as safe as your
> backups, except you've probably been using your backup policies for a
> while and your archiving appears new, and (2), as should be quite clear
> by now, I have no use for bparchive.
>
> However, the tech note you quote is only important if a directory you
> archive is changing during the archive process ... something that would
> appear intrinsically dangerous for backup or bparchive.
>
> Hope this helps!
>
> cheers, wayne
>
> Shyam Hazari wrote, in part, on 3/8/2006 8:45 AM:
> > I am planning to archive some of the old files on my unix servers(
> > user related files). I already generated the file list and kept it in
> > a file. My intention is to backup first(bpbackup), next use bparchive
> > to archive the files. But after reading the following technote, I am
> > little concerned. Now the questions is, How safe is bparchive ? Anyone
> > used bparchive recently ?
> >
> > This is the technote I was referring to. The technote talks about
> > archiving directories, but in my case I am arching individual files.
> >
> > http://seer.support.veritas.com/docs/281323.htm
> _______________________________________________
> 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
>
------=_Part_5501_20605670.1141855267399
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
I agree. <br>We have been using bparchive for over 2 years now. We have ove=
r 30TB on archive tapes. Since version 5.x we have been using the ITC=
feature to archive to 2 sets of tapes, one of which is sent off-site. It h=
as worked well for us so far. Earlier with bpduplicate, the whole archive p=
rocess used to take about 2 to 3x the time it takes now with ITC. The polic=
y is set such that if writing to one copy fails it fails the complete archi=
ve.=20
<br>We randomly restore from different archive sets every quarter just to m=
ake sure we have good archive. We normally run a full just before the=
archive with 1 year retention just to be safe. The technote mentioned is a=
non-issue for us because we archive from a "nearline" server tha=
t holds inactive data, that's shared out as read-only to the users. Its par=
t of our ILM strategy, Online->Nearline->Archive->Expire. Data not=
accessed in 6 months moves from Online storage to Nearline where it stays =
read-only for another 6 months. It then gets archived to tapes and gets exp=
ired after 7 years. Its not an automated process, like HSM, but something w=
e setup internally. Has been working well for us, though it involves a lot =
of documentation, home grown scripts and other so called ILM tools. Still l=
ooking for a packaged solution that does it all.=20
<br><br>We did run into a major issue in 2004. It is to do with the feature=
called "Checkpoint restart" that was introduced in NBU 5. If you=
r client is a windows server and your master/media server is Solaris and if=
you use checkpoint restart for your user-archive policy, after a SUCCESSFU=
L archive (
i.e successful backup and files deleted) NBU fails to save the backup image=
! We had to import the tapes to recreate the image. What a pain. Even thoug=
h they claim its fixed in their latest MPx release, we still do not use che=
ckpoint restarts for any of our archvie jobs.=20
<br>Refer this technote for details <a href=3D"http://seer.support.veritas.=
com/docs/272853.htm">http://seer.support.veritas.com/docs/272853.htm</a> <b=
r><br>-G<br><br><div><span class=3D"gmail_quote">On 3/8/06, <b class=3D"gma=
il_sendername">
<a href=3D"mailto:Mark.Donaldson AT cexp DOT com">Mark.Donaldson AT cexp DOT
com</a></b> =
<<a href=3D"mailto:Mark.Donaldson AT cexp DOT com">Mark.Donaldson AT cexp
DOT com</a>&=
gt; wrote:</span><blockquote class=3D"gmail_quote" style=3D"border-left: 1p=
x solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I think you're overworrying this.<br><br>bparchive, a misnomer, IMO, is jus=
t bpbackup with a twist.<br><br>If, and only if, the backup to tape is succ=
essful then the primary file is<br>deleted. I've never fed it a =
directory, just files, so I've never stumbled
<br>on this little behavior described in the tech bulletin. We u=
se this command<br>constantly, to keep filesystems clean. It's a=
little like poor-man's HSM.<br><br>For our most critical data, the stuff t=
he SEC cares about, we do a double
<br>backup, first feeding the list of files to be backed up to bpbackup, th=
en,<br>if the return code is 0, feeding the same list to bparchive using a<=
br>different tape pool. We could probably use ITC for this but w=
hen we started
<br>the process it wasn't available. I've never tested the bparchive & =
ITC<br>interaction.<br><br>Netbackup happily expiring your archive is what =
I'd expect. When you<br>specify policy & schedule on your bp=
archive command you're selecting this
<br>behavior. Our SEC stuff writes to an 8-year retention. =
If you don't want<br>to expire your data, then feed it to a policy/sc=
hed that has infinite<br>retention.<br><br>My only complaint about bparchiv=
e (other than the name is misleading) is
<br>that to restore or list the archived files (bprestore & bplist), yo=
u have to<br>specify the "-A" flag. Why treat the rest=
ores any differently, I've always<br>wondered.<br><br>Anyway, my $.02.<br><=
br>-M<br>
<br>-----Original Message-----<br>From: <a href=3D"mailto:veritas-bu-admin@=
mailman.eng.auburn.edu">veritas-bu-admin AT mailman.eng.auburn DOT
edu</a><br>[mai=
lto:<a href=3D"mailto:veritas-bu-admin AT mailman.eng.auburn DOT
edu">veritas-bu-a=
dmin AT mailman.eng.auburn DOT edu
</a>]On Behalf Of Wayne T<br>Smith<br>Sent: Wednesday, March 08, 2006 9:04 =
AM<br>To: <a href=3D"mailto:veritas-bu AT mailman.eng.auburn DOT
edu">veritas-bu@m=
ailman.eng.auburn.edu</a><br>Subject: Re: [Veritas-bu] bparchive<br><br><br=
>
NetBackup "archive" has always been a pet-peeve of mine. &nb=
sp;Most people, I<br>think, have images of the Smithsonian or Louvre when t=
hey think of the<br>word "archive" and get a warm, fuzzy feeling =
about keeping important
<br>things, forever, in an archive. But NetBackup archive just g=
ives me a<br>chill! Allow me to explain, please ...<br><br>Right=
now, you have your data, and it is backed up, with probably<br>multiple co=
pies in your backup/restore system(s). When you use
<br>NetBackup "archive", NetBackup makes a copy of the files and =
ERASES your<br>primary copy. NetBackup now has the primary copy=
of your data, and it<br>is a completely untested copy -- maybe you can res=
tore it, maybe you
<br>can't. Now, unless and until you make copies of your archiv=
ed data,<br>you have no backups. Data with no backup is data tha=
t you can afford to<br>lose. Oh yes, ... and NetBackup will happ=
ily expire your archive.<br>
Maybe that's good ... maybe not. Finally, there is no connectio=
n<br>between your original system and data and the data in NetBackup, excep=
t<br>the rather independent NetBackup catalog and any manual records you<br=
>might make. Those NetBackup catalog entries are based on the m=
achine
<br>that last held the data, not the application that might find the data<b=
r>important.<br><br>To answer your questions. (1) bparchive is probably as =
safe as your<br>backups, except you've probably been using your backup poli=
cies for a
<br>while and your archiving appears new, and (2), as should be quite clear=
<br>by now, I have no use for bparchive.<br><br>However, the tech note you =
quote is only important if a directory you<br>archive is changing during th=
e archive process ... something that would
<br>appear intrinsically dangerous for backup or bparchive.<br><=
br>Hope this helps!<br><br>cheers, wayne<br><br>Shyam Hazari wrote, in part=
, on 3/8/2006 8:45 AM:<br>> I am planning to archive some of =
the old files on my unix servers(
<br>> user related files). I already generated the file list and kept it=
in<br>> a file. My intention is to backup first(bpbackup), next use bpa=
rchive<br>> to archive the files. But after reading the following techno=
te, I am
<br>> little concerned. Now the questions is, How safe is bparchive ? An=
yone<br>> used bparchive recently ?<br>><br>> This is the technote=
I was referring to. The technote talks about<br>> archiving directories=
, but in my case I am arching individual files.
<br>><br>> <a href=3D"http://seer.support.veritas.com/docs/281323.htm=
">http://seer.support.veritas.com/docs/281323.htm</a><br>__________________=
_____________________________<br>Veritas-bu maillist - &nbs=
p;<a href=3D"mailto:Veritas-bu AT mailman.eng.auburn DOT edu">
Veritas-bu AT mailman.eng.auburn DOT edu</a><br><a
href=3D"http://mailman.eng.aubu=
rn.edu/mailman/listinfo/veritas-bu">http://mailman.eng.auburn.edu/mailman/l=
istinfo/veritas-bu</a><br>_______________________________________________
<br>Veritas-bu maillist - <a href=3D"mailto:Veritas-b=
u AT mailman.eng.auburn DOT edu">Veritas-bu AT mailman.eng.auburn DOT
edu</a><br><a href=
=3D"http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu";>http://mailm=
an.eng.auburn.edu/mailman/listinfo/veritas-bu
</a><br></blockquote></div><br>
------=_Part_5501_20605670.1141855267399--
|
