[gentoo-user-de] Akonadi

[Sebastian Kürschner]

Hallo,

Akonadi startet hier nicht richtig. Folgende Fehlermeldungen erhalte ich beim Start von Kontact.


MYSQL Serverprotokoll enthÀlt Fehler.

170526 13:48:01 [Note] InnoDB: Using mutexes to ref count buffer pool pages
170526 13:48:01 [Note] InnoDB: The InnoDB memory heap is disabled
170526 13:48:01 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
170526 13:48:01 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
170526 13:48:01 [Note] InnoDB: Compressed tables use zlib 1.2.11
170526 13:48:01 [Note] InnoDB: Using Linux native AIO
170526 13:48:01 [Note] InnoDB: Not using CPU crc32 instructions
170526 13:48:01 [Note] InnoDB: Initializing buffer pool, size = 80.0M
170526 13:48:01 [Note] InnoDB: Completed initialization of buffer pool
170526 13:48:01 [Note] InnoDB: Highest supported file format is Barracuda.
170526 13:48:01 [Note] InnoDB: Log scan progressed past the checkpoint lsn 7035871685
170526 13:48:01 [Note] InnoDB: Database was not shutdown normally!
170526 13:48:01 [Note] InnoDB: Starting crash recovery.
170526 13:48:01 [Note] InnoDB: Reading tablespace information from the .ibd files...
170526 13:48:01 [Note] InnoDB: Restoring possible half-written data pages
170526 13:48:01 [Note] InnoDB: from the doublewrite buffer...
170526 13:48:06 [ERROR] InnoDB: Tried to read 16384 bytes at offset 64208896. Was only able to read 12288.
2017-05-26 13:48:06 7f7699b06740 InnoDB: Operating system error number 5 in a file operation.
InnoDB: Error number 5 means 'Input/output error'.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/operating-system-error-codes.html
170526 13:48:06 [ERROR] InnoDB: File (unknown): 'read' returned OS error 105. Cannot continue operation

Akonai-Steuerprogram nicht am D-Bus registriert

Das Akonadi-Steuerprogramm ist nicht am D-Bus registriert, was normalerweise bedeutet, dass es nicht gestartet wurde oder beim Start ein schwerer Fehler aufgetreten ist.


Database process exited unexpectedly during initial connection!
executable: "/usr/sbin/mysqld"
arguments: ("--defaults-file=/home/sebastian/.local/share/akonadi/mysql.conf", "--datadir=/home/sebastian/.local/share/akonadi/db_data/", "--socket=/tmp/akonadi-sebastian.P5dJCT/mysql.socket")
stdout: ""
stderr: "170526 13:48:01 [Note] /usr/sbin/mysqld (mysqld 10.0.30-MariaDB) starting as process 31402 ...
"
exit code: 1
process error: "Process operation timed out"
"[
0: akonadiserver(_Z11akBacktracev+0x4b) [0x463a6b]
1: akonadiserver() [0x463cf2]
2: /lib64/libc.so.6(+0x331f0) [0x7f4ed4fae1f0]
3: /lib64/libc.so.6(gsignal+0x37) [0x7f4ed4fae167]
4: /lib64/libc.so.6(abort+0x16a) [0x7f4ed4faf5ea]
5: /usr/lib64/qt4/libQtCore.so.4(_Z17qt_message_output9QtMsgTypePKc+0x8d) [0x7f4ed68ae18d]
6: akonadiserver(_ZN15FileDebugStream9writeDataEPKcx+0xad) [0x465bad]
7: /usr/lib64/qt4/libQtCore.so.4(_ZN9QIODevice5writeEPKcx+0x9f) [0x7f4ed6954b9f]
8: /usr/lib64/qt4/libQtCore.so.4(+0x125cb5) [0x7f4ed6962cb5]
9: /usr/lib64/qt4/libQtCore.so.4(_ZN11QTextStreamD1Ev+0x31) [0x7f4ed696c9f1]
10: akonadiserver(_ZN6QDebugD1Ev+0x48) [0x45e7c8]
11: akonadiserver(_ZN7Akonadi6Server13DbConfigMysql19startInternalServerEv+0x1ecb) [0x4d53ab]
12: akonadiserver(_ZN7Akonadi6Server13AkonadiServer20startDatabaseProcessEv+0xff) [0x46681f]
13: akonadiserver(_ZN7Akonadi6Server13AkonadiServer4initEv+0xb8) [0x468ed8]
14: akonadiserver() [0x536719]
15: /usr/lib64/qt4/libQtCore.so.4(_ZN7QObject5eventEP6QEvent+0x1d1) [0x7f4ed69e9871]
16: /usr/lib64/qt4/libQtCore.so.4(_ZN16QCoreApplication14notifyInternalEP7QObjectP6QEvent+0x8c) [0x7f4ed69cf0ac]
17: /usr/lib64/qt4/libQtCore.so.4(_ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData+0x365) [0x7f4ed69d2625]
18: /usr/lib64/qt4/libQtCore.so.4(+0x1c343e) [0x7f4ed6a0043e]
19: /usr/lib64/libglib-2.0.so.0(g_main_context_dispatch+0x244) [0x7f4ed4678384]
20: /usr/lib64/libglib-2.0.so.0(+0x4c665) [0x7f4ed4678665]
21: /usr/lib64/libglib-2.0.so.0(g_main_context_iteration+0x2c) [0x7f4ed467872c]
22: /usr/lib64/qt4/libQtCore.so.4(_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE+0x7e) [0x7f4ed6a005be]
23: /usr/lib64/qt4/libQtCore.so.4(_ZN10QEventLoop13processEventsE6QFlagsINS_17ProcessEventsFlagEE+0x41) [0x7f4ed69cd821]
24: /usr/lib64/qt4/libQtCore.so.4(_ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE+0x1b5) [0x7f4ed69cdbd5]
25: /usr/lib64/qt4/libQtCore.so.4(_ZN16QCoreApplication4execEv+0x99) [0x7f4ed69d3799]
26: akonadiserver(main+0x1e5) [0x45dbe5]
27: /lib64/libc.so.6(__libc_start_main+0xf0) [0x7f4ed4f9b790]
28: akonadiserver(_start+0x29) [0x45e509]
]
"

