ADSM-L

Re: Extend Archive retention period

2002-08-08 10:21:43
Subject: Re: Extend Archive retention period
From: "Lai, Kathy KL" <Kathy.KL.Lai AT PCCW DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 8 Aug 2002 20:26:49 +0800
Dear all,

Thank you for all your advice here. But I still feel confusing about whether
I can extend the retention period for an already archived file. I try
perform the action suggested by Reinhard (i.e. change the retver of the
copyg for the management class that I use to archive those files and then
use query archive command to check the expired date of that files), it does
seems works as the expired date change to a new value. But it is really
reflect the actual expire date of that archived file? Will it just show me
the calculation result and expire the archived file on the original expired
date?

Thank you very much.

> Regards,
> Kathy Lai
> Outsourcing & Managed Services
> Pacific Century CyberWorks
> * 852-8101 2790
> kathy.kl.lai AT pccw DOT com


-----Original Message-----
From: Reinhard Mersch [mailto:mersch AT UNI-MUENSTER DOT DE]
Sent: Thursday, August 08, 2002 6:03 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Extend Archive retention period


Hi Eric,

"Loon, E.J. van - SPLXM" <Eric-van.Loon AT KLM DOT COM> schrieb:
> Hi Reinhard!
> I stand correct... There is no rebinding when you update a
> managementclass/copygroup.

.. and you stand incorrect when saying "So updating an archive copygroup
will NOT work for already existing archives." And THIS was the original
question.

Best regards,

Reinhard

> Kindest regards,
> Eric van Loon
> KLM Royal Dutch Airlines

> -----Original Message-----
> From: Reinhard Mersch [mailto:mersch AT UNI-MUENSTER DOT DE]
> Sent: Thursday, August 08, 2002 08:55
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Extend Archive retention period


> Hi Eric,

> what do you mean by "rebound"? Backups may be "rebound" to a different
> mgmclass, e.g. by specifying a new one in the inclexcl list. You are
right:
> This does not happen for archives, but nevertheless: If the mgmclass an
> existing archive is bound to is changed, this change also applies to that
> existing archive.

> Let's do the test I spoke of (4.2.2.0 server on AIX 4.3.3, 4.2.2.0 client
> on Linux, copy group "test" retains for 30 days):

> client> dsmc ar -archmc=test archive-test
> client> dsmc q ar archive-test
> ...
>              Size  Archive Date - Time    File - Expires on - Description
>              ----  -------------------    -------------------------------
>               733  08.08.2002 08:35:28    /home/mersch/tmp/archive-test
> 07.09.2002 Archive Date: 08.08.2002
> ...

> server> upd co ba std test t=a retv=400
> server> activate pol ba std

> client> dsmc q ar archive-test
> ...
>              Size  Archive Date - Time    File - Expires on - Description
>              ----  -------------------    -------------------------------
>               733  08.08.2002 08:35:28    /home/mersch/tmp/archive-test
> 12.09.2003 Archive Date: 08.08.2002


> See the change in the "Expires on" field? 07.09.2002 (07-Sep-2002) to
> 12.09.2003 (12-Sep-2003)!

> So, now you ...

> "Loon, E.J. van - SPLXM" <Eric-van.Loon AT KLM DOT COM> schrieb:
> > Hi Reinhard!
> > As a matter of fact: NO!
> > Backups are rebound to the new backup copygroup/managementclass (and
thus
> > retention) archives will NOT be rebound. So updating an archive
copygroup
> > will NOT work for already existing archives.
> > Kindest regards,
> > Eric van Loon
> > KLM Royal Dutch Airlines


> > -----Original Message-----
> > From: Reinhard Mersch [mailto:mersch AT UNI-MUENSTER DOT DE]
> > Sent: Wednesday, August 07, 2002 09:12
> > To: ADSM-L AT VM.MARIST DOT EDU
> > Subject: Re: Extend Archive retention period


