[Digikam-users] Migration problems - Digikam 1.8 to 2.0

[Jean-François Rabasse]

Hello,

A comment about backups :

On Tue, 13 Sep 2011, Photonoxx wrote:

> The second key is making backup. I think having two backup is
> good. One made when you import your pictures from camera or memory
> card (Rapid-Photo-Downloader make this perfectly) and an other
> made regularly from your working directory to have a backup of the
> modification you made to your files.
> 
> In the worse case, you still can get back your files "backuped"
> from "out of the camera".

I fully agree with the concept of two different backups, because an
image (from a photographer's point of view) is not one file but,
at least, two; and a formulation written by David,

On Tue, 13 Sep 2011, David Vincent-Jones wrote:

> We Linux photographers, are now in the enviable position of having
> a plethora of fine products to turn our raw material into finished
> images etc.

is excellent. True, we have the "raw material" file, and the
"finished image" file. So, having a backup (or one should rather say
an archive) of raw files, just in case, plus periodic backups of
finished images (may be tagged, as the raw file is preserved:-)
seems to be a safe way.

As for databases themselves, good backups should prefer databases
dumps, rather than the binary .db file(s).

For those not very familiar with SQL databases, a DB dump is a
(huge) text file, containing all the SQL commands needed to recreate
then repopulate a database from scratch. And it's a very important
interchange tool when changins software versions. In some cases,
a binary .db file may raise problems with a newer version of the DB
software. Doing a dump with the older version, then recreating with
the newer version could allow transitions without problems.

With SQLite, doing a dump will be one command :
     sqlite3 digikam4.db .dump > dk-dump.sql

(mind the dot before the keyword .dump)
and you get a text file containing all SQL commands to rebuild.

When you want to rebuild from scratch, you don't even need to have
already a database file, it will be created on the fly with the
command :
     sqlite3 test.db < dk-dump.sql

Can check it,
     sqlite3 -line test.db 'pragma integrity_check;'

then you can rename test.db to digikam4.db

(Also, the SQL dump format allows possible migration of your data to
another DB software, e.g. MySQL or PostgreSQL.)

I think that this text format is more flexible than the binary
format and doing backups with dumped versions of databases is safe
for a longer term.
(Those files are large, but it's only text and can be gzip'ed)

Jean-François