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

[DDvO]

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 ☹️

[grote]

I suspect a Seedvault bug.

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

[DDvO]

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.

[DDvO]

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

[DDvO]

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.

[grote]

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: []

[DDvO]

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.

[DDvO]

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.

[grote]

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?

[DDvO]

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.

[grote]

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?

[DDvO]

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.

[eternal-sorrow]

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

[DDvO]

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.

[eternal-sorrow]

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.

[eternal-sorrow]

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.

[grote]

@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.

[eternal-sorrow]

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.

[grote]

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.

[Seneral]

Same experience here, backup up on an old (luckily still working) phone on LineageOS 19.1 to an SD card.
Was not able to restore it on first boot in a new LineageOS 21 install on a new phone.
"No suitable backups found at given location. This is most likely due to a wrong recovery code or storage error"
Interestingly, the experimental storage backup detects the backup (with correct old phone model name).
So I was able to restore all my files and photos but not my contacts and apps.

Notably, verifying the passcode on the NEW phone after initial setup was done did work, so it can read the backup and presumably decrypt it just fine.
So something seems to be very wrong with seedvault (or its integration into LineageOS, idk).

Update:
I set up the new phones for backup as well to test it out. Thinking I had overwritten the old one, I went back, made sure the old one was backed up, and tried again with a full wipe on the new phone. This time, it showed me the backup (45kB - nothing) I did on my NEW phone, but not the old one. Same when selecting "Restore backup" in the settings after setup.
Unfortunately the seedvault version on my old phone doesn't allow me to manually restore to verify. Again, both phones correctly verify the SAME 12-word code.
I can DM the log. I only have one where it found the new backup from the new phone and thus never showed the error, but I can delete that and recreate the situation with just the older backup.

I'm starting to believe it's just filtering it out due to being on an old version or from a different device.
Again, the old device ran LineageOS 19.1, unofficial, new device (only one generation newer) runs LineageOS 21, official.

[Seneral]

Looked at the code, and the log file doesn't contain any relevant logs from RestoreCoordinator.kt::getAvailableBackups() - is this intended behaviour? How do I get those logs? Feels like they would be incredibly useful here...
Really, for all intents and purposes, getAvailableBackups() should NOT just log the error and the UI just say there was an error. I feel it badly needs a rewrite (sadly I never wrote anything Kotlin/Android related).
Currently, only if there is NO backup does the UI even know there was a error at all:
if (backups.isEmpty()) return RestorableBackupResult.ErrorResult(lastException)
Maybe instead return a list of results, each of which can have their own error, and pass along the readable error message along to the UI, not just dump it into a log (where I can't even find it anyway).
Then, the UI can confidently state, "there's no backup", "here are all backups, this one failed because of this, this one is valid", etc.
Currently, an empty backup list is the same as one where 2-3 failed, and a backup list with one result is the same as one with one valid and 1 failed to decrypt.
Seems like an easy fix if you know some kotlin, that would make it a whole lot easier to debug for users. Please.

In the meantime, is there a way to view the logs that file outputs?
This is the only way for me to even move to a new phone, I don't use google (for sync), I tried to manually convert a TWRP backup (different android versions didn't like that), neither of my phones is (or should be) rooted for titanium backup, so this is my only option.

[grote]

you should be able to export all needed logs via the UI, tap 3-dot menu at the top right corner on main screen, go to expert settings and then choose last option -> log export.

[Seneral]

you should be able to export all needed logs via the UI, tap 3-dot menu at the top right corner on main screen, go to expert settings and then choose last option -> log export.

As I said, I did that, and I did get a file with a bunch of logs. Sadly none of the relevant logs from the function I mentioned, even the ones in code that had to have run for the UI to look like it did. So either the log levels are wrong and they are not logged to file, or the logs from the initial setup are truncated.

BTW, I had to resort to manually transferring contacts, manually export settings and backups from each and every app, and luckily, all relevant apps did have an option - even if I had to fight them at times (the chat transfer of WhatsApp didn't work, and that is the only non-google official option - they don't document transferring files manually and I had to dig deep in reddit to find out how to do it. Even then I'm not sure what exactly did it as I tried a lot).

So while I don't need this to work myself anymore, I would really prefer to have an actually reliable form of backup, and this seems to be the only real option that works across devices, sadly, it didn't work for me.

If you got any hints or things you want me to try (short of restoring an old backup on my newly set up phone), please say. I do want this to work.

[grote]

If you still have the old backups, you could point Seedvault to that location and then select "restore backup". If nothing shows up, export logs right after and cut the logs right before you tapped "restore". Then you can share the logs with us and we can have a look.

[Seneral]

If you still have the old backups, you could point Seedvault to that location and then select "restore backup". If nothing shows up, export logs right after and cut the logs right before you tapped "restore". Then you can share the logs with us and we can have a look.

Took a bit since I didn't have access to the SD card until now.
Did that, pressed skip on app restore (showing only an empty backup made on the new phone), and skip on file restore (showing two 20GB file backups made on the old phone, one of them should have been overwritten but still shows), and then saved the logs.
No string "getAvailableBackups" found, looked at the git blame, and voila, that log was only added last month, no wonder I didn't find it.
It does contain the decrypt error at least:
seedvault-14-4.1-1730907661986.txt

Please tell me if there's any sensitive info in there I missed (just truncated so far).