Classification:
Prologue:
Epilogue:
Hi Dan,
If I understand this scenario correctly, you *should* have been able to restore
the prior version. Let me lay out what I think you're saying:
04/06/1997: File last modified 90 days (or more) ago. Assuming there was a
prior backup to begin with, let's say for the sake of discussion that it was
backed up on 01/01/1997.
04/07/1997: File is modified again, and corrupted in the process. ADSM backs
up the corrupted file that night.
04/08/1997: User discovers the error, and tries to restore the prior backup
version (created on 01/01/1997).
Based on this, here is what should have happened:
Version backed up on 01/01/1997 is deactivated. The 30-day clock starts
ticking at this point (04/07/1997). This version is still available for restore
for 30 days, i.e. until 05/07/1997.
Version backed up on 04/07/1997 is now the active version.
Unless there is something wrong with the base assumptions, the prior backup
version should have still been available for restore.
Andy Raibeck
ADSM Level 2 Support
---------------------- Forwarded by Andrew Raibeck/San Jose/IBM on 04-11-97
04:53 AM ---------------------------
04:53 AM ---------------------------
owner-adsm-l @ VM.MARIST.EDU
04-11-97 05:43 AM
Please respond to ADSM-L AT VM.MARIST DOT EDU@internet
To: ADSM-L @ VM.MARIST.EDU@internet
cc:
Subject: More Management Class Questions
While we are on the subject, has anyone developed a technique for
maintaining multiple (>1) ONLY versions for files that STILL EXIST. I have
a server who backs up data to a management class with the following
characteristics:
Versions Data Exists: 7
Versions Data Deleted: 2
Retain Extra Versions: 30
Retain Only Version: 30
Copy Mode: Modified
Copy Serialization: Shared Static
Copy Frequency: 0
Earlier this week, a client corrupted a file that had not been modified for
90 days. The file was still valid and ADSM backed up the "corrupted" copy
that evening, EXPIRING THE ONLY GOOD COPY. The client discovered that the
file corrupted the next morning and requested that it be restored to the
previous version. We were very embarrassed to not be able to meet this
very reasonable request. Note that had the file been deleted instead of
corrupted, we would have had 2 copies from which to restore. Fortunately
for us this was not a business critical file. However, this does point
does a very real exposure that we had not previously considered. We could
keep 7 copies for an UNLIMITED amount of time but this policy change
applied to several hundred clients would create a significant increase in
resource utilization both for the database and the associated storage
pools. What I really need is a option to specify multiple ONLY files.
Have I overlooked something?
> Date: Thu, 10 Apr 1997 08:42:23 -0400
> From: Andrew Raibeck <storman AT US.IBM DOT COM>
> Subject: Re: Plea for Clarification of example in AIX Admin Guide
>
>Classification:
>Prologue:
>Epilogue:
>
>As long as the file exists on the client, the active version is always the
most
>recent version. If/when the file is backed up again, the pre-existing
active
>version becomes inactive, and the new version becomes the active version.
Thus,
>as you've already surmised, the "VEREXISTS=5" is correct.
>
>If you delete the file from the client, then run another incremental
backup,
>ADSM detects that the file no longer exists on the client and changes the
>active version to inactive. Also at this time, the VERDELETED and RETONLY
>options go into effect. Thus if the goal is to retain up to 3 inactive
versions
>when the original file is deleted, the VERDELETED should be set to 3. So
I'd
>say that the example is wrong in this case.
>
>Andy Raibeck
>ADSM Level 2 Support
DanC
=============================================
Daniel G. Crouse
Mainstar Software Corporation
Email: Dan.Crouse AT Transquest DOT com
Vmail: 800-233-6838
Voice: 404-714-5754
Fax: 770-682-7739
=============================================
- AT000411
|
