Restore fails with error: 'No suitable backups found at given location'

Question

Restore fails with error: 'No suitable backups found at given location'

DDvO opened this issue 4 months ago · 20 comments

Trying to migrate apps+data to my new phone, the restore step fails.
regardless which storage location I tried on the target (local phone storage or webDAV via the DAVx5 app, which provided further challenges, see #85 (comment)).
After entering the correct 12-word passphrase that I had used to backup up apps+data on my old phone,
I am stuck with this error:

No suitable backups found at given location
This is most likely due to a wrong recovery code or storage error.

When I then select "Skip restoring apps", I get

No storage backups found
Sorry, but there is nothing that can be restored.

The above error messages are very vague, not giving real info what went wrong why,
so I can only guess what went wrong. I suspect a Seedvault bug.
It turns out that it is there since more than 3 years:
https://www.reddit.com/r/LineageOS/comments/lask4q/no_suitable_backups_found_at_given_location_for/

This makes Seedvault unusable for migrating apps+data to a new phone ☹️

Answer 1 · 2024-06-17T16:32:30.000Z

I suspect a Seedvault bug.

Would you please be so nice and export logs from right after you got those messages?

Answer 2 · 2024-06-17T19:16:04.000Z

I just re-did the restore attempt, which the same result, and here is the log: seedvault-14-4.0-1718651594220.txt.
In this case the backup was created using DAVx5.

Answer 3 · 2024-06-17T19:24:00.000Z

Since someone claimed that he got it working using local phone storage for the backup and then copying that to the local storage of the new system,
I tried this too, but in my case with the same negative result and the following log: seedvault-14-4.0-1718651988210.txt

Answer 4 · 2024-06-17T20:24:56.000Z

As mentioned, in in case the error message given is too vague!
And the log is awkward to obtain and display, and its content are a mess that is mostly useless to regular users.

For effective user-level debugging, Seedvault should provide to-the-point failure information, e.g.

connection to server failed (for the given reasonl),
access permission denied
the backup directory does not exist at the specified location,
there is no (current) backup data instance in that directory,
a directory/file read error occurred (for the given reason)
decryption failed (likely due to wrong passphrase),
etc.

Answer 5 · 2024-06-18T12:57:47.000Z

relevent bit from seedvault-14-4.0-1718651594220.txt.

06-17 21:12:20.799 32718   337 E RestoreCoordinator: Error while getting restore set 1718570792674
06-17 21:12:20.799 32718   337 E RestoreCoordinator: java.io.IOException: java.io.IOException
06-17 21:12:20.799 32718   337 E RestoreCoordinator: 	at com.stevesoltys.seedvault.plugins.saf.DocumentsStorage.getInputStream(DocumentsStorage.kt:134)
06-17 21:12:20.799 32718   337 E RestoreCoordinator: 	at com.stevesoltys.seedvault.plugins.saf.DocumentsProviderStoragePlugin$getAvailableBackups$2$1.invokeSuspend(DocumentsProviderStoragePlugin.kt:125)
06-17 21:12:20.799 32718   337 E RestoreCoordinator: 	at com.stevesoltys.seedvault.plugins.saf.DocumentsProviderStoragePlugin$getAvailableBackups$2$1.invoke(Unknown Source:8)
06-17 21:12:20.799 32718   337 E RestoreCoordinator: 	at com.stevesoltys.seedvault.plugins.saf.DocumentsProviderStoragePlugin$getAvailableBackups$2$1.invoke(Unknown Source:2)
06-17 21:12:20.799 32718   337 E RestoreCoordinator: 	at com.stevesoltys.seedvault.transport.restore.RestoreCoordinator.getAvailableMetadata(RestoreCoordinator.kt:80)
06-17 21:12:20.799 32718   337 E RestoreCoordinator: 	at com.stevesoltys.seedvault.transport.restore.RestoreCoordinator$getAvailableMetadata$1.invokeSuspend(Unknown Source:14)
06-17 21:12:20.799 32718   337 E RestoreCoordinator: 	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
06-17 21:12:20.799 32718   337 E RestoreCoordinator: 	at kotlinx.coroutines.internal.ScopeCoroutine.afterResume(Scopes.kt:32)
06-17 21:12:20.799 32718   337 E RestoreCoordinator: 	at kotlinx.coroutines.AbstractCoroutine.resumeWith(AbstractCoroutine.kt:102)
06-17 21:12:20.799 32718   337 E RestoreCoordinator: 	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:46)
06-17 21:12:20.799 32718   337 E RestoreCoordinator: 	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:108)
06-17 21:12:20.799 32718   337 E RestoreCoordinator: 	at kotlinx.coroutines.internal.LimitedDispatcher$Worker.run(LimitedDispatcher.kt:115)
06-17 21:12:20.799 32718   337 E RestoreCoordinator: 	at kotlinx.coroutines.scheduling.TaskImpl.run(Tasks.kt:103)
06-17 21:12:20.799 32718   337 E RestoreCoordinator: 	at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:584)
06-17 21:12:20.799 32718   337 E RestoreCoordinator: 	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:793)
06-17 21:12:20.799 32718   337 E RestoreCoordinator: 	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:697)
06-17 21:12:20.799 32718   337 E RestoreCoordinator: 	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:684)
06-17 21:12:20.799 32718   337 E RestoreCoordinator: Caused by: java.io.IOException
06-17 21:12:20.799 32718   337 E RestoreCoordinator: 	at com.stevesoltys.seedvault.plugins.saf.DocumentsStorage.getInputStream(DocumentsStorage.kt:131)
06-17 21:12:20.799 32718   337 E RestoreCoordinator: 	... 16 more
06-17 21:12:20.799 32718   337 I RestoreCoordinator: Got available metadata for tokens: []

