I would take advantage of the archive function of ADSM to accomplish your
goals of saving system snapshots. Set up a schedule so that on the first day
of the week, month, etc. you archive the data with a different mgmt. class.
Regards,
Lowell
lowell AT tkg DOT com The Kernel Group, Inc.
>
> ---------------------------- Forwarded with Changes
> ---------------------------
> From: INTERNET.OWNERAD at SNADGATE
> Date: 9/3/96 2:28PM
> To: Jerry Lawson at TISDMAIL
> *To: *Multiple recipients of list ADSM-L at SNADGATE
> Subject: Q's about weekly, monthly, yearly backups.
> -------------------------------------------------------------------------------
>
> Owen -
>
> ADSM is not your father's backup product! :-)
>
> Because of it's design, and the use of the Data Base, it is not a requirement
> to do full backups. This is supported by the lack of any "easy" way to do a
> full backup - you can't just click on "full" and let 'er rip. The design lets
> you always get to the latest copy of the files, thus allowing ADSM to go
> directly to the files that made up your disk the last time it was backed up.
> Additionally, if you do a full restore, you don't have to do the full volume
> and then apply the incrementals or differentials. Each file is only handled
> once. They are processed in tape order to eliminate back spacing on the tape.
> All of this minimizes network traffic, which in my shop is the critical
> resource.
>
> The only argument that I have heard that begins to make sense for full backups
> is that a "full" backup allows for the smallest number of tapes to manage.
> Perhaps this is true, but I rely on my tape automation system to worry about
> that. ADSM can use a process called collocation to keep files from a user
> together on a minimum set of tapes that generally only "belong" to him, so
> this is not a strong argument, in my opinion.
>
> Because of this design, we keep things simple here - we just set up a single
> policy domain for an area, and tell people to stick ADSM in their Start Up
> folders and forget about it - let the scheduler handle the backups for them.
> Behind the scenes, the daily incrementals keep popping off without a problem.
>
> As they said in Star Trek 5 "Let go of your pain....."
>
> Jerry Lawson
> jlawson AT itthartford DOT com
> ________________________Forward Header________________________
> Author: INTERNET.OWNERAD
> Subject: Q's about weekly, monthly, yearly backups.
> 09-03-96 02:28 PM
>
> [This is a question from someone who has no formal ADSM training but has
> tried to read the ADSM docs on the subject, so it's a pretty newbie question.]
>
> I am trying to understand how the traditional weekly, monthly, and yearly
> backup schedules I'm used to translate into ADSM. By traditional, I mean the
> following schedule:
>
> Daily incremental backups are made for a machine.
> Each week, a full backup is made and kept for 4 weeks.
> The first weekly backup is also considered a monthly backup and is kept for
> 12 months.
> The first monthly backup is also considered a yearly backup and is kept for
> 7 years.
>
> This works fine in the one file system->one set of tapes->one backup mode,
> but ADSM complicates things mightily.
>
> I am trying to backup multiple systems each on a different day (for the
> weekly) to a single stgpool (or active policy set -- I'm still a little hazy
> on the nomenclature) and then backing that stgpool up to a copy stgpool for
> off site storage. I want the off site tapes to be stored for a set period of
> time (4 weeks, 12 months, or 7 years) and then be returned and immediately
> re-used.
>
> So my questions are do I need to use different management groups (policy
> set?) with different retentions for the daily, weekly, monthly, and yearly
> backups? Or do I need a separate copy stgpool for each type?
>
> If the above did not make it clear, I am confused. Any help would be
> appreciated.
>
> Thanks for your time,
> Owen Crow
>
|