Gruß
Sebastian

[Kai Krakow]

Am Fri, 26 May 2017 13:58:05 +0200 (CEST)

Post by Sebastian Kürschner
Hallo,
Akonadi startet hier nicht richtig. Folgende Fehlermeldungen erhalte
ich beim Start von Kontact.
MYSQL Serverprotokoll enthält Fehler.
170526 13:48:01 [Note] InnoDB: Using mutexes to ref count buffer pool
pages 170526 13:48:01 [Note] InnoDB: The InnoDB memory heap is
disabled 170526 13:48:01 [Note] InnoDB: Mutexes and rw_locks use GCC
atomic builtins 170526 13:48:01 [Note] InnoDB: GCC builtin
__atomic_thread_fence() is used for memory barrier 170526 13:48:01
[Note] InnoDB: Compressed tables use zlib 1.2.11 170526 13:48:01
Completed initialization of buffer pool 170526 13:48:01 [Note]
InnoDB: Highest supported file format is Barracuda. 170526 13:48:01
[Note] InnoDB: Log scan progressed past the checkpoint lsn 7035871685
170526 13:48:01 [Note] InnoDB: Database was not shutdown normally!
170526 13:48:01 [Note] InnoDB: Starting crash recovery. 170526
13:48:01 [Note] InnoDB: Reading tablespace information from the .ibd
files... 170526 13:48:01 [Note] InnoDB: Restoring possible
half-written data pages 170526 13:48:01 [Note] InnoDB: from the
doublewrite buffer... 170526 13:48:06 [ERROR] InnoDB: Tried to read
16384 bytes at offset 64208896. Was only able to read 12288.
2017-05-26 13:48:06 7f7699b06740 InnoDB: Operating system error
number 5 in a file operation. InnoDB: Error number 5 means
'Input/output error'. InnoDB: Some operating system error numbers are
http://dev.mysql.com/doc/refman/5.6/en/operating-system-error-codes.html
170526 13:48:06 [ERROR] InnoDB: File (unknown): 'read' returned OS
error 105. Cannot continue operation

Sieht aus, als wäre die MySQL-Datei von Akonadi beschädigt, und
außerdem die InnoDB-Log-Datei... Da wird es vermutlich einfacher, das
neu aufzusetzen. Gibt es Backups von deinen Mails?

Die Frage ist eigentlich auch, wie das passieren konnte. Verwendest du
dein Dateisystem mit nobarrier?