Here we really can't say much, it is an I/O error.

Next one : seedvault-14-4.0-1718651988210.txt is different, here we have 3 restore sets and can't decrypt any of them:

06-17 21:19:16.620  2509  2558 E RestoreCoordinator: Error while getting restore set 1718466670667
06-17 21:19:16.620  2509  2558 E RestoreCoordinator: java.io.IOException: error:1e000065:Cipher functions:OPENSSL_internal:BAD_DECRYPT
06-17 21:19:16.620  2509  2558 E RestoreCoordinator: StreamingAeadDecryptingStream
06-17 21:19:16.620  2509  2558 E RestoreCoordinator: segmentNr:0
06-17 21:19:16.620  2509  2558 E RestoreCoordinator: ciphertextSegmentSize:1048576
06-17 21:19:16.620  2509  2558 E RestoreCoordinator: headerRead:true
06-17 21:19:16.620  2509  2558 E RestoreCoordinator: endOfCiphertext:true
06-17 21:19:16.620  2509  2558 E RestoreCoordinator: endOfPlaintext:false
06-17 21:19:16.620  2509  2558 E RestoreCoordinator: decryptionErrorOccured:true
06-17 21:19:16.620  2509  2558 E RestoreCoordinator: ciphertextSgement position:15247 limit:15247
06-17 21:19:16.620  2509  2558 E RestoreCoordinator: plaintextSegment position:0 limit:0
06-17 21:19:16.620  2509  2558 E RestoreCoordinator: segmentNr:0 endOfCiphertext:true
06-17 21:19:16.620  2509  2558 E RestoreCoordinator: 	at com.google.crypto.tink.subtle.StreamingAeadDecryptingStream.loadSegment(StreamingAeadDecryptingStream.java:176)
06-17 21:19:16.620  2509  2558 E RestoreCoordinator: 	at com.google.crypto.tink.subtle.StreamingAeadDecryptingStream.read(StreamingAeadDecryptingStream.java:231)
06-17 21:19:16.620  2509  2558 E RestoreCoordinator: 	at com.google.crypto.tink.subtle.StreamingAeadDecryptingStream.read(StreamingAeadDecryptingStream.java:208)
06-17 21:19:16.620  2509  2558 E RestoreCoordinator: 	at kotlin.io.ByteStreamsKt.copyTo(IOStreams.kt:106)
06-17 21:19:16.620  2509  2558 E RestoreCoordinator: 	at kotlin.io.ByteStreamsKt.copyTo$default(IOStreams.kt:103)
06-17 21:19:16.620  2509  2558 E RestoreCoordinator: 	at kotlin.io.ByteStreamsKt.readBytes(IOStreams.kt:136)
06-17 21:19:16.620  2509  2558 E RestoreCoordinator: 	at com.stevesoltys.seedvault.metadata.MetadataReaderImpl.readMetadata(MetadataReader.kt:59)
06-17 21:19:16.620  2509  2558 E RestoreCoordinator: 	at com.stevesoltys.seedvault.transport.restore.RestoreCoordinator.getAvailableMetadata(RestoreCoordinator.kt:81)
06-17 21:19:16.620  2509  2558 E RestoreCoordinator: 	at com.stevesoltys.seedvault.restore.RestoreViewModel$loadRestoreSets$1.invokeSuspend(RestoreViewModel.kt:147)
06-17 21:19:16.620  2509  2558 E RestoreCoordinator: 	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
06-17 21:19:16.620  2509  2558 E RestoreCoordinator: 	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:108)
06-17 21:19:16.620  2509  2558 E RestoreCoordinator: 	at kotlinx.coroutines.internal.LimitedDispatcher$Worker.run(LimitedDispatcher.kt:115)
06-17 21:19:16.620  2509  2558 E RestoreCoordinator: 	at kotlinx.coroutines.scheduling.TaskImpl.run(Tasks.kt:103)
06-17 21:19:16.620  2509  2558 E RestoreCoordinator: 	at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:584)
06-17 21:19:16.620  2509  2558 E RestoreCoordinator: 	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:793)
06-17 21:19:16.620  2509  2558 E RestoreCoordinator: 	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:697)
06-17 21:19:16.620  2509  2558 E RestoreCoordinator: 	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:684)
06-17 21:19:16.620  2509  2558 E RestoreCoordinator: Caused by: javax.crypto.AEADBadTagException: error:1e000065:Cipher functions:OPENSSL_internal:BAD_DECRYPT
06-17 21:19:16.620  2509  2558 E RestoreCoordinator: 	at java.lang.reflect.Constructor.newInstance0(Native Method)
06-17 21:19:16.620  2509  2558 E RestoreCoordinator: 	at java.lang.reflect.Constructor.newInstance(Constructor.java:343)
06-17 21:19:16.620  2509  2558 E RestoreCoordinator: 	at com.android.org.conscrypt.OpenSSLAeadCipher.throwAEADBadTagExceptionIfAvailable(OpenSSLAeadCipher.java:320)
06-17 21:19:16.620  2509  2558 E RestoreCoordinator: 	at com.android.org.conscrypt.OpenSSLAeadCipher.doFinalInternal(OpenSSLAeadCipher.java:348)
06-17 21:19:16.620  2509  2558 E RestoreCoordinator: 	at com.android.org.conscrypt.OpenSSLAeadCipher.engineDoFinal(OpenSSLAeadCipher.java:262)
06-17 21:19:16.620  2509  2558 E RestoreCoordinator: 	at javax.crypto.Cipher.doFinal(Cipher.java:2369)
06-17 21:19:16.620  2509  2558 E RestoreCoordinator: 	at com.google.crypto.tink.subtle.AesGcmHkdfStreaming$AesGcmHkdfStreamDecrypter.decryptSegment(AesGcmHkdfStreaming.java:300)
06-17 21:19:16.620  2509  2558 E RestoreCoordinator: 	at com.google.crypto.tink.subtle.StreamingAeadDecryptingStream.loadSegment(StreamingAeadDecryptingStream.java:168)
06-17 21:19:16.620  2509  2558 E RestoreCoordinator: 	... 16 more
06-17 21:19:16.659  2509  2558 E RestoreCoordinator: Error while getting restore set 1718570792674
06-17 21:19:16.659  2509  2558 E RestoreCoordinator: java.io.IOException: error:1e000065:Cipher functions:OPENSSL_internal:BAD_DECRYPT
06-17 21:19:16.659  2509  2558 E RestoreCoordinator: StreamingAeadDecryptingStream
06-17 21:19:16.659  2509  2558 E RestoreCoordinator: segmentNr:0
06-17 21:19:16.659  2509  2558 E RestoreCoordinator: ciphertextSegmentSize:1048576
06-17 21:19:16.659  2509  2558 E RestoreCoordinator: headerRead:true
06-17 21:19:16.659  2509  2558 E RestoreCoordinator: endOfCiphertext:true
06-17 21:19:16.659  2509  2558 E RestoreCoordinator: endOfPlaintext:false
06-17 21:19:16.659  2509  2558 E RestoreCoordinator: decryptionErrorOccured:true
06-17 21:19:16.659  2509  2558 E RestoreCoordinator: ciphertextSgement position:16005 limit:16005
06-17 21:19:16.659  2509  2558 E RestoreCoordinator: plaintextSegment position:0 limit:0
06-17 21:19:16.659  2509  2558 E RestoreCoordinator: segmentNr:0 endOfCiphertext:true
06-17 21:19:16.659  2509  2558 E RestoreCoordinator: 	at com.google.crypto.tink.subtle.StreamingAeadDecryptingStream.loadSegment(StreamingAeadDecryptingStream.java:176)
06-17 21:19:16.659  2509  2558 E RestoreCoordinator: 	at com.google.crypto.tink.subtle.StreamingAeadDecryptingStream.read(StreamingAeadDecryptingStream.java:231)
06-17 21:19:16.659  2509  2558 E RestoreCoordinator: 	at com.google.crypto.tink.subtle.StreamingAeadDecryptingStream.read(StreamingAeadDecryptingStream.java:208)
06-17 21:19:16.659  2509  2558 E RestoreCoordinator: 	at kotlin.io.ByteStreamsKt.copyTo(IOStreams.kt:106)
06-17 21:19:16.659  2509  2558 E RestoreCoordinator: 	at kotlin.io.ByteStreamsKt.copyTo$default(IOStreams.kt:103)
06-17 21:19:16.659  2509  2558 E RestoreCoordinator: 	at kotlin.io.ByteStreamsKt.readBytes(IOStreams.kt:136)
06-17 21:19:16.659  2509  2558 E RestoreCoordinator: 	at com.stevesoltys.seedvault.metadata.MetadataReaderImpl.readMetadata(MetadataReader.kt:59)
06-17 21:19:16.659  2509  2558 E RestoreCoordinator: 	at com.stevesoltys.seedvault.transport.restore.RestoreCoordinator.getAvailableMetadata(RestoreCoordinator.kt:81)
06-17 21:19:16.659  2509  2558 E RestoreCoordinator: 	at com.stevesoltys.seedvault.restore.RestoreViewModel$loadRestoreSets$1.invokeSuspend(RestoreViewModel.kt:147)
06-17 21:19:16.659  2509  2558 E RestoreCoordinator: 	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
06-17 21:19:16.659  2509  2558 E RestoreCoordinator: 	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:108)
06-17 21:19:16.659  2509  2558 E RestoreCoordinator: 	at kotlinx.coroutines.internal.LimitedDispatcher$Worker.run(LimitedDispatcher.kt:115)
06-17 21:19:16.659  2509  2558 E RestoreCoordinator: 	at kotlinx.coroutines.scheduling.TaskImpl.run(Tasks.kt:103)
06-17 21:19:16.659  2509  2558 E RestoreCoordinator: 	at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:584)
06-17 21:19:16.659  2509  2558 E RestoreCoordinator: 	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:793)
06-17 21:19:16.659  2509  2558 E RestoreCoordinator: 	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:697)
06-17 21:19:16.659  2509  2558 E RestoreCoordinator: 	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:684)
06-17 21:19:16.659  2509  2558 E RestoreCoordinator: Caused by: javax.crypto.AEADBadTagException: error:1e000065:Cipher functions:OPENSSL_internal:BAD_DECRYPT
06-17 21:19:16.659  2509  2558 E RestoreCoordinator: 	at java.lang.reflect.Constructor.newInstance0(Native Method)
06-17 21:19:16.659  2509  2558 E RestoreCoordinator: 	at java.lang.reflect.Constructor.newInstance(Constructor.java:343)
06-17 21:19:16.659  2509  2558 E RestoreCoordinator: 	at com.android.org.conscrypt.OpenSSLAeadCipher.throwAEADBadTagExceptionIfAvailable(OpenSSLAeadCipher.java:320)
06-17 21:19:16.659  2509  2558 E RestoreCoordinator: 	at com.android.org.conscrypt.OpenSSLAeadCipher.doFinalInternal(OpenSSLAeadCipher.java:348)
06-17 21:19:16.659  2509  2558 E RestoreCoordinator: 	at com.android.org.conscrypt.OpenSSLAeadCipher.engineDoFinal(OpenSSLAeadCipher.java:262)
06-17 21:19:16.659  2509  2558 E RestoreCoordinator: 	at javax.crypto.Cipher.doFinal(Cipher.java:2369)
06-17 21:19:16.659  2509  2558 E RestoreCoordinator: 	at com.google.crypto.tink.subtle.AesGcmHkdfStreaming$AesGcmHkdfStreamDecrypter.decryptSegment(AesGcmHkdfStreaming.java:300)
06-17 21:19:16.659  2509  2558 E RestoreCoordinator: 	at com.google.crypto.tink.subtle.StreamingAeadDecryptingStream.loadSegment(StreamingAeadDecryptingStream.java:168)
06-17 21:19:16.659  2509  2558 E RestoreCoordinator: 	... 16 more
06-17 21:19:16.682  2509  2558 E RestoreCoordinator: Error while getting restore set 1718463896044
06-17 21:19:16.682  2509  2558 E RestoreCoordinator: java.io.IOException: error:1e000065:Cipher functions:OPENSSL_internal:BAD_DECRYPT
06-17 21:19:16.682  2509  2558 E RestoreCoordinator: StreamingAeadDecryptingStream
06-17 21:19:16.682  2509  2558 E RestoreCoordinator: segmentNr:0
06-17 21:19:16.682  2509  2558 E RestoreCoordinator: ciphertextSegmentSize:1048576
06-17 21:19:16.682  2509  2558 E RestoreCoordinator: headerRead:true
06-17 21:19:16.682  2509  2558 E RestoreCoordinator: endOfCiphertext:true
06-17 21:19:16.682  2509  2558 E RestoreCoordinator: endOfPlaintext:false
06-17 21:19:16.682  2509  2558 E RestoreCoordinator: decryptionErrorOccured:true
06-17 21:19:16.682  2509  2558 E RestoreCoordinator: ciphertextSgement position:208 limit:208
06-17 21:19:16.682  2509  2558 E RestoreCoordinator: plaintextSegment position:0 limit:0
06-17 21:19:16.682  2509  2558 E RestoreCoordinator: segmentNr:0 endOfCiphertext:true
06-17 21:19:16.682  2509  2558 E RestoreCoordinator: 	at com.google.crypto.tink.subtle.StreamingAeadDecryptingStream.loadSegment(StreamingAeadDecryptingStream.java:176)
06-17 21:19:16.682  2509  2558 E RestoreCoordinator: 	at com.google.crypto.tink.subtle.StreamingAeadDecryptingStream.read(StreamingAeadDecryptingStream.java:231)
06-17 21:19:16.682  2509  2558 E RestoreCoordinator: 	at com.google.crypto.tink.subtle.StreamingAeadDecryptingStream.read(StreamingAeadDecryptingStream.java:208)
06-17 21:19:16.682  2509  2558 E RestoreCoordinator: 	at kotlin.io.ByteStreamsKt.copyTo(IOStreams.kt:106)
06-17 21:19:16.682  2509  2558 E RestoreCoordinator: 	at kotlin.io.ByteStreamsKt.copyTo$default(IOStreams.kt:103)
06-17 21:19:16.682  2509  2558 E RestoreCoordinator: 	at kotlin.io.ByteStreamsKt.readBytes(IOStreams.kt:136)
06-17 21:19:16.682  2509  2558 E RestoreCoordinator: 	at com.stevesoltys.seedvault.metadata.MetadataReaderImpl.readMetadata(MetadataReader.kt:59)
06-17 21:19:16.682  2509  2558 E RestoreCoordinator: 	at com.stevesoltys.seedvault.transport.restore.RestoreCoordinator.getAvailableMetadata(RestoreCoordinator.kt:81)
06-17 21:19:16.682  2509  2558 E RestoreCoordinator: 	at com.stevesoltys.seedvault.restore.RestoreViewModel$loadRestoreSets$1.invokeSuspend(RestoreViewModel.kt:147)
06-17 21:19:16.682  2509  2558 E RestoreCoordinator: 	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
06-17 21:19:16.682  2509  2558 E RestoreCoordinator: 	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:108)
06-17 21:19:16.682  2509  2558 E RestoreCoordinator: 	at kotlinx.coroutines.internal.LimitedDispatcher$Worker.run(LimitedDispatcher.kt:115)
06-17 21:19:16.682  2509  2558 E RestoreCoordinator: 	at kotlinx.coroutines.scheduling.TaskImpl.run(Tasks.kt:103)
06-17 21:19:16.682  2509  2558 E RestoreCoordinator: 	at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:584)
06-17 21:19:16.682  2509  2558 E RestoreCoordinator: 	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:793)
06-17 21:19:16.682  2509  2558 E RestoreCoordinator: 	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:697)
06-17 21:19:16.682  2509  2558 E RestoreCoordinator: 	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:684)
06-17 21:19:16.682  2509  2558 E RestoreCoordinator: Caused by: javax.crypto.AEADBadTagException: error:1e000065:Cipher functions:OPENSSL_internal:BAD_DECRYPT
06-17 21:19:16.682  2509  2558 E RestoreCoordinator: 	at java.lang.reflect.Constructor.newInstance0(Native Method)
06-17 21:19:16.682  2509  2558 E RestoreCoordinator: 	at java.lang.reflect.Constructor.newInstance(Constructor.java:343)
06-17 21:19:16.682  2509  2558 E RestoreCoordinator: 	at com.android.org.conscrypt.OpenSSLAeadCipher.throwAEADBadTagExceptionIfAvailable(OpenSSLAeadCipher.java:320)
06-17 21:19:16.682  2509  2558 E RestoreCoordinator: 	at com.android.org.conscrypt.OpenSSLAeadCipher.doFinalInternal(OpenSSLAeadCipher.java:348)
06-17 21:19:16.682  2509  2558 E RestoreCoordinator: 	at com.android.org.conscrypt.OpenSSLAeadCipher.engineDoFinal(OpenSSLAeadCipher.java:262)
06-17 21:19:16.682  2509  2558 E RestoreCoordinator: 	at javax.crypto.Cipher.doFinal(Cipher.java:2369)
06-17 21:19:16.682  2509  2558 E RestoreCoordinator: 	at com.google.crypto.tink.subtle.AesGcmHkdfStreaming$AesGcmHkdfStreamDecrypter.decryptSegment(AesGcmHkdfStreaming.java:300)
06-17 21:19:16.682  2509  2558 E RestoreCoordinator: 	at com.google.crypto.tink.subtle.StreamingAeadDecryptingStream.loadSegment(StreamingAeadDecryptingStream.java:168)
06-17 21:19:16.682  2509  2558 E RestoreCoordinator: 	... 16 more
06-17 21:19:16.682  2509  2558 I RestoreCoordinator: Got available metadata for tokens: []

