[kdepim-users] dimap, where are mails stored locally and how to back up?

[Martin Steigerwald]

Am Samstag, 7. Januar 2012 schrieb Dirk Sarpe:
> Hi Andras and thanks for the reply.
> 
> Andras Mantia wrote:
> > Dirk Sarpe wrote:
> >> How is one supposed to make a sensible
> >> backup of this?
> > 
> > The backup would be backing up the whole /.local/share/akonadi and
> > /.config/akonadi (for the akonadi data and config) and the .kde/ for
> > the generic kde config files, including KMail and Akonadi client
> > settings.
> > 
> > Restoring would be the same, again first the servers (akonadi, mysql)
> > need to be stopped. Stopping the akonadi server will stop mysql as
> > well.
> 
> I see three possible pathways at the moment:
> 
> 1. Backup at the IMAP server side directly
> 2. Backup using a tool on the backup machine that just fetches Mails
> from the IMAP server or since many mail providers offer IMAP and POP,
> use POP for this. Afterwards one can backup those mails locally to be
> on the save side, even if something strange to the IMAP server happens
> which gets synced to the machine. Incremental backup with rsync or a
> version control system with automatic commit after every sync might be
> a solution.
> 3. Local backup using only IMAP.  Stop the db, backup
> .local/share/akonadi and .config/akonadi and config files inside of
> .kde. Afterwards start the server again.
> 
> 
> Solution 3 is the only one that would keep not only the mails but also
> the whole metadata and Akonadi configuration intact. But I still have
> some questions here (sorry :):
> 
> Do the files inside .local/share/akonadi/file_db_data/ keep their
> names, or do they change?
> 
> There are some bigger binary files in db_data/ for one ib_logifle0 and
> ib_logifle1 (64 MB), do they need to be backed up or are they just
> logfiles which can be ignored?

They are InnoDB logfiles. mysqld needs these to recover to the latest state 
of the database in case of a crash or other sudden abort. I do not know 
whether their contents are needed after a clean shutdown of the database 
tough.

> The three other big files are ibdata1 (10 MB), akonadi/parttable.ibd
> (36 MB) and akonadi/pimitemtable.ibd (9 MB) I guess they are needed
> and they will add their full size in an incremental rsync backup
> during each run.

Rsync is capable of doing incremental within a file as long as it has not 
been renamed. It builds checksums on parts of the files and compares these 
to only transfer whats needed.

> I guess the relevant files inside .kde are all in /config,
> specificially AkonadiAgentServerrc, and all the akonadi* files. The
> akonadi* files in /apps all seem to be directories containing the
> cache of ical ressources (and several older versions of them). Sorry
> that I go into so much detail, but I want to keep the backup footprint
> small and their is at least one big file (nepomuk repository) and many
> small files which change rather frequently.

Aside from that I just backup the complete home directory.

Anyway I wouldn´t worry about rsync it can handle big files with changes in 
it just well. Thats at least my experience. But then I am currently 
rsyncing from an Intel SSD 320 to an 2 TB Hitachi harddisk and thats going 
in about 10 minutes for / and /home with about 215 GiB which includes all 
my POP3 mail - I am still using POP3. Anyway a backup of just Akonadi and 
Nepomuk stuff as well as mails should be faster and it didn´t take 
exceedingly long on my old ThinkPad T42 as well.

But then you might want to run the backup more frequently than I currently 
do and there volume and duration might become an issue. I still wouldn´t 
worry too much about it.

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
_______________________________________________
KDE PIM users mailing list
Subscription management: https://mail.kde.org/mailman/listinfo/kdepim-users