ADSM-L

Re: ADSM Backup and its alteration of file "last access" timestamp

1996-09-03 02:19:15
Subject: Re: ADSM Backup and its alteration of file "last access" timestamp
From: Andreas Floeter <Andreas.Floeter AT AIRBUS DOT DE>
Date: Tue, 3 Sep 1996 08:19:15 +0200
On Mon, 2 Sep 1996, Michael Fink wrote:

> On Tue, 27 Aug 1996, Richard Sims wrote:
>
> > An historic problem with ADSM Backup is its alteration of a file's
> > "last accessed" timestamp, which is highly undesirable, particularly in
> > the case of mail files where handling programs detect unread mail via
> > "modified" and "accessed" timestamps.  This is also a privacy and
> > security issue.
> >     I scanned the ADSM-L archives to review past discussions of this
> > issue.  It has been the subject of customer complaints, but as yet seems
> > to have no resolution.  One circumvention I've considered it to mount the
> > subject file system a second time on the client, at a different mount
> > point, in read-only mode, and then perform the ADSM backup.
> > But I'd like to see a more natural solution to this problem from IBM.
> >     So I seek whatever perspectives list members have on this.
> >          thanks,   Richard Sims, Boston University OIT
>
> I'm a bit surprised that there has not been any echo on this letter
> so far. Either it has been discussed /ad nauseam/ previously
> (I'm relatively new to the list) or it's not an issue or (I hope not)
> there are so many issues more urgent than this one...?
> Anyway, I plainly second above views.

I second this, too. The thing with ADSM is, that there are so many little
surprises, that after awhile one gets a bit tired to comment on all
the things, which are not natural at all. To make an example I will post
on current problem with the ADSM hotline, later this morning.

But obviously, a backup tool should be transparent to the system and it's
data. It should alter only data it really needs to.

> As a matter of definition, a backup/restore system is supposed to
> take a snapshot of the information in a file system and to be able
> to restore this information when needed. In a UNIX file system, the
> information consists of all files' data and metadata. A backup system
> that alters this information will not be able to fully restore it.
>
> If a feature such as atime exists in a system, it will be used for
> various (unforseeable) purposes; detecting unread email is just one
> example. So if you alter atime by backup procedures, you will break
> an unknown number of applications or - at the least - confuse users
> who try to interpret the output of the `ls -lu' command.
>
> Taking this evident principle into account, traditional UNIX backup
> methods have either avoided updating the atime alltogether by directly
> accessing the inode area (dump(1M) being an example) or have provided
> options to reset the access time after copying out the files
> (such as tar(1), cpio(1) etc.).
>
> So why go for less? It's easy to implement, anyway. Just look into
> any PD version of tar or cpio and imitate their work. Hey IBM
> folks, what're you waiting for? (And then, for a real improvement,
> please add backup of special files, too.)

I second this one too. There are two situations why one makes backups,
first a disk crashes and second a "logical deletion" occured. The first
one
does not stop upfront before system disks. Restoring a system from scratch
will take always a very long time and deciding later on which system files
have changed and should be added from a backup is very error prune.
The matter of restoring an disk which belongs to the operating system is
not an easy task but it should be a challange for the development team of
a backup tool. The second case is usually, that a user deleted data or an
application has corrupted data. Only the second case is really covered by
ADSM, unfortunately.

> Sincerely,
>
>    Dr. Michael Fink +-----------------------------+------------------------
>         EDV-Zentrum | Universitaet Innsbruck      | Tel: +43(512)507-2311
>  Computing Services | Technikerstrasse 13         | FAX: +43(512)507-2944
> --------------------+ A - 6020 Innsbruck, Austria | Michael.Fink AT uibk.ac 
> DOT at
>

______________________________________________________________________
Disclaimer: These are my views and not those of my employer.

                        Andreas Floeter
Phone: +49 40 74 37 - 48 50     FAX: +49 40 74 37 - 27 55 (or 47 60)
email: Andreas.Floeter AT airbus DOT de

                Daimler-Benz Aerospace Airbus GmbH
Kreetslag 10, 21129 Hamburg; Postfach 95 01 09, 21111 Hamburg, Germany
<Prev in Thread] Current Thread [Next in Thread>