Answer 6 · 2024-06-18T20:12:12.000Z

relevent bit from seedvault-14-4.0-1718651594220.txt.

06-17 21:12:20.799 32718   337 E RestoreCoordinator: Error while getting restore set 1718570792674
06-17 21:12:20.799 32718   337 E RestoreCoordinator: java.io.IOException: java.io.IOException

So here Seedvault should have reported, e.g., "Error while getting restore set 1718570792674"
and state for which file it got which type of I/O error.

Here we really can't say much, it is an I/O error.

The directory 1718570792674 is present and does contain 133 app+data files, plus .backup.metadata.
I see no reason for an actual I/O error.

The whole directory and all files can be read (e.g., using adb pull -a /sdcard/.SeedVaultAndroidBackup/1718570792674) without any errors.

I can only guess that Seedvault tries to access a wrong file, or access an existing file in a wrong way or access got denied. The app really should report exactly what exactly went wrong on which file.

As mentioned below, on a second try there was no I/O error.

Answer 7 · 2024-06-18T20:28:15.000Z

Next one : seedvault-14-4.0-1718651988210.txt is different, here we have 3 restore sets and can't decrypt any of them:

06-17 21:19:16.620  2509  2558 E RestoreCoordinator: Error while getting restore set 1718466670667
06-17 21:19:16.620  2509  2558 E RestoreCoordinator: java.io.IOException: error:1e000065:Cipher functions:OPENSSL_internal:BAD_DECRYPT

