Recover from very old backup

Need some suggestion about recovering my data:

My android app stopped working after the 1.40 issue. There’s something wrong with my Titanium Backup files, and the app would quit immediately, even after I downgraded to 1.38.2. May be the data files were corrupted?

I have a very old Delta Chat backup .bak file lying around (2019-08!), but encountered 2 issues trying to restore from it:

  1. Android app doesn’t let me select the .bak file in the file picker - Not sure why file is greyed out
  2. On desktop app, the log says core/event ERROR IMEX failed to complete: numeric field was not a number: when getting cksum for SQLite format 3 immediately after opening the file for restore

I reckon the backup was created way back with the old core (compared with the current Rust core) and they’re not compatible. I could spin up a VM and run an old version of the desktop app to try to restore the backup. Or, perhaps backups made on android app isn’t compatible with desktop app?

What should I try next? I’m comfortable with tinkering the backup SQLite file but dunno where to start. Any suggestion would be much appreciated!

Here are my options:

  1. Tinker with the Titanium Backup files and try to fix the corruption
  2. Spin up old Ubuntu VM and restore to an old desktop app

p.s. I’ve trouble getting the Android app crash logs, suggestion appreciated!

I’m getting the following error after downgrade app, and restored app data from Titanium Backup.

Doesn’t look like a Delta Chat error?

Under root, I tried deleting the database under /data/user/0/com.b44t.messenger/no_backup/, but that didn’t solve the app quitting issue.

type: crash
osVersion:
package: com.b44t.messenger:621
process: com.b44t.messenger
processUptime: 26 + 72 ms

java.lang.IllegalStateException: The file system on the device is in a bad state. WorkManager cannot access the app's internal data store.
	at androidx.work.impl.utils.ForceStopRunnable.run(ForceStopRunnable.java:115)
	at androidx.work.impl.utils.SerialExecutor$Task.run(SerialExecutor.java:91)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1137)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:637)
	at java.lang.Thread.run(Thread.java:1012)
Caused by: android.database.sqlite.SQLiteCantOpenDatabaseException: Cannot open database '/data/user/0/com.b44t.messenger/no_backup/androidx.work.workdb' with flags 0x30000000: Unable to deduct failure reason
	at android.database.sqlite.SQLiteConnection.open(SQLiteConnection.java:262)
	at android.database.sqlite.SQLiteConnection.open(SQLiteConnection.java:205)
	at android.database.sqlite.SQLiteConnectionPool.openConnectionLocked(SQLiteConnectionPool.java:512)
	at android.database.sqlite.SQLiteConnectionPool.open(SQLiteConnectionPool.java:210)
	at android.database.sqlite.SQLiteConnectionPool.open(SQLiteConnectionPool.java:202)
	at android.database.sqlite.SQLiteDatabase.openInner(SQLiteDatabase.java:1094)
	at android.database.sqlite.SQLiteDatabase.open(SQLiteDatabase.java:1074)
	at android.database.sqlite.SQLiteDatabase.openDatabase(SQLiteDatabase.java:938)
	at android.database.sqlite.SQLiteDatabase.openDatabase(SQLiteDatabase.java:927)
	at android.database.sqlite.SQLiteOpenHelper.getDatabaseLocked(SQLiteOpenHelper.java:380)
	at android.database.sqlite.SQLiteOpenHelper.getWritableDatabase(SQLiteOpenHelper.java:323)
	at androidx.sqlite.db.framework.FrameworkSQLiteOpenHelper$OpenHelper.getWritableSupportDatabase(FrameworkSQLiteOpenHelper.java:145)
	at androidx.sqlite.db.framework.FrameworkSQLiteOpenHelper.getWritableDatabase(FrameworkSQLiteOpenHelper.java:106)
	at androidx.room.RoomDatabase.beginTransaction(RoomDatabase.java:352)
	at androidx.work.impl.utils.ForceStopRunnable.cleanUp(ForceStopRunnable.java:156)
	at androidx.work.impl.utils.ForceStopRunnable.run(ForceStopRunnable.java:87)
	... 4 more
Caused by: android.database.sqlite.SQLiteCantOpenDatabaseException: unknown error (code 14 SQLITE_CANTOPEN): Could not open database
	at android.database.sqlite.SQLiteConnection.nativeOpen(Native Method)
	at android.database.sqlite.SQLiteConnection.open(SQLiteConnection.java:224)
	... 19 more

They are compatible, all backups are generated by the same Rust core regardless of whether you are using Android, Desktop or iOS.

Good to know! Any suggestion to get pass the restore error? core/event ERROR IMEX failed to complete: numeric field was not a number: when getting cksum for SQLite format 3 immediately after opening the file for restore.

Current android app crash log, help appreciated!

type: crash
osVersion: 
package: com.b44t.messenger:6582
process: com.b44t.messenger
processUptime: 42 + 61 ms
installer: com.machiav3lli.fdroid

java.lang.NullPointerException: Attempt to read from field 'int com.b44t.messenger.rpc.Rpc$Response.id' on a null object reference in method 'void com.b44t.messenger.rpc.Rpc.processResponse()'
    at com.b44t.messenger.rpc.Rpc.processResponse(Rpc.java:30)
    at com.b44t.messenger.rpc.Rpc.lambda$start$0$com-b44t-messenger-rpc-Rpc(Rpc.java:52)
    at com.b44t.messenger.rpc.Rpc$ExternalSyntheticLambda0.run(Unknown Source:2)
    at java.lang.Thread.run(Thread.java:1012)

It is already fixed but f-droid takes ages to update. Should be ready any day now…

1 Like

Thanks for the assurance. I’ve got an impression that my data files are corrupted. What’s my best bet to recover from that?

Could you try opening the .bak file with sqlitebrowser or the command line? What is the size of it?

The failure to open the database after Titanium Backup restore looks like a permission problem, maybe try restoring it and then try to change ownership of the directory to match the UID of the app if you have root and some command line knowledge. Apps under android get different UIDs each time they are installed.

Thanks @link2xt good suggestions. I’ll try to browse the .bak file.

Have updated to latest FD 1.40.1 build and still not starting - Some kind of file corruption or permission issue it seems. In Termux I’ve checked the UID/GID they all seem correct (matching com.b44t.messenger directory’s UID and GID)