Post by Sebastian Kürschner
Akonai-Steuerprogram nicht am D-Bus registriert

Das ist nur ein Folgefehler, diesen und nachfolgende Fehler kannst du
vorab ignorieren.

Post by Sebastian Kürschner
Das Akonadi-Steuerprogramm ist nicht am D-Bus registriert, was
normalerweise bedeutet, dass es nicht gestartet wurde oder beim Start
ein schwerer Fehler aufgetreten ist.
Database process exited unexpectedly during initial connection!
executable: "/usr/sbin/mysqld"
("--defaults-file=/home/sebastian/.local/share/akonadi/mysql.conf",
"--datadir=/home/sebastian/.local/share/akonadi/db_data/",
"--socket=/tmp/akonadi-sebastian.P5dJCT/mysql.socket") stdout: ""
stderr: "170526 13:48:01 [Note] /usr/sbin/mysqld (mysqld
10.0.30-MariaDB) starting as process 31402 ... " exit code: 1 process
error: "Process operation timed out" "[
0: akonadiserver(_Z11akBacktracev+0x4b) [0x463a6b]
1: akonadiserver() [0x463cf2]
2: /lib64/libc.so.6(+0x331f0) [0x7f4ed4fae1f0]
3: /lib64/libc.so.6(gsignal+0x37) [0x7f4ed4fae167]
4: /lib64/libc.so.6(abort+0x16a) [0x7f4ed4faf5ea]
5: /usr/lib64/qt4/libQtCore.so.4(_Z17qt_message_output9QtMsgTypePKc+0x8d)
akonadiserver(_ZN15FileDebugStream9writeDataEPKcx+0xad) [0x465bad]
7: /usr/lib64/qt4/libQtCore.so.4(_ZN9QIODevice5writeEPKcx+0x9f)
[0x7f4ed6954b9f] 8: /usr/lib64/qt4/libQtCore.so.4(+0x125cb5)
[0x7f4ed6962cb5]
9: /usr/lib64/qt4/libQtCore.so.4(_ZN11QTextStreamD1Ev+0x31)
[0x7f4ed696c9f1] 10: akonadiserver(_ZN6QDebugD1Ev+0x48) [0x45e7c8]
akonadiserver(_ZN7Akonadi6Server13DbConfigMysql19startInternalServerEv+0x1ecb)
akonadiserver(_ZN7Akonadi6Server13AkonadiServer20startDatabaseProcessEv+0xff)
akonadiserver(_ZN7Akonadi6Server13AkonadiServer4initEv+0xb8)
[0x468ed8] 14: akonadiserver() [0x536719]
15: /usr/lib64/qt4/libQtCore.so.4(_ZN7QObject5eventEP6QEvent+0x1d1) [0x7f4ed69e9871]
16: /usr/lib64/qt4/libQtCore.so.4(_ZN16QCoreApplication14notifyInternalEP7QObjectP6QEvent+0x8c)
[0x7f4ed69cf0ac]
17: /usr/lib64/qt4/libQtCore.so.4(_ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData+0x365)
[0x7f4ed69d2625] 18: /usr/lib64/qt4/libQtCore.so.4(+0x1c343e)
[0x7f4ed6a0043e]
19: /usr/lib64/libglib-2.0.so.0(g_main_context_dispatch+0x244)
[0x7f4ed4678384] 20: /usr/lib64/libglib-2.0.so.0(+0x4c665)
[0x7f4ed4678665]
21: /usr/lib64/libglib-2.0.so.0(g_main_context_iteration+0x2c)
[0x7f4ed467872c]
22: /usr/lib64/qt4/libQtCore.so.4(_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE+0x7e)
[0x7f4ed6a005be]
23: /usr/lib64/qt4/libQtCore.so.4(_ZN10QEventLoop13processEventsE6QFlagsINS_17ProcessEventsFlagEE+0x41)
[0x7f4ed69cd821]
24: /usr/lib64/qt4/libQtCore.so.4(_ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE+0x1b5)
[0x7f4ed69cdbd5]
25: /usr/lib64/qt4/libQtCore.so.4(_ZN16QCoreApplication4execEv+0x99)
[0x7f4ed69d3799] 26: akonadiserver(main+0x1e5) [0x45dbe5]
akonadiserver(_start+0x29) [0x45e509] ] "
Gruß
Sebastian

