Generally speaking, I think this is what testing a backup means.
I recommend restoring your backup as a test. Restoring a blank tape often doesn't do anything. And if it does do something, it's probably not what you want.
In the olden days when I was the admin for a small shop we would immediately restore the backup to a second system to be used as a playground. Win/win: verified restore and a place to test/train with production data.
Yup, just as long as none of the connection strings point to (and can reach) a prod database.
I came to make this snide comment as well! Nobody tests their backups though, I've only ever seen it done inadvertently when the backups were used as part of the development process.
BTW how do you test a personal workstation backup? I don’t have backup workstations to rotate between by backing one up, restoring on the other, working and then cycling between them in this manner. How do you test the restore procedure without risking destruction of the original?
Most backup systems allow you to explore backups and extract individual files. Testing a bunch of files for restoring is at least better than completely ignoring it.. however it's difficult if it turns out part of your backup is simply missing, maybe an erroneous exclusion entry or some path miss (happened to me, I was without backup for a home folder for a year before I noticed it, the /home/user/ was a symlink to another volume that mostly had tmp data and so wasn't backed up). You might not even notice this even if you restore the whole backup, because you can't really be expected to go through everything every time either..
You can buy an extra storage device and swap them out (either physically or swapping the boot order), as long as your workstation doesn't have soldered in storage.
Even if it does, you can usually boot from an external volume anyway.
md5sum using a bash script and find, then compare on live.