There is a theoretical problem in what you just asked. MarkK, I agree that FSO and the FileCopy primitive can do the actual job. The question is what kind of job they do and whether you can live with their result in a 7x24 environment.
Nominally, the back-end copy will be passive if split traditionally. The only way to do what you ask involves a front-end from which to run code. But what you really wanted to do was to test for not having the DB open at a given time so that you could make a good copy. The wrinkle is that to do this from VBA code, that implies that the FE is open at the time and therefore linked to the database. I.e. if the FE is open and the BE linked tables are statically linked, then the BE is ALSO open. You will therefore have file locks on the BE database.
The way that I usually did this important task was to ask around for consensus from my users as to when would be a good time to manually do a backup. Otherwise, you run the risk of catching the DB in a partially updated state. Oh, you could still do a copy if you had to, but there is no guarantee that what you save is consistent at that exact moment. I.e. if any action queries are active, then the DB might partially updated. OK, low odds on that case - but not ZERO odds.
As to the steps, I had a login/logout table that I called a "session" table. Each user logging in would get an (autonumbered) session with a login time and a flag saying "Logged in" - and the code would remember the session number. When logging out, they would update the session table for their session number to set the logout time and clear the "Logged In" flag.
So when it was time to do this dirty deed, I would test that table to see if anyone was logged in. The user table included their work extension so I could call them and say "It is maintenance time, please log out." If they didn't cooperate, I had ways to be a total bastard about it, since I could reboot the host system if they didn't want to play by the rules. (And the boss was on-board with playing hardball about data preservation - an important consideration.)
I would verify that I could take it down by RENAMING the back-end file in-place, which you could not do if someone was still logged in. I copied the renamed file to a work area and then made a copy in that place with the correct name for the BE. However, since the BE was NOT in the right folder during this time, a smarty-pants user would not be able to log in because the FE would test for the existence of the BE and would barf if not there.
OK, so I would open the BE directly in my working area. I could do that because, even though the BE had its own protective switchboard and other steps to prevent people from getting into it, I was an admin user and the DB knew that. So it waited a few seconds and let me into the navigation panel. It also turned on the ribbon for me. Then I could do the manual C&R on the correctly-named copy of the file I had moved from the working area. After that, I could copy that file back to the right place; it was already under the right name.
Then I could erase the incorrectly named copy and move the copy with the right name in the wrong place to the place where I kept archival copies. (Which I always manually renamed to include a date stamp.)
Sounds tedious, but then again we had users who didn't need to be in our database 7x24, so they could spare me about 15-30 minutes, usually at their lunch hour. I didn't mind taking a later lunch. It wasn't like I was going to wither away if I was late for a meal now and then. (In fact, my doctor suggested I try that as a way to lose weight... but I digress.)
Anyway, your problem is going to be that automated methods can often work, but the best automated method will face a time when you HAVE to make a backup and because the DB is open, you CAN'T make a backup. Do you want automation to suddenly make decisions about when to interrupt production and when to defer activity? We didn't.