[Sven Eden]

Hallo allerseits.

Post by Kai Krakow

Post by Sebastian Kürschner
Akonadi startet hier nicht richtig. Folgende Fehlermeldungen erhalte
ich beim Start von Kontact.
170526 13:48:01 [Note] InnoDB: Database was not shutdown normally!
170526 13:48:01 [Note] InnoDB: Starting crash recovery. 170526
13:48:01 [Note] InnoDB: Reading tablespace information from the .ibd
files... 170526 13:48:01 [Note] InnoDB: Restoring possible
half-written data pages 170526 13:48:01 [Note] InnoDB: from the
doublewrite buffer... 170526 13:48:06 [ERROR] InnoDB: Tried to read
16384 bytes at offset 64208896. Was only able to read 12288.
2017-05-26 13:48:06 7f7699b06740 InnoDB: Operating system error
number 5 in a file operation. InnoDB: Error number 5 means
'Input/output error'. InnoDB: Some operating system error numbers are
http://dev.mysql.com/doc/refman/5.6/en/operating-system-error-codes.html
170526 13:48:06 [ERROR] InnoDB: File (unknown): 'read' returned OS
error 105. Cannot continue operation

Wieso wurde denn mysql nicht richtig beendet? Stromausfall oder so?

Naja, die Innodb ist hin.

Post by Kai Krakow
Sieht aus, als wäre die MySQL-Datei von Akonadi beschädigt, und
außerdem die InnoDB-Log-Datei... Da wird es vermutlich einfacher, das
neu aufzusetzen. Gibt es Backups von deinen Mails?

Alle Mails sind entweder auf dem Server oder dem Dateisystem. Die Datenbank
von Akonadi ist nur für die Organisation und Metadatensuche.

Post by Kai Krakow
Die Frage ist eigentlich auch, wie das passieren konnte. Verwendest du
dein Dateisystem mit nobarrier?

"InnoDB: Database was not shutdown normally!" - Und das mitten im
Schreibprozess. Die InnoDB ist *eigentlich* sehr robust.


Gruß

Sven

[Kai Krakow]

Am Sat, 27 May 2017 09:18:43 +0200

Post by Sven Eden
Hallo allerseits.

Post by Sebastian Kürschner
Akonadi startet hier nicht richtig. Folgende Fehlermeldungen
erhalte ich beim Start von Kontact.
170526 13:48:01 [Note] InnoDB: Database was not shutdown normally!
170526 13:48:01 [Note] InnoDB: Starting crash recovery. 170526
13:48:01 [Note] InnoDB: Reading tablespace information from
the .ibd files... 170526 13:48:01 [Note] InnoDB: Restoring
Tried to read 16384 bytes at offset 64208896. Was only able to
read 12288. 2017-05-26 13:48:06 7f7699b06740 InnoDB: Operating
system error number 5 in a file operation. InnoDB: Error number 5
means 'Input/output error'. InnoDB: Some operating system error
http://dev.mysql.com/doc/refman/5.6/en/operating-system-error-codes.html
170526 13:48:06 [ERROR] InnoDB: File (unknown): 'read' returned OS
error 105. Cannot continue operation

Wieso wurde denn mysql nicht richtig beendet? Stromausfall oder so?
Naja, die Innodb ist hin.

Richtig...

Post by Sven Eden

Sieht aus, als wÀre die MySQL-Datei von Akonadi beschÀdigt, und
außerdem die InnoDB-Log-Datei... Da wird es vermutlich einfacher,
das neu aufzusetzen. Gibt es Backups von deinen Mails?

Alle Mails sind entweder auf dem Server oder dem Dateisystem. Die
Datenbank von Akonadi ist nur fÃŒr die Organisation und Metadatensuche.

Werden nicht sehr kleine Objekte direkt in der Datenbank gespeichert
und nicht extern? Die wÀren dann doch auch weg?

Post by Sven Eden

Die Frage ist eigentlich auch, wie das passieren konnte. Verwendest
du dein Dateisystem mit nobarrier?

"InnoDB: Database was not shutdown normally!" - Und das mitten im
Schreibprozess. Die InnoDB ist *eigentlich* sehr robust.

