I will take a closer look but what was not immediately apparent was: what kind of backups are we talking about here? mysqldump or volume snapshots ? What about incremental backups ?
Redis snapshots support would be awesome as well.
I have plans to support things like RDS as well in the longer term.
I've got some redis instances here that I can test restoring from, so could look at adding that.
I'm not at all against sanity checks, especially of something you trust will work when you need it to like backups. But what would cause a DB backup to the filesystem to fail? When they are/were stored on tape or other media, there is certainly the concern of media corruption. But when we're talking about files resting on disk, what would cause a backup to be corrupt or unusable? Certainly there is some expectation that mysql/psql can reliably dump a DB. Or is it purely for sleeping soundly at night?
It can also help catch operational changes, eg. someone changed the root password and updated the apps that depend upon it, but didn't adjust the backup scripts.
Sounds like the crux will still depend on how well one writes these tests.
Agreeing that no backup is verified until it is restored... one way this can be achieved is use something like Ansible to script the backup of the database, script the restore, and run them and verify everything is backed up / restored properly.
Then since everything is automated, a person can reasonably trust their backups are verified, with the full confidence if they need to do a backup/restore, they just have to run a script.
