HomeUserBackup Feature Specification

[Aigars Mahinovs]

(Note: why the reply-to is not set to the list?)

On 12/3/05, Sandis Neilands <sandisn at gmail.com> wrote:
>  Few suggestions:
>  1. In case of manual backups, backgrounding process is bad idea. What if it
> fails? And even if it won't, i'd like to know, what it is doing and when
> will it finish. I can't easily cancel it eihter. Backgrounding should be
> optional not default.

How about this - the backup process it self is in the back ground, but
its progress is shown by a panel applet with optional window with a
bit more progress info. They could communicate via dbus or a pipe.

>  2. Stephen Hemminger mentioned already that restore is more important than
> backup itself. Sbackup is only usable in gnome, but what if user runs kde?
> And lack of CLI is really important, since sbackup is not usable in rescue
> mode (in case x or gnome is broken OR machine is server OR machine is
> administrated via ssh, etc.)

There is a CLI tool srestore.py which is also a Python library
providing a Python class where all the restore funcionality actually
is implemented. The graphical version only calls that library for
restore.

>  3. If sbackup worked in CLI it should include itself in every backup, but
> it shouldn't be compressed. This would help in situations,  when user
> decides to switch to another distro, where sbackup is not included. It would
> also help, if /usr/sbin  is (accidentaly) deleted or damaged, but it was
> included in last backup.

Currently backups are simple tar.gz files. Planned changes include
making several .tar.gz files (see below) and slitting one .tar.gz file
into cat'able chunks for recording to small media and to overcome 2 Gb
file size limits on some filesystems. If this is docummented then I
see no real reason to include sbackup (or srestore) into a backup
snapshot.

>  4. User data should be seperated from system data (seperate archives). When
> I'll upgrade to drake or change distro I would like to have an option to
> restore only user data, not /bin, /usr, /etc, etc. This would also let me
> easily get rid of old system data, which won't be used anyway, but still
> keep useful user data archives.

Good point, this will be done as a consequence of packing each users
data in a separate archive which must be done for security need anyway
(if we want to allow users to restore their own file without root
rights).

>  5. Ordinary (non-root/sudo) users should have a right to use this tool too.

Here are 3 use cases:
* user restores his files
* user backups his files
* user adjusts system-wide backup's preferences within his home directory

>  Have you checked other backup tools included in ubuntu? I haven't so
> perhaps it is  possible to build upon them?

Yes I have checked them out and I build on tar. Otherwise I think that
it would be more productive to build with the people that have written
these tools, to cooperate on a single, better solution.

--
Best regards,
    Aigars Mahinovs        mailto:aigarius at debian.org
 #--------------------------------------------------------------#
 |     .''`.         Debian GNU/Linux              LAKA         |
 |    : :' :      http://www.debian.org  &  http://www.laka.lv  |
 |    `. `'                                                     |
 |      `-                                                       |
 #--------------------------------------------------------------#