[digiKam-users] Best practise for DigiKam backup?

Daniel Bauer linux at daniel-bauer.com
Tue Nov 23 16:28:21 GMT 2021

I see that people have very sophisticated back-up strategies. I for sure 
believe that back-ups are essential for many reasons, especially because 
all disks do fail one day, and as a professional photographer my image 
files are my wealth.

But I also think there is something like an expense/result ratio, and so 
my back-up strategy is somehow more relaxed and includes the possibility 
to lose some data in a very bad case.

First of all have the original camera files separated from digikam. 
Within digikam I work only with the camera-jpgs (for selection) and the 
processed .png from raw with Canon-software for further editing in 
Digikam and Gimp. I don't delete any raw files (I learned to miss thrown 
away negatives and slides because in one moment I thought they were not 
good enough...) nor do I do any changes on those raw files.

So I copy them from the camera-card to my computers disk (a physically 
separate disk that contains only those files). Then I add the new files 
to my raw-backup on an external disk. From time to time I update a 
second and a third external disk, of which one is kept on another 
location for the case of a fire or so.

I run the risk to lose the latest work if such a disaster occurs before 
the update of the disk I keep out of my house, but in such a case this 
probably would be my smallest problem... At least all earlier stuff is 
more or less safe.

Then my digikam is also on a physical separate disk in the computer. I 
use the SQlite database that is also on that disk. I back-up daily to 
one external disk and from time to time also to a second and third one, 
of which one is kept in another location, too.

For digikam I update using rsync with the --delete option, which means 
that files I delete will be deleted also on the back-ups and I cannot go 
back to older versions because they are overwritten with the last one. 
But I don't remember a case where I missed an earlier version, and 
should that ever happen I can still start again from the original raw. I 
could also lose my latest edits since my last update of the 
out-of-the-house-back-up in case of a disaster.

I believe that for me that risk is acceptable while the effort in time, 
organization and hardware to have incremental updates seems too much 
compared to what really could happen.

B.t.w., of my old negatives and slides I only have the originals. They 
are stored professionally and acid-free, but in case of fire or water 
they will be lost. The alternative would be a huge bank safe with it's 
enormous costs - and who knows if the one in the next safe doesn't store 
things with bugs who love to eat my negatives...

So I decided to store them "normal". The risk exists, but then: what is 
without risk in life?

Am 21.11.21 um 22:34 schrieb Jonathan Kamens:
> I will share my backup approach as well, but as with Thomas, I doubt the 
> way I do things is going to be exactly how anyone else wants to do them. 
> Rather, you may get some inspiration from my description about how you 
> want to handle things yourself.
> I'm a big believer in backups happening automatically. I don't want to 
> have to periodically copy/paste folders, or manually back up onto a 
> thumb drive or external drive, or anything like that. I just want the 
> backups to happen transparently in the background and tell me when 
> they're not working.
> Similarly, I'm a big believer in offsite backups. If your data is only 
> backed up to devices in your home, then you're not protected against a 
> disaster that destroys your home, and you're not protected against a 
> disaster which keeps you out of your home for an extended period of 
> time, and you're not protected against a burglar breaking into your home 
> and stealing all your devices.
> So:
>   * My digiKam database is stored in MariaDB rather than SQLite.
>   * My photos are stored on a Synology NAS accessed over CIFS from my
>     Linux boxes where I run digiKam.
>   * I do nightly backups of the digikam MariaDB database using
>     mariabackup, full backups every 45 days and incremental backups
>     between the full backups.
>   * My home-grown network backup scripts
>     <https://github.com/jikamens/jik-backup-utilities> back up my entire
>     photo archive and my database backups into Backblaze B2 storage
>     every night. (Note that the stuff at that link is partially obsolete
>     since I'm now using mariabackup for the database backups rather than
>     MySQL backup method described there; I haven't gotten around to
>     updating the stuff in Github to reflect my current usage.)
>   * Backblaze B2 saves old versions of deleted files, so if one of my
>     photos somehow gets corrupted by digiKam or some other tool I can
>     restore from an old version.
>   * However, I don't want to pay to store those old versions of photos
>     forever, so I periodically run "jpeginfo -c" on the current versions
>     of all the photos that have old versions saved, and if jpeginfo says
>     the current version is OK, I purge the old versions. (Face-tagging
>     is the biggest culprit for modifying files and causing old versions
>     to be saved, since I have digiKam configured to save all metadata
>     into the photo files for maximum interoperability with things like
>     Synology Photos.)
> By the way, I've only just recently started using digiKam, and may I 
> just say how grateful I am to the people who have worked on it for 
> finally creating a photo management tool that runs on Linux that is 
> robust enough for me to finally stop using my old copy of Picasa. I am 
> especially grateful for the face recognition features and for the fact 
> that digiKam supports MariaDB as a backend. Thank you!
> jik

Daniel Bauer photographer Basel Málaga

More information about the Digikam-users mailing list