Ja, eigentlich... Wenn man allerdings die Ordering-Garantien des
Dateisystems abschaltet, geht die beim Absturz/Reset/Stromausfall nun
mal kaputt, zumindest wenn gerade darin geschrieben wird.
HDD-Schreibcache und nobarrier können da beide sehr böse Fallen werden,
die aber in fast jedem einfachen Tuning-Tutorial immer wieder erwÀhnt
werden. InnoDB muss sich auf den unterliegenden Storage-Stack verlassen
können, sonst funktioniert es nicht.

[Sven Eden]

Post by Kai Krakow

Post by Sven Eden
Alle Mails sind entweder auf dem Server oder dem Dateisystem. Die
Datenbank von Akonadi ist nur für die Organisation und Metadatensuche.

Werden nicht sehr kleine Objekte direkt in der Datenbank gespeichert
und nicht extern? Die wären dann doch auch weg?

Ja, stimmt. Bis zu 4096 Bytes Größe. :-/

Das sind auch gerne mal Adress- oder Kalendereinträge. E-Mails kann man ja
erneut herunterladen.

Aber was hilfts? Die InnoDB ist futsch... :-(

[Kai Krakow]

Am Sat, 27 May 2017 10:58:30 +0200

Post by Kai Krakow

Post by Sven Eden
Alle Mails sind entweder auf dem Server oder dem Dateisystem. Die
Datenbank von Akonadi ist nur fÃŒr die Organisation und
Metadatensuche.

Werden nicht sehr kleine Objekte direkt in der Datenbank gespeichert
und nicht extern? Die wÀren dann doch auch weg?

Ja, stimmt. Bis zu 4096 Bytes Größe. :-/
Das sind auch gerne mal Adress- oder KalendereintrÀge. E-Mails kann
man ja erneut herunterladen.

Per POP3 geholte Mails sind normalerweise nicht mehr auf einem Server...

Aber was hilfts? Die InnoDB ist futsch... :-(

Legt Akonadi nicht von selbst regelmÀßig Backups an als ZIP oder so?
Ich meine das mal irgendwann gesehen zu haben, finde das aktuell aber
nicht mehr wieder.

Aber ich finde aktuell nicht mal Akonadi in den System Settings oder
dem Tray. Was fehlt mir?

[Sven Eden]

Post by Kai Krakow
Per POP3 geholte Mails sind normalerweise nicht mehr auf einem Server...

Alles eine Frage der Einstellungen. Ich hatte, vor dem Umstieg auf IMAP,
meinen GMX-Agenen so eingestellt, das bis zu 980MB auf dem Server verbleiben
sollen.
Ich kann mich aber beim besten Willen nicht daran erinnern, was der Standard
war. Alles herunterladen, und nichts auf dem Server belassen, oder?

Post by Kai Krakow

Post by Sven Eden
Aber was hilfts? Die InnoDB ist futsch... :-(

Legt Akonadi nicht von selbst regelmäßig Backups an als ZIP oder so?
Ich meine das mal irgendwann gesehen zu haben, finde das aktuell aber
nicht mehr wieder.

Nicht, dass ich wüsste...

Post by Kai Krakow
Aber ich finde aktuell nicht mal Akonadi in den System Settings oder
dem Tray. Was fehlt mir?

Wir User sind nicht fähig Akonadi per GUI zu konfigurieren, also gibt es nur
noch
A) ~/.config/akonadi/akonadiserverrc
B) ~/.config/akonadi_maildir_resource_0rc und ...
C) /usr/bin/akonadiconsole (<-- HA, doch GUI)

Zu B) : Hierin steht der Pfad zum Lokalen Ordner. Alle Mails darin finden sich
hier im Dateisystem wieder.

Weiterhin gibt es noch
~/.config/akonadi_imap_resource_*rc für IMAP, und sicherlich eine Entsprechung
für POP3. Zumindes in den IMAP-Resourcen steht aber leider nicht drin, wo die
Mails lokal gespeichert werden.
Allerdings tippe hier ganz stark auf
~/.local/share/akonadi/file_db_data

Letztendlich sind alle Daten bis 4096 Bytes weg, sofern sie nicht erneut vom
Server heruntergeladen werden können, wenn man die Datenbank löscht. Alles
Andere ist im Dateisystem gespeichert. Ob das nach dem Löschen der Datenbank
auch alles brav wieder indiziert wird, weiß ich leider nicht.

Gruß

