Of course if you can't trust the (creator/maintainer of the) code on a machine there's nothing you can in code on the machine to make it secure. That said, if

Of course if you can't trust the (creator/maintainer of the) code on a machine there's nothing you can in code on the machine to make it secure. That said, if this kind of problem is a valid concern for an installation, the simplest solution is external validation of backups. For example, one might hire someone not in control of the original system (and not in contact with them) to do restorations and provide certification that they worked according to a test plan. This is the foundation for a lot of Sarbanes-Oxley technical audit consulting. Audited backups would, of course, require a fairly elaborate disaster recovery plan, which sounds out of scope for this company. I don't want to pass judgement, but if a pivotal IT person was let go and sabotage was discovered, at least a basic pass through the systems taking backups doesn't seem out of line.