So here Seedvault should have reported, e.g., "Could not decrypt restore set 1718466670667"

06-17 21:19:16.659 2509 2558 E RestoreCoordinator: Error while getting restore set 1718570792674
06-17 21:19:16.659 2509 2558 E RestoreCoordinator: java.io.IOException: error:1e000065:Cipher functions:OPENSSL_internal:BAD_DECRYPT

So here Seedvault should have reported, e.g., "Could not decrypt restore set 1718570792674"

Note that this is the same restore set for which at first an I/O error occurred. Weird.

06-17 21:19:16.682 2509 2558 E RestoreCoordinator: Error while getting restore set 1718463896044
06-17 21:19:16.682 2509 2558 E RestoreCoordinator: java.io.IOException: error:1e000065:Cipher functions:OPENSSL_internal:BAD_DECRYPT

So here Seedvault should have reported, e.g., "Could not decrypt restore set 1718463896044"

I've double-checked that the pass phrase used on the source (backup) and target (restore) system are the same
and used the Seedvault option on the target system to verify the pass phrase I entered, which did not give an error.

I wonder why nothing could be decrypted. There must be some Seedvault bug here.

Since AEAD ciphers are used, looks like the passphrase and/or the encrypted contents
somehow got modified between the backup and restore attempts or were wrongly use.
I'm pretty sure this is not due to a user's mistake with the passphrase
nor due to a data transmission issue between source and target system.
For being able to better distinguish potential reasons, I suggest adding a checksum/hash to each backup set/directory.

