Journal Backup/Restore UI

Bernie Innocenti bernie at
Thu Mar 25 18:51:09 EDT 2010

In Paraguay, we started discussing the topic of improving backup and
restore procedures. Let's compare notes with a wider audience.

We started from an existing backup/restore procedure written by Daniel
Drake one year ago. It's meant to be invoked from the Terminal and uses
a transactional approach:

1) the technician runs a script to restore the journal from the school
server into a temporary directory while Sugar is still running;

2) then, you restart Sugar (by killing the sugar-shell process);

3) on startup, the olpc-session script notices the temporary directory
    and replaces the datastore with it almost atomically.

The problem with this approach was that it only works as long as there's
a enough free space in the filesystem, which is rarely the case with
laptops that are actually in use. Transactional behavior would be good
to have, but I don't see how we could implement it reliably. Even an
rsync in-place would have to be done with --delete-before to ensure it
works all the time.

This opens the question of how we stop the datastore from accessing the
journal and mess it up while we're still updating it. We're currently
doing it quite a gross way: kill the datastore process before beginning
the restore, then restart Sugar:

We'll thoroughly test this new kludge tomorrow. I'm confident it will
work, but it's a shame that users need to call tech support in order to
restore a backup.

Perhaps it's time to add integrated backup/restore functionality to the
datastore itself, with a nice UI in the Journal or in the control panel.
The underlying mechanism could be as simple as the one we're testing
now, but with proper synchronization with the datastore and no need to
restart Sugar.

Shall we go on and write a feature page, targeting 0.90? If it's done as
a control panel item, it may be sufficiently self-contained to backport
it all the way back to 0.84.

For the time being, I might add the backup and restore scripts to
olpc-utils. Or, better, create a new sugar-utils package for these
things that are generally useful on any platform.


   // Bernie Innocenti -
 \X/  Sugar Labs       -

More information about the Devel mailing list