Owncloud Datenbank-Probleme

Es war mal wieder sehr warm. Meine Heim-Owncloud mit einem kleinen Raspberry Pi und einer externen USB-Platte ist etwas warm gelaufen. Die Festplatte mochte es nicht so und es gab so einige Probleme mit der Platte. Eine kleine Dateisystemreparatur löste die Probleme. Aber die SQLite-Datenbank, die ich verwende, mochte es nicht. Ich konnte keine neuen Ordner mehr anlegen und auch das Update versagte seinen Dienst. Die Fehlermeldung sah zum Beispiel so aus:

Doctrine\DBAL\Exception\DriverException: An exception occurred while executing ‘CREATE TEMPORARY TABLE __temp__oc_file_locks AS SELECT id, lock, “key”, ttl FROM oc_file_locks’:
SQLSTATE[HY000]: General error: 11 database disk image is malformed

SQLLite-Fehlermeldung beim Owncloud-Update

In solchen Fällen ist guter Rat nicht so teuer: der schlimmste Weg wäre gewesen, eine neue Owncloud-Instanz aufzusetzen, die Dateien zu laden und zu kopieren und schon wäre es wieder gelaufen. Aber ich wollte die alte Datenbank im besten Fall behalten. Also bin ich so mal in die Datenbank “reingelesen”.

Owncloud-Datenbank mit SQLite ansehen und checken

Im folgenden habe ich den SSH-Zugang zur Konsole genutzt und dort einen SQLite-Client installiert:

sudo apt-get install sqlite3

Die Handhabung von SQLite-Datenbanken ist sehr einfach: mit sqlite3 und dem Pfad zur Datenbank ist man direkt in der Datenbank. Ich bin als in den Ordner, wo die owncloud.db liegt (meistens im Ordner data im Owncloud-Ordner) und habe dort die Datenbank geöffnet:

sqlite3 owncloud.db

Die Tatsache, dass das noch ging, zeigt, dass noch nicht alles verloren ist. mit “.tables” habe ich auch gesehen, dass die Datenbanktabellen noch vorhanden sind. Das ist schon mal gut. Dann habe ich den Check der Datenbank gestartet:

sqlite> PRAGMA integrity_check;

mit dem Ergebnis:

*** in database main ***
Page 3488: btreeInitPage() returns error code 11
On tree page 3374 cell 40: Child page depth differs
On tree page 3374 cell 41: Child page depth differs
Page 3473: btreeInitPage() returns error code 11
On tree page 3374 cell 48: Child page depth differs
On tree page 3374 cell 49: Child page depth differs
Page 3474: btreeInitPage() returns error code 11
On tree page 3374 cell 51: Child page depth differs
On tree page 3374 cell 52: Child page depth differs
Page 3475: btreeInitPage() returns error code 11
On tree page 3374 cell 55: Child page depth differs
On tree page 3374 cell 56: Child page depth differs
Page 3476: btreeInitPage() returns error code 11
On tree page 3374 cell 58: Child page depth differs
On tree page 3374 cell 59: Child page depth differs
Page 3477: btreeInitPage() returns error code 11
On tree page 3374 cell 62: Child page depth differs
On tree page 3374 cell 63: Child page depth differs
Page 3479: btreeInitPage() returns error code 11
On tree page 3374 cell 65: Child page depth differs
On tree page 3374 cell 66: Child page depth differs
Page 3481: btreeInitPage() returns error code 11
On tree page 3374 cell 68: Child page depth differs
On tree page 3374 cell 69: Child page depth differs
Page 3486: btreeInitPage() returns error code 11
On tree page 3374 cell 89: Child page depth differs
On tree page 3374 cell 90: Child page depth differs
Page 3489: btreeInitPage() returns error code 11
On tree page 3374 cell 91: Child page depth differs
On tree page 3374 cell 92: Child page depth differs
Page 3478: btreeInitPage() returns error code 11
On tree page 3374 cell 100: Child page depth differs
Page 3483: btreeInitPage() returns error code 11
Page 3484: btreeInitPage() returns error code 11
Page 3487: btreeInitPage() returns error code 11
Page 3482: btreeInitPage() returns error code 11
Page 3480: btreeInitPage() returns error code 11
On tree page 838 cell 6: Child page depth differs
On tree page 838 cell 7: Child page depth differs
Page 3485: btreeInitPage() returns error code 11
Error: database disk image is malformed

Autsch, das sieht nicht nur nicht gut aus, das sieht ganz besonders schlecht aus. Mein Reparaturversuch, der auch funktionierte, was das anlegen eines Backups und das Wiedereinspielen des Backups. Das habe ich wie folgt gemacht:

Backup und Restore von SQLite-Datenbank mit einem SQL-Backup

In der offenen Konsole habe ich auf den SQL-Modus umgestellt mit INSERTS mit dem Kommando:

sqlite> .mode insert

Dann habe ich angegeben, wie die Backup-Datei heißen soll und das er bitte das Backup machen soll:

sqlite> .output owncloud.bak.sql
sqlite> .dump

Damit habe ich nun die bestehende Datenbank in ein SQL-File übertragen und in die Datei owncloud.bak.sql geschrieben. Jetzt lege ich eine neue Datenbank an, in die ich das Backup einspiele. Dafür beende ich zuerst mit “.exit” die aktuelle SQLite-Session und schließe meine “defekte” Datenbank.

Im nächsten Schritt lege ich die neue Datenbank an, in dem ich in der ssh-Session

sqlite3 owncoud.new.db

eingebe. Es öffnet sich nun wieder die Command Line von sqlite. Jetzt lasse ich die SQL-Befehle aus der Datei in die Datenbank schrieben. Das geht einfach mit dem Kommando:

.read owncloud.bak.sql

Mit einem anschließenden “.tables” kann ich sehen, ob in der neuen Datenbank die Tabellen angekommen sind. Mit etwas Glück kommt dann eine Liste von Tabellen:

oc_account_terms             oc_files_trash
oc_accounts                  oc_group_admin
oc_addressbookchanges        oc_group_user
oc_addressbooks              oc_groups
oc_appconfig                 oc_jobs
oc_authtoken                 oc_migrations
oc_calendarchanges           oc_mimetypes
oc_calendarobjects           oc_mounts
oc_calendars                 oc_notifications
oc_calendarsubscriptions     oc_preferences
oc_cards                     oc_privatedata
oc_cards_properties          oc_properties
oc_comments                  oc_schedulingobjects
oc_comments_read_markers     oc_share
oc_credentials               oc_share_external
oc_dav_shares                oc_storages
oc_external_applicable       oc_systemtag
oc_external_config           oc_systemtag_group
oc_external_mounts           oc_systemtag_object_mapping
oc_external_options          oc_trusted_servers
oc_federated_reshares        oc_users
oc_file_locks                oc_vcategory
oc_filecache                 oc_vcategory_to_object

Sieht alles so aus? Prima. Dann mit “.exit” die Command Line schließen und owncloud die neue Datenbank geben. Dafür habe ich die alte Datenbank zur Sicherheit noch beibehalten und nur umbenannt und durch die neue Datenbank ersetzt mit den Befehlen:

mv owncloud.db owncloud.save.db
mv owndloud.new.db owncloud.db

Wenn alles gut gegangen ist, dann kann man jetzt via Webinterface wieder auf Owncloud zugreifen und es normal nutzen. Fertig. Die Reparatur ist geglückt.

Hat es bei Dir auch geklappt? Oder waren es ganz andere Probleme mit Owncloud, die Du hattest? Schreib es mir gerne in die Kommentare.