Automated System Recovery Tool

J C powerswitch1972 at yahoo.com
Thu Apr 2 01:22:14 UTC 2009






________________________________
From: James Antill <james at fedoraproject.org>
To: Development discussions related to Fedora <fedora-devel-list at redhat.com>
Sent: Wednesday, April 1, 2009 5:56:06 PM
Subject: Re: Automated System Recovery Tool

   On Wed, 2009-04-01 at 11:52 -0700, J C wrote:
   >> 
   >> Title:  Automated System Recovery Tool  
   >> Student:  Jeff Chandler  
   >> Abstract:  
   >> An automated system
   >> recovery tool is needed for average users to feel secure using Fedora
   >> as their primary Desktop OS. Fedora and other Gnu/Linux distros can be
   >> rendered useless to the non-technical user by a failed binary driver
   >> install (Video cards, wireless ethernet, etc.) or malicious programs.
   > > For these users, there is no easy fix available.

>How are you going to run your daemon (let alone the UI to command it)
>if arbitrary parts of the system are broken?


The daemon should already be installed and running as part of the initial installation, at the users discretion, of course.  It will create a series of backup files at specified intervals, daily, weekly, or monthly.  The GUI recovery tool will have three options: Run  from the actual installation, a recovery partition ( essentially a bare bones copy of the installation cd) or the installation cd itself.  It will have to use the backup file from the local hard drive, unless the user had the foresight to save a backup to another media.  I suppose a reminder could be a part of the system, to copy backups to some other system or media. 


    >>  I propose a daemon
    >> that tracks changes in the filesystem and can restore installed
    >> programs and configuration to a previous point in time when the system
    >> was working. Suspect programs would be cordoned off into a secure
    >> area.

>So do you only protect packages, and not all files on disk?
>If more than packages how do you tell which ones (reverting a config.
>file might require reverting a package, and it's much more likely the
>other way around).
>If only package data, then you should really be monitoring/using the
>"yum history" database (not written, yet, but planned for this year).

The user will select to revert packages and config data only or all data.  In the former case, packages and config files will be restored to tjhe state they existed at a previous time ( selected by the user  among the available backups) so versions and configuration data should be in sync.  If the latter option is chosen, the same action occurs, but any user data that has changed (based on file access times) since the backup, will be moved to a "vault" where it can be recovered by the user with assistance from the recovery tool.
 


  [...]
  >>    A daemon that would track changes in the filesystem, installed
  >> packages and versions, and configuration information.  In the event of
  >> a system failure or corruption (by a binary driver, user error,...)the
  >> Automated System Recovery Tool could be used to restore the system to
  >> a
  >> previous time.  The daemon would also keep a copy of non-standard (not
  >> available from the standard repos) packages for reinstall. The tool
  >> could also be used as a System Backup utility to store all system and
  >> user data in a compressed file in case of a total system or hardware
  >> failure.

>A backup utility like this would be a huge undertaking, on it's own, I
>think (even if you ignored the packaging aspect).

  [...]
  >> * A rough timeline for your progress
  >>   1.) Implement daemon to record system changes to a recovery file. 1
  >> week
  >>   2.) Implement Graphical Interface for user interaction. 1 week
  >>   3.) Implement System Recovery backend 2 weeks
  >>   4.) Test and Debug. 2 weeks
  >> * Any other details you feel we should consider

>IMO the above is "optimistic".

I realize the timeline seems optimistic, for some reason I was thinking the actual coding period was only 6 weeks, but now I see it is actually 12 weeks, plus an additional 4 weeks between the announcement of acceptance and begin of coding. I've update my proposal to reflect the actual time period.



-- 
Thank You for your comments,
Jeff Chandler
powerswitch1972 at yahoo.com


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090401/d7d60231/attachment.htm>


More information about the fedora-devel-list mailing list