ADSM-L

Re: "Point-in-time-restore"?

1994-02-01 08:57:13
Subject: Re: "Point-in-time-restore"?
From: "Smith, Dean" <DSMITH8 AT IS.ARCO DOT COM>
Date: Tue, 1 Feb 1994 13:57:13 GMT
> In a programming environment -- especially in low-level programming like
   > robotics or the like -- it's awfully easy to do something dumb and
> clobber the disk by accident, or want to fall back to a previous release
> if an install fails catastrophically. Another scenario where
> point in time restores would be useful is in case of security
> breakins on Unix systems; it'd be very useful to be able to do a
> point in time restore from before the breakin and compare it to
> the current version to determine what had been compromised.
>
> It'd be a useful thing in configuration management as well. A
> known working configuration at point A in time would be a
> excellent starting place for custom installs (hit the basics, and
> then overlay the custom stuff for this workstation, then do a
> backup to freeze a known working configuration).

> I'm scheduling a ADSM BOF at SHARE in Anaheim; I'll put this on
> the list of stuff to be discussed.

Case I:  If your going to be doing this kind of development you can should know
when you will be getting into trouble.  Doing an ARCHIVE at that point seems in
order.  If this developer doesn't know when they can get into trouble the
current backup/restore operations will work.  If I was going to do something
that could really hurt, I would bring up ADSM, do an incremental and get a cup
of coffee.  When I got back the incremental would be done and I'ld be ready for
my worst nightmare.

Case II:  The UNIX intruder will very likely update system files which will be
excluded from backup--at least that is what I would be doing.  In any case, an
arguement for a better security which logs updates.  Indeed, since intruder
corruption is much less likely than User Initiated Unintended Computing (UIUC),
shouldn't resources needing this type of function already have accesses logged
by some other mechanism?

Case III:  Configuration Management: is an arguement for using the ARCHIVE
function.

The cases you are using are very user/application specific.  They are arguements
for a user managed backup and recovery.  IMHO, this is what ARCHIVE constitutes.


BOF:  You'll probably see me there.

Dean Smith, a.k.a.  DASD MISER
<Prev in Thread] Current Thread [Next in Thread>