Answer 8 · 2024-06-19T12:49:23.000Z

I see no reason for an actual I/O error.

Maybe the filesystem is corrupted?

As mentioned below, on a second try there was no I/O error.

Ok, all good then I guess.

So here Seedvault should have reported, e.g., "Could not decrypt restore set 1718466670667"

Isn't this what "This is most likely due to a wrong recovery code or storage error." is saying? We don't expose low lever details to users and what would be the benefit? If it can not decrypt/read any backups and you are proficient enough to mess with the internal files, then you'll find them yourself.

looks like the passphrase and/or the encrypted contents somehow got modified between the backup

faulty filesystem or storage medium? Have you tried using a (different) flash drive for backup/restore?

Answer 9 · 2024-06-23T14:42:58.000Z

I see no reason for an actual I/O error.

Maybe the filesystem is corrupted?

No - as I wrote, the directory can be read (e.g., using adb pull) without issues.

As mentioned below, on a second try there was no I/O error.

Ok, all good then I guess.

Not really - it seems to be a matter of luck.

So here Seedvault should have reported, e.g., "Could not decrypt restore set 1718466670667"

Isn't this what "This is most likely due to a wrong recovery code or storage error." is saying? We don't expose low lever details to users and what would be the benefit? If it can not decrypt/read any backups and you are proficient enough to mess with the internal files, then you'll find them yourself.

