Backup Feature (Issue 68)
Gokturk Yuksek
I've been tinkering on this backup problem for some time. As it's been
discussed in the issue page, it's essential to have a system that backs
up the database, in case something bad happens. My proposal is as follows:
- Initially, save the digest of the database in a file (say
cards.digest). Make a compressed copy of the current database (say
cards-2011-10-11.tar.gz), preferably under a separate folder called
"backup".
- Every time ARDB starts up, calculate the digest of the current
database, compare it to the one in the digest file. If the digests
differ, make a backup, update the digest file.
Even though a single database file is roughly ~4MB, it can be compressed
below 1MB. Also with the digest comparison we avoid unnecessary backups.
To restore a backup, we can simply:
- Rename the current database to something temporary (cards.db.tmp) so
that if the restore process fails somehow can quickly recover.
- Uncompress the requested backup file.
- Update the digest file.
- Treat this operation just like a database update.
I found an implementation of Whirlpool[1] in the public domain. It's
written in C but I'm almost done with converting it to C++. The
remaining part of the work is to implement a "DatabaseBackup" class,
independent of the underlying hash function for the reasons I'll talk
about later, and integrate this functionality into ARDB.
WxWidgets seems to provide a nice API for data compression, so we don't
need to worry about that.
This type of setup does not add extra build dependencies so we do not
need to worry about supporting multiple OSes. There are several
drawbacks though:
* Whirlpool implementation that I have takes about one second to
generate the digest on a Intel Core2 Duo 2.0Ghz CPU. Another 0.5s will
add up from the compression process. So each startup will be delayed by
about 2 seconds.
* People may want to use the shared crypto libraries on their systems
to create the digest rather than the one we have. That was the reason
why I said the backup class should be independent of the underlying hash
function. This will add some complexity to the code and to the build
process as well.
* We still need a GUI to make this process user friendly. Unfortunately
my GUI skills are not good enough to do that, nor have I time to spend
on improving it.
Comments are welcome ...
[1] http://en.wikipedia.org/wiki/Whirlpool_%28cryptography%29
--
Gokturk Yuksek
Graham Smith
I'm not really working on ardb anymore. But Robert is. I'm happy to point you in the right direction but unfortunately I just do not have the time to build, test or release ardb anymore :-(
G.
> --
> You received this message because you are subscribed to the Google Groups "ardb-devel" group.
> To post to this group, send email to ardb-...@googlegroups.com.
> To unsubscribe from this group, send email to ardb-devel+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/ardb-devel?hl=en.
>