ADSM-L

Re: Long term data retention for retired clients

2005-07-14 13:49:14
Subject: Re: Long term data retention for retired clients
From: "Allen S. Rout" <asr AT UFL DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 14 Jul 2005 13:48:54 -0400
==> On Thu, 14 Jul 2005 10:27:49 +0100, John Naylor <John.Naylor AT 
SCOTTISH-SOUTHERN.CO DOT UK> said:

> I have consideredf various approaches
> 1) Export
> 2) Backup set
> 3) Create a new domain for retired clients which have the long term
> retention requirement

> I see export and backup sets as reducing database overhead, but being less
> easy to track and rather unfriendly if you just need to get a subset of
> the data back

Export yes, backupset no; [ see below ]


> The new domain would retain great visibilty for the data and allow easy
> access to subsets of the data, but you would stiil have the database
> overhead.

Yes, but in the long term this overhead devolves to just space.  For example,
if everything in the node is ACTIVE, I don't believe that it represents much
of an e.g. expiration hit.  So there's an incrementally (hah) larger full DB
backup, and more space on disk for the DB, but not a lot of day to day DB
overhead.

> Does the choice just depend, on how often in reality you will need to get
> the  data back ?

I'd say that and how frequently you want to do the retention thing, for how
long.

Off the top of my head, if keeping the bits and pieces around would add up to,
say, a third of my [DB space / data / whatever] I'd consider doing something
nearline with it.


[below]

Keep in mind:  you can restore from a backupset stored on the server; this
need only be a little less convenient than restorations from online data.
Gedankenexperiment:

Say you want to deal with TheNode:

rename node TheNode OLD-2005-07-12-13-TheNode

       [ in case you ever want to use TheNode name again ]

GEN BACKUPSET OLD-2005-07-12-13-TheNode Terminal devclass=foobar RET=NOLimit

which usess tapes FOO1 and FOO2.

Then you DEL FILESPACE OLD-2005-07-12-13-TheNode *

and

CHECKOUT LIBVOLUME FOOLIB FOO1
CHECKOUT LIBVOLUME FOOLIB FOO2

At this point, you've got a -permanent- record of the state of TheNode, at the
cost of a few records in the node and backupset tables. Of course, you have an
increased exposure to media failure: no copypools for backupsets.  Anyway, to
restore from it all you have to do to use it is check the tapes back in, and
issue a

dsmc restore backupset Terminal -loc=server [sourcespec] [destspec]

This is going to be a much less efficient restore than the online one, but
only in wall clock time and tape use, not in human skull sweat.


Plus, if someone gets crotchety about the archive, you can hand them the
checked out tapes and tell them to get their own LTO3. (heh)


- Allen S. Rout