Where I work, we have a active directory setup with a dedicated file server. All important data goes to a partition on file server. The server has a RAID10 setup to create 2 exact mirrors on 4 drives.
Every 6 hours, a backup software creates a mirror of all shared files to 3 external hard disk and one NAS drive.
Every 12 hours the contents of the file server is mirrored to Dropbox, every 24 hours to Microsoft OneDrive, Every 48 hours to Google Drive.
Are we too cautious?
The correct answer is yes, no, and maybe. Which answer is correct? Depends on how much value is placed on the data being copied AND two other factors: How difficult would it be to reconstitute the data from other sources? And how much user disruption is involved when making those backup file copies? HINT: There is a LOT of depth behind the second question.
There is this little bit of a "gotcha" for databases, because it is possible for a "transparent" backup to capture an unusable mirror of the file. For instance, one in which at the time of the backup, you also happened to be going through the internal overhead associated with an insert, update, or delete - which sometimes results in massive physical restructuring of the tables.
I know from personal experience that this "gotcha" is possible for ORACLE, because I won a bet with the "external backup" software rep. He bought me a steak dinner at a decent restaurant in Fort Worth after an incident when his backup software was unable to correctly restore an ORACLE database even though we followed every step of the documented process. After that incident, about 15-20 years ago, ORACLE had to introduce a new back-end state called "BACKUP" in which all tables were stabilized and all ongoing transactions were logged in a TEMP area that was visible to service users touching altered tables. In short, one initiated the state, took the image, and then discontinued the BACKUP state, which caused ORACLE to "roll forward" the transactions that were still pending. I.e. it played "catch up."
When you took the image of the DB in that BACKUP state, you could restore the database to the date/time (and instantiation number) of the moment of completion of establishing the BACKUP state. You then had to roll forward any pending transactions. If you didn't do that state change, you could not restore anything because the copy operation copied mixed (non-coherent) table instantiation numbers.
Why am I telling you this about an Access DB? Because Access
doesn't have a BACKUP state where it stabilizes the main tables so you can make a coherent backup. To assure a good backup of an Access backend, you must assure that no one is in it at the moment. Now, all of that staging of copies of the backup? That level of expense is up to you. It
would meet U.S. Department of Defense guidelines regarding handling of backups up to and including regulations on offsite storage of operational backups. So my answer for the staging of the backup files is "no, not too cautious" - if the file contents are that valuable to you.
The key to the value of the whole process is what you do when you make the backup copy from the "live" file to the backup file. At that moment, if the DB is in a precarious state, you've got nothing. If you take pains to assure the backup is good, or if the back end file is a non-Access SQL server or ODBC-type server that has a BACKUP state or equivalent AND you use it for backups, then you are as good as gold.
