There's a utility that will do it for you automatically. But here's the manual way (it's always best to know how the wizards work anyway):
1) Make sure no one is using your database.
2) Make a copy of the database and set it aside
3) Create a new, blank database.
4) Once inside the new database, go to File>Get External Data>Import... on your menu bar.
5) An Import dialog box (just like a File Open one) will pop up. Select your existing database and press <Import> (not LINK TABLES!).
6) Click on the Tab labelled "Tables."
7) Press "Select All".
8) Press "OK". This will bring in FULL COPIES of all the tables in your old database.
9) Save the new database. Most people use a naming convention that implies the relationship between the two dbs. I've seen "_be" appended to the name of the front-end database to make the name of the backend. For example: MyRecordCollection.mdb and MyRecordCollection_be.mdb. Be smart and do something like that.
10) Make certain you've backed up the original database.
11) Make doubly-certain you've backed up the original database.
12) Close the database and open up your original one. This is now your front-end database. The one with your tables is the back-end.
13) Delete all of the tables in this database (now you see what backups are so important <grin!>. Really! Delete them.
14) Go to File>Get External Data>Link Tables (NOT IMPORT) and do the same thing as before, this time selecting your BACKEND database.
15) Select all the tables, press OK. You will see all the tables return to your database but their icons will look a bit like shortcut icons (there'll be a little arrow by each suggesting the link).
16) Test your link by opening a table and seeing if you can get to the data.
Save the backend database to a common directory on the network (unless you're doing some kind of table synchronization thing - unlikely)
Consider making an MDE file of your front-end database. This can be downloaded to each desktop or run from the network.
If you don't make an MDE file, make your front end application Read-Only, they don't change data on the front end so this is okay.
If you are having consistent, repeatable problems of this type with an Access database, then I think it unreasonable to assume that splitting the database into two parts will have any measurable effect.
(The operative words are consistent and repeatable. Any such problem must have a physical cause of some kind, and it will persist until you find the root cause of the problem. This certainly seems to be the case here.)
Very likely, a cacheing related problem (see "opportunistic locking") will prove to be the culprit. This is where various workstations hold out-of-date copies of parts of the information in their memory caches, and wind up writing them to the file... corrupting it. MS has written a number of articles and summaries on the subject.