> > For a definite answer, you will need a developer, but to the best of
> > my knowledge, an object's DB entry does not contain the object's
> > expiration date. It contains the management class ID it is associated
to,
> > and during inventory expiration the decision is based on the archive
> file's
> > creation date and the current management class settings. So, yes:
changing
> > the management class / copy group parameters applies to all existing
> archive
> > files belonging to that management class (same for backups). This
applies
> > to all *SM versions.

> > You can easily test it: the command line client shows the expiration
date
> > of archive files. So issue a "query archive", change the management
class,
> > and issue a "query archive" again. The expiration date should have
> > changed.

> > Don't forget to activate the policy set.

> > "Lai, Kathy KL" <Kathy.KL.Lai AT PCCW DOT COM> schrieb:
> > > Dear all,

> > > I am using ADSM v3.1.2.57 for backup. I am now have a questiong about
> > > whether I can extend the retention period of an archived file. I have
> > create
> > > a archive type copy group and a management class with certain
retention
> > > period which is not the default management class (say 7days). Then I
use
> > > this management class and copy group to archive a file. My question is
> > > whether I can change the retention of that file already archived by
> > changing
> > > the retention period of the management class? By change the retention
> > period
> > > of the management class, will it effective to both file already
archived
> > and
> > > new archive file after the change or just effective to file archive
> after
> > > the change? If I can change the retention period of an archived file
by
> > > change the retver of the management class, does it mean that I have to
> > > retrieve the file and then re-archive it for a longer retention?

> > > Please urgently reply me the question as I am using this method to
> backup
> > > the DB archive. User now request to hold a certain online backup image
> of
> > a
> > > DB. Now I can only hold the expiration job for the backup image only
but
> > not
> > > the DB archive. Thank you very much.


> > > > Regards,
> > > > Kathy Lai
> > > >

> > --
> > Reinhard Mersch                        Westfaelische
Wilhelms-Universitaet
> > Zentrum fuer Informationsverarbeitung - ehemals
Universitaetsrechenzentrum
> > Roentgenstrasse 9-13, D-48149 Muenster, Germany      Tel:
+49(251)83-31583
> > E-Mail: mersch AT uni-muenster DOT de                       Fax:
+49(251)83-31653


> > **********************************************************************
> > For information, services and offers, please visit our web site:
> > http://www.klm.com. This e-mail and any attachment may contain
> confidential
> > and privileged material intended for the addressee only. If you are not
> the
> > addressee, you are notified that no part of the e-mail or any attachment
> may
> > be disclosed, copied or distributed, and that any other action related
to
> > this e-mail or attachment is strictly prohibited, and may be unlawful.
If
> > you have received this e-mail by error, please notify the sender
> immediately
> > by return e-mail, and delete this message. Koninklijke Luchtvaart
> > Maatschappij NV (KLM), its subsidiaries and/or its employees shall not
be
> > liable for the incorrect or incomplete transmission of this e-mail or
any
> > attachments, nor responsible for any delay in receipt.
> > **********************************************************************

> --
> Reinhard Mersch                        Westfaelische Wilhelms-Universitaet
> Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum
> Roentgenstrasse 9-13, D-48149 Muenster, Germany      Tel: +49(251)83-31583
> E-Mail: mersch AT uni-muenster DOT de                       Fax: 
> +49(251)83-31653


> **********************************************************************
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
confidential
> and privileged material intended for the addressee only. If you are not
the
> addressee, you are notified that no part of the e-mail or any attachment
may
> be disclosed, copied or distributed, and that any other action related to
> this e-mail or attachment is strictly prohibited, and may be unlawful. If
> you have received this e-mail by error, please notify the sender
immediately
> by return e-mail, and delete this message. Koninklijke Luchtvaart
> Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be
> liable for the incorrect or incomplete transmission of this e-mail or any
> attachments, nor responsible for any delay in receipt.
> **********************************************************************

--
Reinhard Mersch                        Westfaelische Wilhelms-Universitaet
Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum
Roentgenstrasse 9-13, D-48149 Muenster, Germany      Tel: +49(251)83-31583
E-Mail: mersch AT uni-muenster DOT de                       Fax: 
+49(251)83-31653

<Prev in Thread] Current Thread [Next in Thread>