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‘:
SQLLite-Fehlermeldung beim Owncloud-Update
SQLSTATE[HY000]: General error: 11 database disk image is malformed
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 sqlite3Die 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.dbDie 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 malformedAutsch, 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 insertDann habe ich angegeben, wie die Backup-Datei heißen soll und das er bitte das Backup machen soll:
sqlite> .output owncloud.bak.sql
sqlite> .dumpDamit 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.dbeingebe. 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.sqlMit 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_objectSieht 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.dbWenn 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.
Danke für die Anleitung.
Hat meine ownCloud Instanz doch noch gerettet.
Eine Anmerkung habe ich aber noch:
In dem Dump sollte der ROLLBACK Command mit COMMIT ausgetauscht werden. (Letzte Zeile!)
Bei einem Fehler in dem Dump hat man trotz „.read XXX.sql“ eine leere Datenbank.