Hi Bill,

(You probably don't remember me, but I'm sure you've stumbled across some of
my old code there at some point...:>)

I don't think you can prevent the backup of the systemobject if the user
selects it.

But, if you don't want to store the data, you could bind the System Object
(via include.systemobject in a CLOPTSET) to a management class that trashes
it immediately.

I don't' think you can prevent them from overriding that include if they are
really determined, but it should cut out a lot of the copies from people
just playing with it.....

Hm... wonder what happens if you bind it to a management class with no
backup copy group?  ....something else to put on my to-test list...




-----Original Message-----
From: Bill Kelly [mailto:kellywh AT AUBURN DOT EDU]
Sent: Friday, January 09, 2004 10:58 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Backup of all-local -systemonject


On Fri, 9 Jan 2004, Lambelet,Rene,VEVEY,GL-CSC wrote:

> could you help me, I'd like to backup all local volumes like C., D: etc.
BUT
> without the system state !
>
> We did not succceed with  "Domain all-local -systemobject"

How exactly is the backup being done?  With the 'incremental' command
(scheduled or via command line) or 'on-demand' via the GUI?  If
incremental, then the 'domain -systemobject' (or 'domain all-local
-systemobject', which is the same thing) should work.  However, the
'domain' statement doesn't affect 'on-demand' backups, so if the user
selects the System Object in the GUI and then clicks 'Backup', it will be
backed up even if you have a 'domain -systemobject'.

I've recently been through all of this; as far as I can tell, there is no
way to absolutely prevent a client from backing up the System Object if
the user really wants to.  No 'exclude.systemobject', no nothing.

I hope I'm wrong on this, and if so, I'd love for someone to correct me!

Thanks,
Bill

Bill Kelly
Auburn University OIT
334-844-9917