Veritas-bu

Re: [Veritas-bu] Archive list

2012-03-11 03:54:31
Subject: Re: [Veritas-bu] Archive list
From: "bob944" <bob944 AT attglobal DOT net>
To: <veritas-bu AT mailman.eng.auburn DOT edu>
Date: Sun, 11 Mar 2012 03:54:01 -0400
Haven't seen this much interest in archives (in the NBU sense) in
years.  GOOD discussion.

[confession:]  Hi.  My name's bob944 and I've used user archives.

Wow.  This is the most press UARC has received in ages.

First, every person who commented on this made sense and appears to
understand the way NBU archives work.

Second, an issue:
o  Not telling the user community about archives is like not telling
them the rm or del commands exist.  Users--and admins--make mistakes,
but my personal High & Mighty Pedestal isn't quite high enough to
decide what they can't know about.
        
In the following, I'm assuming that 
o  UBAKs and UARCs are understood by the admin and the owner of the
data:  user specifies the data; upon successful archive, the data are
removed
o  I and the users decided where and for how long the data are be
preserved

Re: David Rock's follow-up:
> Backup admins are generally in the business of preserving data
> for recovery, not removal of files from systems.

I agree, yet don't see a conflict here.  IMO, the admin _does_
preserves the data--automatically at it's very last (that may be
important) state--before the user blows it away.  The user has made
sure "we" backed it up before it's deleted.  He could have just
deleted it himself.  Why is that not a win?

If we back up /ora/db/our_2011_customer_masterfile.dbf, we do it so
that we can recover it after some bonehead mistake OR DELIBERATE USER
ACTION ("the backup guys have backed up the DB; let's blow it away and
go with the new schema") removes data that is needed today or a year
from now.  There's no intrinsic difference when we, and the user, set
up an archive.  The user can already 'rm
our_2011_customer_masterfile.dbf' without any archive in scope, call
up and need it restored.  Same thing for a deliberate decision by the
user that they no longer need it--but just in case, would like the
last version backed up before their schema change.  To Mr Rock's
point, we _have_ preserved the data so that the user can remove it
with assurance that it can be recovered within the parameters agreed
to--the same as for backups.  I see no difference between a UARC and a
morning phone call of "did you back up that old customer master file?"
| "yes" | "Okay, we're blowing it away." 

Unless one has a) incorrectly instructed the user community on what a
UARC does, b) set the UARC parameters to something inferior to what
the user expects  or c) treats UARCs as sacrificial data, I
don't/haven't seen an issue:  we're doing exactly what we do for
scheduled backups--preserving the data to agreed-upon standards.

Regarding the archive policy (I'll still call it that, assuming that
the admin and the user know "the user runs a user backup, specifying
what gets backed up and, if it's an archive and successful,
subsequently deleted"), I've only set this up in production a couple
of times in the last 15 years.  My favorite was in the late '90s with
NBU 3.1 or 3.2.  A user group had a finance application in which
month-end created an elaborate set of directories, subdirectories
(thousands) and files (hundreds of thousands).  The app left the files
in place, leaving it to the user to decide when the data were of no
value.  None of the users (or perhaps, "their management") was keen on
using a command line or GUI to recursively remove thousands of
directories and the files therein, and the space used was a big issue
in those days.  They used the app's data for a day or two, then their
business process used a UARC schedule on (IIRC) a unique policy to
back it up "just in case" and delete it.  I've also set up UARC
schedules for groups that were leaving the corporate HQ's backup
umbrella so they could get tapes of their data to be recovered in
their new "home."

[Rock:]
> Basically, what you are trying to do is something that NBU
> is not meant to do.  The expected behavior for Archives is
> that they are managed by the client admin, not the backup
>admin.  Archive jobs get a filelist from the user, run the
> archive, and 

[if and only if the backups were 100% successful,]

> delete the files when they are done, so the user would
> already know what files were archived because they would
> have supplied the list to the command in the first place.

Whether the original poster understood this or not, IMO it's an
excellent clarification of how UBAKs (without the deletion) and UARCs
work.  It's scary or unknown territory to many admins and most all
users.

> From: Kevin Holtz
> All is true but I wouldn't say it's something NBU was not designed
> to do.  It was made difficult for a reason rather than easy due to
> the nature of the outcome e.g. Archiving.  This is very common
> practice for DBA's.  Yes, this all needs to be scripted, blat etc.
> and you will need admins to help if you don't have access to the
> local systems.

What he said, except the admin isn't helping me, I'm helping them by
providing a user tool.  Though I think Rock was commenting on the
"policy" aspect to make sure the original poster understood that the
class's selection list was immaterial and that the UBAK or UARC had to
be user-initiated.


> From: Wayne T Smith
> When I consider protecting data, I'm typically thinking
> of keeping them in multiple places that are as independent
> as possible.
> 
> If I were to use NBU "archive", I would be basically
> chopping off one of the places where the data is stored
> (its original, live home).

But you're not doing it--not wiping out data.  The user _wants_ to
delete his data after ensuring it's been backed up.  You're providing
a facility to the user to back up data and then automatically delete
it, rather than the user deleting it without such assurance, or
coordinating his deletion with backup completion times, or backing up
X and Y and accidentally rm'ing X, Y and Z.

> I think the place for NBU "archive" is quite limited and is not a
> reasonable solution where one is expected to be able to restore the
> data to their usable place/form.

Agreed that its place is limited but why is it any more unreasonable
to "restore the data to their usable place/form" than if the data had
been backed up by a full/diff/incr schedule and then blown away by the
user?  You have the same storage destinations, volume pools, copies,
retentions, ownership, multiplexing, ... as any other backup--all
under the admin's complete control.  Why should I be less able to
restore the data "to their usable place/form" than from, say, the
previous night's scheduled full?

> For the case where "it would be nice, but not critical, to restore
> this data sometime in the next x months", NBU "archive" might be
> an easy solution.   I've never encountered that case.

Similarly to previous paragraph, I don't see any difference in
restoring the data.  It's NetBackup backup, it's a NetBackup image,
it's in the catalog, it's using whatever facilities you could
otherwise include in a server-directed schedule, and the data owner
wants to delete it after it's backed up one final time.  What am I
missing?


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

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