[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kdepim-users
Subject:    Re: [kdepim-users] dimap,
From:       Martin Steigerwald <Martin () lichtvoll ! de>
Date:       2012-01-07 21:54:40
Message-ID: 201201072254.41138.Martin () lichtvoll ! de
[Download RAW message or body]

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=B4t 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=B4t 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=B4t =

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
[prev in list] [next in list] [prev in thread] [next in thread]