> In <1994Nov11.194347.21011 AT draper DOT com>, spikes AT vnet.ibm DOT com
> (Jim Smith)
writes> >>>1) You cannot select a full backup. He is a firm believer in
> > re-saving all the data periodically.
> >As Amy stated, there is a way using the copy groups to define an absolute
> >backup.... but .. this is also a known requirement. There are several users
> >that would just like to select a 'FULL INCREMENTAL' pulldown or schedule
> >a full incremental without going through policy changes.
> >Jim Smith / ADSM Technical Support / San Jose
> I hope that the 'Known requirement' includes point-in-time
> capability. I suspect that people who want periodic full backups are
> also expecting that they will be able to locate this full as a
> kept-together entity in ADSM and easily restore to it. That is not
> the case today with ADSM. If normal incrementals are done and/or
> another full, the first full becomes very difficult to identify and
> restore from.
Point-in-time is a frequent request here. We run redundant backups
(UNIX dump, et. al.) which fills this requirement. Redundancy has
great value and increases flexibility because it allows either system
to do either function (trivial restores or complex restores) but makes
it truly easier to pick the appropriate restore methodology.
>
> The desire for a full backup is perhaps a hold over from other
> methods of backup which don't integrate the incremental backups in a
> server. People think they need frequent full backups because with
> all other backup systems you would be crazy or stupid or both to take
> one full and then infinite incrementals and expect a full restore to
> work or even be possible. One of the great things about ADSM is that
> you can do that without being crazy or stupid ot both!
This feature is very difficult to explain to people who are not
familiar with or trust the features of ADSM. I find myself going
crazy and stupid at times trying to explain why this works.
>
> However, the old backup paradigm made a virtue out of a necessity
> - the necessary periodic fulls created point in time restore
> capability. What ADSM needs is an option which says --
"old backup paradigm made a virtue out of a necessity...." Hmmm. I like
that. May I use it? It says it all.
>
> 'after this incremental, tag all the file versions in the current
> active set as "Point-in-time-d94315:16.30' comment(my system before
> Warp)"'. The server MUST avoid deleting any file versions in this set
> until the point-in-time indicator is released. This point-in-time
> should also show up as a choice at restore time.
I wish we had this option. Our catalogs and repositories are too large
now to allow for this. We keep 5 versions of actives and 2 versions
of inactives and our catalogs are huge. I have been running an audit on
one server shadow (a DDR'ed copy of a server) for over a week now on a
3090-200 and it's still running. It's using about 16 CPU hours/day and
is into it's 8th day. It looks like this:
ANS5101I Server command: 'q db'
Available Assigned Maximum Maximum Page Total Used %Util Max.
Space Capacity Extension Reduction Size Usable Pages %Util
(MB) (MB) (MB) (MB) (bytes) Pages
--------- -------- --------- --------- ------- --------- --------- ----- -----
7,020 7,020 0 2,000 4,096 1,797,120 1,285,285 71.5 71.5
7,020 7,020 0 2,000 4,096 1,797,120 1,285,285 71.5 71.5
ANS5103I Highest return code was 0.
This is just one of four ADSM servers now. We could not possibly expect to
put much more data on these ADSM servers. Fortunately (or unfortunately)
our object count is extremely high but the data is not all that large
for this server. Believe it or not, this server services only one client.
Our UNIX servers are mostly very large Auxpex fileservers and the average
file size is relatively small (I don't have that number). The data
changes frequently on many filesystems, to use a retailing term, our
"stock turn" is perhaps less than a week on many filesystems because
production data is being processed and then deleted and replace with
new production data. Our expiration processes blow off thousands of
files/day and the tape reclamation process works great!
________________________________________________________________________
| Mitch Sako \\\\ \\\\ \\\\\\\\ |||||||| /////// // // |
| I-NET Corporation \\ \\ \\ \\ \\ || // // // |
| LSI Logic Contract \\ \\\ \\ \\ || // //////// |
| Mailstop E-195 \\ \\ \\ || // // // |
| 1501 McCarthy Blvd. \\ \\ \\\\\\\\ || /////// // // |
| Milpitas CA 95035 ___o |
| local: mitch@asic _'\ <_ Phone: (408) 433-4187 |
| internet: msako AT lsil DOT com (_)/ (_) FAX: (408) 433-8796 |
| personal: msako AT netcom DOT com Pager: (408) 989-3365 |
| ibmmail: USMILUN9 AT IBMMAIL |
| DISCLAIMER: Opinions expressed are mine alone |
|______________________________________________________________________|
|
