I'm with Pat on this one. If your big company makes it difficult for you to do backups via some scheduler task, they are big enough to have an IT department. Find out their operations policy regarding backup retention. I can't believe they wouldn't have a tape "leap-frog" method of keeping data for more than just a day or two.
You are worried that you won't notice corruption. So... take action to reduce the odds of corruption. You already started down that path by having a split FE/BE pair of files. Next question: Does each user have a private FE file that is a copy of your "Master FE" file? Because that is the next big step in avoiding corruption.
By the way... it is good that the company wouldn't allow you to "roll your own" backup. Using a scheduler + automated file-copy doesn't help much. It's as much of a gamble because basically, the file-copy is a snapshot of the file in question REGARDLESS of the state of any Access actions that might be underway. It is therefore a snapshot of something that is moving and therefore could be a blurred snapshot because you caught it between parts of a long update. To YOU, it looks like a single update. To Access, it is broken up into as many disk I/O operations as it takes to touch every record in the target table.
BUT... what YOU described - making a shadow transaction behind every insert, delete, or update - is ALSO a snapshot in a different sense. If you do this within the FE, then you have people all over the place doing SQL actions to two files - but of necessity, they are time-sequential actions, not parallel actions, because Access is not multi-threaded. With extremely rare and complex exceptions that involve complex API calls, you can only ask Access to do one SQL action as a time if the BE is native Access (as opposed to something like SQL server). Which means that if ANY user's machine bites the dust between the "live" update and the "backup" update, you STILL have an imperfect snapshot. If you tried to do this using a Data Macro, then you simply transferred the possible origin of corruption from an incomplete FE action to an incomplete BE backup action.
Not only that... if your company invests in an automatic dynamic backup system that keeps driver-level duplication of all disk I/O, then if you DO get corruption, you just replicated it. "Cloud" backups are no help because the cloud protocols tend to get in the way of Access operations. Full-blown replication of all disk actions doesn't help this specific case because it also propagates that putative corruption.
My advice to you is to contemplate the Serenity prayer and then CAREFULLY look at things you CAN do to help the situation. But rolling your own backup isn't as likely to be helpful as you might think.
Before you ask, I was with the U.S. Navy as a contractor during the time that they initiated a COOP initiative. (Continuity Of Operations Program... COOP.) I watched - and participated when allowed to do so - as they analyzed all of these issues. In our case, it was an ORACLE back-end and a package called SmartStar on the front-end, which was a timesharing interactive+batch mainframe. (Or so the Navy considered it.) But we went through analysis to the point that we were as blue in the face as the Navy's Dress Blues. COOP is an exercise in the possible tempered by patience regarding that which cannot be achieved, and doing due diligence to learn which is which.
If you REALLY get curious about the Navy's plan, do this search: U.S. Navy COOP initiative
If you do this, don't blame me for getting either bored or lost in all the Navy acronyms.
