There are a few things to be concerned about going wrong and depending on your concerns it can change the strategy a bit. If the concern is the backup program (tar, zfs send, whatever) generating an incorrect backup file, a test restore is the only way your going to find it.
Assuming you’re confident in your backup program it allows some different strategies. If you save the file to a filesystem that checksums data like zfs, a scrub gets the file check “for free” but managing external drives with zfs can be a pain.
What I do is use gpg to encrypt and sign the backups as they’re copied to the external drive. This way a lost disk is less scary but the encrypt step could be skipped and you could just sign them. The idea is to be piping from the backup program through gpg and not just gpg the file after it’s written. If using a filesystem like ext4 you will be exposed to botrot if you work with the files after writing them and I have had files fail a signature check just after writing. You wouldn’t want to sign an already corrupted file. If you verify the signature it ensures the file is unchanged on disk with any corruption resulting in a bad signature.
This can be adapted to just using checksums shh256sum but make sure you are piping the data rather than summing it on a “suspect” disk.