Again, as I wrote in the OP, it is NOT sufficient to provide very vague error messages.
User should get to-the-point information what exactly went wrong and why.
For instance, it's a big difference whether the backup directory cannot be found, or there was a file or directory read error, or the pass phrase does not match.

looks like the passphrase and/or the encrypted contents somehow got modified between the backup

faulty filesystem or storage medium? Have you tried using a (different) flash drive for backup/restore?

Again, the file system is fine.

In my 20+ years of using many different Android phones, I never had issues with the internal file system.
Also the current two phones involved here work fine - except that Seedvault exhibits all sorts of weird behavior, which is for sure not the fault of (the system on) the phones.
In particular, the good-old Titanium Backup works pretty well.

Answer 10 · 2024-06-24T13:52:23.000Z

Again, as I wrote in the OP, it is NOT sufficient to provide very vague error messages.
User should get to-the-point information what exactly went wrong and why.

Sorry, I can't find the pull request from you that provided this behavior.

In particular, the good-old Titanium Backup works pretty well.

Why don't you stick with that then?

Answer 11 · 2024-07-01T20:16:49.000Z

Again, as I wrote in the OP, it is NOT sufficient to provide very vague error messages.
User should get to-the-point information what exactly went wrong and why.

Sorry, I can't find the pull request from you that provided this behavior.

