seedvault
seedvault copied to clipboard
seedvault-app
Option to test/verify backups
- [ ] Implement way to download and verify backup integrity without actually restoring anything
- [ ] Show how much data of each app got backup app
I'd love some way to verify the backups I've already made. Ideally this would be done automatically for me on a regular basis.
Maybe select a backup to verify every night semi-randomly, giving a stronger weight to both recent backups and backups that hadn't been checked in a while?
What kind of verification are you proposing here exactly?
The real way to verify a backup would be to actually try restoring it.
You can do that in a separate user or work profile, or on another device - to avoid losing any data on the device being backed up.
I'm not sure because I'm unsure of exactly what kind of metadata is retained by Seedvault. Ideally Seedvault would be able to cryptographically verify that the data hadn't been tampered with or corrupted, and it would do a dry run restore (i.e. everything that a restore would do except actually passing the data to the system APIs to be restored) to check for format issues, like a bug in the original serialization.
Mostly the Nextcloud app is slow and fragile and errors on that side have caused numerous backups I've manually run to abort partway through. So from a user perspective I want to have some assurance that what was uploaded before the failure is usable.
The real way to verify a backup would be to actually try restoring it.
You can do that in a separate user or work profile
I just stumbled across this and tried. Created fresh user profile with using phone & sms allowed, switched to it, skipped phone setup and dialed the vanity number. It did nothing - until I switched back to my normal user profile where I was prompted with choosing the location to restore from! Out of curiosity and convinced that I would need to enter my 12-word passcode before some real restoring could happen, I followed the instructions as if I wanted to restore (yes, still on my main profile). And without asking me for that 12-word passcode Seedvault tried to restore and is now kind of stuck. 0 of 117 files restored since 30 minutes... I'm gonna need to kill the app.
Verification that the backup setup works would be really nice but it seems that it's not just as simple as trying to restore in another user profile on the same phone.
Created fresh user profile with using phone & sms allowed, switched to it, skipped phone setup and dialed the vanity number. It did nothing - until I switched back to my normal user profile where I was prompted with choosing the location to restore from!
That sounds strange. Maybe the vanity number thing opened the activity in the main user instead of the fresh one?
This is a hugely important feature. Normal backup practice is to do test restores to ensure that the backups can be read. On a normal operating system, you can just unpack it someplace else. While I see the point of another profile, this was news to me (that it could be done, and backups per profile vs per user), and not all devices really do profiles.
For Android/Seedvault, I think what's needed is a "test restore" option that does the entire reading and validation part of the restore, and just doesn't write it anywhere. The main path would be entering the passphrase, but there could be a "use internal key" to avoid that, to make it easier. So this would read every file needed, validate checksums, unpack and validate the format, and just use a dummy implementation of putting it back.
This of course won't catch bugs in the "put it back" code, but it will find problems with "files seedvault thinks it wrote didn't end up right." Looking at the history of "NextCloud android app breaks backups" and other woes makes it seem like everyone should be encouraged to be doing test restores monthly at least.
Arguably one should be able to configure, and perhaps by default, automatic validation (using the key that is already inside), perhaps as the first step in a backup, basically validate previous, do backup, report both statuses.
as the first step in a backup, basically validate previous
As we don't have a server-side component that can perform verification tasks, we would need to download all data for verification. I am not sure we can do that by default before all backups (especially those tasks scheduled by the OS), because it would introduce significant delays and bandwidth usage.
as the first step in a backup, basically validate previous
As we don't have a server-side component that can perform verification tasks, we would need to download all data for verification. I am not sure we can do that by default before all backups (especially those tasks scheduled by the OS), because it would introduce significant delays and bandwidth usage.
Maybe we do not need that? I think generally in most use cases we can rely on files to be not maliciously modified on target storage. So, the meta data has to be validated. Then we can check if the file has the expected size, and if it does, it probably has been written as expected to the storage. To validate bit-correctness, one could then run a script to check for filename = hashsum(content) on target storage (on some future storage backends (which store hashsums of stored content) this might even be supported ootb).
To validate bit-correctness, one could then run a script to check for filename = hashsum(content) on target storage (on some future storage backends (which store hashsums of stored content) this might even be supported ootb).
Modern Nextcloud versions support checksums automatically.
Modern Nextcloud versions support checksums automatically.
That sounds great! Could you check if the filenames align with the sums your NC calculates?