Sven

[Kai Krakow]

Am Wed, 31 May 2017 09:01:35 +0200

Post by Sven Eden

Post by Kai Krakow
Per POP3 geholte Mails sind normalerweise nicht mehr auf einem Server...

Alles eine Frage der Einstellungen. Ich hatte, vor dem Umstieg auf
IMAP, meinen GMX-Agenen so eingestellt, das bis zu 980MB auf dem
Server verbleiben sollen.
Ich kann mich aber beim besten Willen nicht daran erinnern, was der
Standard war. Alles herunterladen, und nichts auf dem Server
belassen, oder?

Post by Kai Krakow

Post by Sven Eden
Aber was hilfts? Die InnoDB ist futsch... :-(

Legt Akonadi nicht von selbst regelmÀßig Backups an als ZIP oder so?
Ich meine das mal irgendwann gesehen zu haben, finde das aktuell
aber nicht mehr wieder.

Nicht, dass ich wÃŒsste...

Post by Kai Krakow
Aber ich finde aktuell nicht mal Akonadi in den System Settings oder
dem Tray. Was fehlt mir?

Wir User sind nicht fÀhig Akonadi per GUI zu konfigurieren, also gibt
es nur noch
A) ~/.config/akonadi/akonadiserverrc
B) ~/.config/akonadi_maildir_resource_0rc und ...
C) /usr/bin/akonadiconsole (<-- HA, doch GUI)

Ganz ehrlich: Ich kann's verstehen, wirkten diese Dialoge doch eher wie
Entwickler-Werkzeuge als Enduser-Dialoge. Wahrscheinlich waren Sie auch
nie was anderes...

Zu C) Stimmt, ich hatte die Debug-Console ein wenig vergessen, hier
finden sich sogar die Einstellungsdialoge wieder... Auf dem "Agents"
Reiter.

Post by Sven Eden
Zu B) : Hierin steht der Pfad zum Lokalen Ordner. Alle Mails darin
finden sich hier im Dateisystem wieder.
Weiterhin gibt es noch
~/.config/akonadi_imap_resource_*rc fÃŒr IMAP, und sicherlich eine
Entsprechung fÃŒr POP3. Zumindes in den IMAP-Resourcen steht aber
leider nicht drin, wo die Mails lokal gespeichert werden.
Allerdings tippe hier ganz stark auf
~/.local/share/akonadi/file_db_data
Letztendlich sind alle Daten bis 4096 Bytes weg, sofern sie nicht
erneut vom Server heruntergeladen werden können, wenn man die
Datenbank löscht. Alles Andere ist im Dateisystem gespeichert. Ob das
nach dem Löschen der Datenbank auch alles brav wieder indiziert wird,
weiß ich leider nicht.

Bei meinem letzten Crash wurden die alle nie wieder korrekt indiziert,
die waren zwar irgendwie da aber irgendwie auch nicht. Bei einem Check
wurde dann alles nach lost+found verschoben und Akonadi konnte nichts
mehr damit anfangen, weil die Meta-Infos fehlen, die beim Abruf oder
Sync angelegt werden.

Das ist inzwischen aber Jahre her, Akonadi hat sich seitdem verÀndert
und verbessert - ein bisschen bezweifle ich aber, dass das je wieder
indiziert werden kann, da einfach die Meta-Infos aus der DB fehlen. Ich
hab mal in den Code geschaut, und Akonadi scheint ziemlich essentiell
darauf angewiesen zu sein und kann mit den Objekten sonst nichts
anfangen und verbannt die nach lost+found. Von da aus könnte ich die
zwar mit etwas Script-Fu in ein Maildir verfrachten und dann wieder
importieren... Schön und zuverlÀssig geht allerdings anders. Zumal auch
jegliche Info verloren geht, in welche Ordner sich die Objekte verteilt
hatten.

RegelmÀßige Backups helfen und tun nicht wirklich weh. Wenn
Speicherplatz ein teures Gut ist, kann ich Borgbackup empfehlen: Sehr
schnell und extrem speichereffizient. Sichert tÀglich mein System (2TB,
viele Millionen Dateien) innerhalb von 10-15 Minuten, und bereits knapp
ein Jahr Backup passen auf eine 3TB Platte (ich sichere also alles und
behalte es auch tÀglich, mit AusdÌnnung nach einigen Wochen).