Sorry, I can't find the time to dig deep into this development.
Nor the motivation to do so after your recent responses.

In particular, the good-old Titanium Backup works pretty well.

Why don't you stick with that then?

After my recent experience with Seedvault, I do stick with Titanium Backup.
Despite some things not working smoothly anymore,
still way better than Seedvault, which at least with LineageOS 21 does not work at all.

Answer 12 · 2024-08-01T01:34:26.000Z

Same problem here with SD card as a storage medium. Could different versions of LineageOS (and probably different versions of SeedVault) be the reason?

Answer 13 · 2024-08-01T05:57:14.000Z

In my case, the same LineageOS version and SeedVault version was used.
So a version mismatch cannot be the reason.
It must be due to some internal SeedVault bug.

Answer 14 · 2024-08-01T06:00:26.000Z

Yes, I updated LineageOS on my old phone to the latest version (I originally wanted to do that after I finished setup of my new phone, but oh well). I made full backup on the old phone and tried to restore on the new one, with the same error.

Answer 15 · 2024-08-01T06:12:45.000Z

I updated LineageOS on one of my phones beforehand because the old version did not support SeedVault at all.
Which was a real bad experience because the update did not work well and I lost my entire old installation, which otherwise could have served as a backup phone.
And an extreme disappointment because then I found that SeedVault does not work, so the whole process was a complete failure, which I could have avoided easily by not attempting to use Seedvault.

