Looking at the user’s home directory I see there are lots of files in ~/.local/share/akonadi/db_data/. Considering that it is a live database I suppose it would be highly incorrect to simply copy the files and I should rather make a database dump. On the other hand being logged in as root in mysql and running ‘show databases;’ does not show a database for akonadi at all which means I can’t even find a way to dump the database to an .sql file.
The next (maybe not the wisest) idea which came to my mind: maybe I could run a before-backup script which stops the service, then run the backup, then restart the service. However I don’t even find a service named akonadi in YaST.
The next (maybe not the wisest) idea which came to my mind: maybe I could run a before-backup script which stops the service, then run the backup, then restart the service. However I don’t even find a service named akonadi in YaST.
It runs as user and is no system service.
Use “akonadictl stop” to stop it.
Another option: run akonaditray, right-click on the tray icon (it’s hidden normally so click on the up arrow in the tray) and choose “Make Backup…”.
But, as the Akonadi database is just a cache, it isn’t really necessary to back it up. Although some things can get confused when the database is lost, e.g. filters only store the database id for destination folders.
How can I use this to make a mysqldump of the database?
It runs as user and is no system service.
Use “akonadictl stop” to stop it.
Yes, I found that info in the meantime. But is it good to stop it and restart it after backup completion (i.e. copy all separate files). Isn’t the right approach with DBs to dump them to a single file and copy that one?
Another option: run akonaditray, right-click on the tray icon (it’s hidden normally so click on the up arrow in the tray) and choose “Make Backup…”.
Unfortunately that is not an option as I am trying to automate the backup process.
But, as the Akonadi database is just a cache, it isn’t really necessary to back it up. Although some things can get confused when the database is lost, e.g. filters only store the database id for destination folders.
I didn’t know it was a cache but considering your further clarification I guess then it is better to have a backup after all?
mysql --socket=$HOME/.local/share/akonadi/socket-`hostname`/mysql.socket akonadi
(the “instance” part allows to run several Akonadi-Servers in parallel, but that’s normally not used.
And mysqldump accepts the same “–socket” parameter, so this should create a dump of the Akonadi database:
mysql --socket=$HOME/.local/share/akonadi/socket-`hostname`/mysql.socket akonadi
(replace $HOME accordingly, if you run this as different user)
Yes, I found that info in the meantime. But is it good to stop it and restart it after backup completion (i.e. copy all separate files). Isn’t the right approach with DBs to dump them to a single file and copy that one?
Yes. But you can just as well backup the actual database files. You just need to make sure the file permissions/ownership is ok afterwards (and mysql/akonadi shouldn’t be running when you restore the backup…)
I didn’t know it was a cache but considering your further clarification I guess then it is better to have a backup after all?
As I said, it is not really necessary (especially if you don’t use KMail), it doesn’t contain any data normally.
But, some data can temporarily exist in the cache only, until it is synchronized with the actual storage.
So yes, it’s probably better to back it up. If there are problems after restoring the backup, you can still delete the database…
Thanks. BTW this is also not the correct path. Actually the socket-hostname is a link to /tmp/akonadi-myusername.jlR8VV which does not exist at all. I tried to use the correct path to mysql.conf but then:
# mysql --socket=$HOME/.local/share/akonadi/mysql.conf akonadi
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/home/myusername/.local/share/akonadi/mysql.conf' (111 "Connection refused")
Akonadi has to be running for the socket to exist.
And you should really use $HOME/.local/share/akonadi/instance/$1/socket-hostname, the actual folder in /tmp can and will change.
I tried to use the correct path to mysql.conf but then:
…
Have we found a bug?
No, your command is wrong.
mysql.conf is the mysql config file, not a socket.
You cannot connect to that…
Ok, I see. ‘akonadictl status’ was showing that it was not running. When I start it manually I can do a mysqldump as you explained.
So as I read here and here it seems that service is running only if certain apps use it. Right?
In that case - to make a mysqldump correctly, should I include in my script commands to:
start akonadi (if not running)
mysqldump its db to a file.sql
stop akonadi (if it was not running before 1)
backup the file.sql
optionally delete file.sql
If that is a correct algorithm, that raises the question: how would the script start and stop the akonadi service? The script is running as user ‘bareos’ and the service obviously needs to be started as each individual human user. How would that be accomplished?
Right. It is only started if an application needs it, but then it keeps running until you stop it manually.
If that is a correct algorithm, that raises the question: how would the script start and stop the akonadi service? The script is running as user ‘bareos’ and the service obviously needs to be started as each individual human user. How would that be accomplished?
Or am I overthinking it?
IMHO yes. I would just backup the files, if anything. After all it’s only a cache…
Another option would be to use an external/system-wide mysql server for Akonadi (like I do), you will then backup the Akonadi database(s) together with the other databases anyway.
That might be the best option as I am backing up all mysql dabases anyway.
How do I configure Akonadi to use the system wide mysql? (I have mariadb installed and working)
BTW I notice something intersting in YaST: there is a package akonadi5 (not installed) but the installed one is named only akonadi. This system is upgraded from 13.2 to Leap. I wonder if I need to do some more upgrading (e.g. install akonadi5?)
BTW I notice something intersting in YaST: there is a package akonadi5 (not installed) but the installed one is named only akonadi. This system is upgraded from 13.2 to Leap. I wonder if I need to do some more upgrading (e.g. install akonadi5?)
Akonadi5 is part of the Qt5/KF5 based Akonadi/KDEPIM suite, i.e. kdepim5.
Akonadi is the KDE4 version, we still use KDEPIM4 by default in Leap for good reasons.
I would not recommending switching, KDEPIM5 does seem to have some (a lot?) problems still.
Btw, the akonadi server itself is in the package akonadi-runtime (akonadi-server for the Qt5 version).
akonadi/akonadi5 are just some KDE additions.
Thanks. Now I am able to start the akonadi server. However the option I remove is added back to the file. Is that normal? There are also 2 errors remaining when I click Test:
There are also 2 errors remaining when I click Test:
Those are “normal” and not really errors. So you can ignore them.
The first one says that there’s still an error log from a previous failed start.
To get rid of it, delete ~/.local/share/akonadi/akonadiserver.error.old, but that’s not really necessary.
The other one is because those agents don’t exist any more. akonadi_nepomuk_feeder has been replaced by baloo-pim, nothing to worry about.
No. Actually it had restored what I removed (line 21 in my last paste).
Those are “normal” and not really errors. So you can ignore them.
The first one says that there’s still an error log from a previous failed start.
To get rid of it, delete ~/.local/share/akonadi/akonadiserver.error.old, but that’s not really necessary.
The other one is because those agents don’t exist any more. akonadi_nepomuk_feeder has been replaced by baloo-pim, nothing to worry about.
Ok, good. Thanks.
Now after all is moved to the main mysql - which files/dirs in ~/.local/share/akonadi are safe to remove?
Now after all is moved to the main mysql - which files/dirs in ~/.local/share/akonadi are safe to remove?
The database is in ~/.local/share/akonadi/db_data/, you can remove that folder.
Btw, you just proved that you don’t have to backup the database…
Switching to an external mysql server is practically the same as wiping out the database, unless you import the old one manually.
Sorry to bring this back but I am stuck with this question:
Should I do this for every single user? (i.e. separate db for each user)
Also:
I notice that Amarok uses a similar strategy and I am currently trying to do the same for it. Are there any other KDE programs which can be migrated to the external mysql?
