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.

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?

Metadata now gets validated before each backup run. #785 will allow you do do manual integrity checks of random samples of data. Let's make a new ticket for scheduling such checks automatically for those who want them.