Answer 16 · 2024-08-01T07:49:30.000Z

The actual reason for this misbehavior/failure is needlessly hard to spot because Seedvault does not provide proper application-level logging.

Answer 17 · 2024-08-01T10:27:42.000Z

Just tried with OTG (created backup as an internal storage backup, transferred it to a thumb drive, connected it via OTG adapter, tried to restore). The same error.

Answer 18 · 2024-08-01T12:22:14.000Z

@eternal-sorrow to debug this, could you send me a file/dir listing of your .SeedVaultAndroidBackup folder and a logcat export right after the error occurred? You can do the export from Settings -> Backup -> 3-dot overflow menu -> expert settings -> export logcat

are you certain that the 12-word recovery code is correct? if you still have access to the backup on the new phone, you can use the verify recovery code option to make sure, the same code is used on both devices.

Could different versions of LineageOS (and probably different versions of SeedVault) be the reason?

Only if the backup was made on a recent version and you try to restore on a very old version.

Answer 19 · 2024-08-01T14:48:11.000Z

Funny enough, it turned out to be a wrong code issue. But the problem is, why it doesn't say it directly "the code is wrong"? Why such vague error message?

Also, when I was trying to (unsuccessfully) restore the backup, I tried many things, including entering the code in different order (in case I wrote it down in different order when I first created it, it was long ago), but it told me instantly that the code was wrong, no vague messages like "No suitable backups". So when it gave me the this message, I thought the code must be correct but something else went wrong after the code was applied.

Answer 20 · 2024-08-01T15:19:35.000Z

Glad you figured it out!

We should improve the error message, but it isn't trivial. There may be several backups in this location. Some we can't decrypt, because of wrong code, others may be corrupted and others may produce i/o errors. So hard to combine this into a sensible error message that is actionable for users.

An easy start here would be to amend the error text with something like: "Please double check that you entered the recovery code correctly." Contributions welcome.