Kelly J. Lipp wrote:
>
> Jerry says it much more eloquently than I. We need to do a better job
> understanding what our business requirements are and less time worrying about
> how old, clunky backup products work.
>
> Kelly
>
> -----Original Message-----
> From: Jerry Lawson [SMTP:jlawson AT THEHARTFORD DOT COM]
> Sent: Thursday, January 22, 1998 10:12 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Using different policies to nightly and weekly backups.
>
> ---------------------------- Forwarded with Changes
> ---------------------------
> From: INTERNET.OWNERAD at SNADGATE
> Date: 1/21/98 11:40AM
> To: Jerry Lawson at ASUPO
> *To: *ADSM-L at SNADGATE
> Subject: Using different policies to nightly and weekly backups.
> -------------------------------------------------------------------------------
> Gary -
>
> If I read your country code and email address correctly, perhaps I should say
> "G'day Mate!"
>
> I hate to break the bad news to you, but you are falling into a logic trap.
> ADSM will look at the files and the rules in effect at that time, and handle
> them accordingly. If the rules say keep 7 copies, it will keep 7. If you
> change it to keep 2, it will keep 2, and throw away any above that (up to 5,
> perhaps).
>
> This is an issue that has been discussed many times - I don't think it ever
> ends - new people just keep coming into the loop and need to be brought up to
> speed. If you really want to see the old messages, check out the archives.
> But in a nutshell, you really need to understand what makes ADSM different.
> It is designed around the idea that if a file doesn't change, why waste
> network bandwidth and machine cycles to back it up again? The old backup is
> still good. Through it's database, it can get back to any file that is still
> active, so periodic monthly (absolute) backups don't really have a lot of
> value.
>
> The real question you need to ask is "How far back do you really need to go
> for any given file?" How often do they change? Then plan accordingly - set
> the number of copies and retention period accordingly. And remember that you
> can have multiple management classes, so that if you determine that 7 copies
> for 21 days is fine for *most* of your users, but there is one application
> where the files must be kept for 90 days, you can have both.
>
> If you really have to have a "point in time" image of a set of files, such as
> a monthly, use the Archive function not the backup. I often wonder, though,
> what the impact would be if you had to go back to one of those.... but that's
> a different story.
>
> As a (somewhat) wise man once said, "ADSM is not your Father's backup tool."
>
> Hope that helps, and if it doesn't, feel free to get back to me.
>
> Jerry Lawson
> jlawson AT thehartford DOT com
>
> ______________________________ Forward Header
> __________________________________
> Subject: Using different policies to nightly and weekly backups.
> Author: INTERNET.OWNERAD at SNADGATE
> Date: 1/21/98 11:40 AM
>
> Dear ADSMers,
> I have a requirement for nightly incremental backups to be retained for
> 14 days and weekly full backups for 3 months (90 days). I have tried
> using a weekly & nightly policy set with the same management class, each
> having a standard copy group with the following parameters (I used 2
> days and 7 days for a test) :-
> TEST_DOM ACTIVE TEST_MGMT STANDARD No Limit No Limit 2
> 2
> TEST_DOM NIGHTLY TEST_MGMT STANDARD No Limit No Limit 2
> 2 mode=modified
> TEST_DOM WEEKLY TEST_MGMT STANDARD No Limit No Limit 7
> 7 mode=absolute
>
> Using a test program to cycle through the days, 2 days after the weekly
> backup the weekly version expires.
> The sequence goes like this :-
> count=1
> set_date (day of the month = count)
> activate policy test_dom weekly
> while [ count -le 4 ]
> do
> set_date
> start_server
> dsmc incremental /test
> stop_server
> let count=count+1
> done
>
> set_date
> start_server
> activate policy test_dom weekly
> dsmc incremental /test
> activate policy test_dom nightly
> stop_server
> let count=count+1
>
> while [ count -le 12 ]
> do
> set_date
> start_server
> dsmc incremental /test
> stop_server
> let count=count+1
> done
>
> According to the help text when the active policy is changed, files are
> rebound when :
>
> ?You change the management class for the file by specifying a different
> management class in an INCLUDE statement.
> ADSM continues to manage the backups based on the old management
> class until you run another backup.
>
> ?Your ADSM administrator deletes the management class from your active
> policy set.
> ADSM uses the default management class to manage the backup
> versions when you back up the file again.
>
> ?Your ADSM administrator assigns your client node to a different policy
> domain and the active policy set in that domain does not have a
> management class with the same name.
> ADSM uses the default management class for the new policy domain
> to manage the backup versions.
>
> Since none of the above is true, I would expect none of the files to be
> rebound. The backup report does not show any rebound files, but the
> versions are still expiring.
>
> Does anybody know why.
>
> Version 2 Server and Client using shared memory.
>
> Regards
> Gary
>
> ----------------------------------------------------------------
> Gary Bromley
> Aspect Computing Pty Ltd
> Tel : +61 (0)3 9230 2222
> Fax : +61 (0)3 9818 1320
> Email : Gary.Bromley AT aspect.com DOT au
>
> ---------------------------------------------------------------
>
> Part 1.2 Type: application/ms-tnef
> Encoding: base64
Hi,
I had the same problem. The solution for this situation is -
For each client you have to set two different node names: for
example-for CLIENT, register it twice - once as CLIENT and the other as
CLIENTw - each of them assigned to another policy domain.
In ordaer to automaticly start the weekly client you have to issue, with
the 'dsmc sched' command the parameter -node=XXX -password=XXX (V2);
-machine=XXX -password=XXX (V3).
Good Luck.
Good Luck.
|
