This is potentially a significant fact. Was that size difference between the damaged DB and the backup based on the "raw" damaged database for which you had not yet attempted a Compact & Repair?
If you use Access to make a backup copy, I don't know if it implies a C&R. If you use Copy/Paste from Windows Explorer, that DOES NOT imply C&R and thus the copied file should be the same size. If the damaged DB was not C&R'd before examination and was STILL shorter than the backup DB, that is a sign of corruption. An "ordinary" delete doesn't reclaim space from a file until the C&R occurs.
Stated another way, if you took a backup of the DB, copied that, and deleted tables manually, but did NOT do a Compact & Repair, the two files should have been approximately the same size within a couple of percent. If the damaged DB is significantly shorter, the physical file is damaged.
I would run a CHKDISK on the disk holding that damaged back-end to see if it has one or more file fragments it can't identify as being part of a named file. (Because you have already replaced the original with its backup, thus replacing the name.) If that has happened, you had a disk failure.
To follow up on that, you should check the system's event viewer. If you know approximately when the loss occurred, go to that machine that served the DB and check the event log viewer. Entries are sorted by date/time so it would be easy to find the detailed logs for the time of the error. Look for a disk error. If you had a disk error and lost the back part of the file, the REAL surprise is that you didn't run into even worse errors than merely losing data.