1. The Status of the backup in the FM Console reads "OK". Why does it say this when the main file didn't get backed up?
That IS strange, raise a support ticket with FMI for that. But first verify that absolutely nothing is trying to work with files or folders during backup time (no Volume Shadow Copy, no virus scanning,...)
2. Is there any way to stop the RC's being backup up - I really don't need any more copies of the files?
No! That's like asking "is there a way to stop backing up some of my old records, I don't need more copies of those" The RC data is integral part of your FM file, don't be fooled by the fact that it is stored outside of the FM file. It's not just a link, it is part of your file.
Also, remember that FMS uses smart hard linking for its backups. So if that container field hasn't changed between backups, you actually don't have a new copy of the RC file, just a pointer to the inode that already exists on the hard disk.
That also answers your question #4: because the RC file IS part of your FM file.
5. Why does the file fail to backup when it's part of a set but work when it's on its own?
Impossible to asnwer without looking in-depth at your deployment and the Windows system and application event logs... so look there for clues. Also look at the hardware to see if there are any indications that the hard disk is failing or running out of disk space. That's also in answer to your question #3.
Thanks for the reply.
My point with the RC's not requiring backup is that unlike the data it never changes and I use other means to back them up. So I understand how important they are. But like I said wish there was an option to not back them up because as it stands the root of my problem still stands; the failure to copy them for unknown reasons is causing my backup to fail. Just because the RC's can't be copied doesn't mean the actual FM file shouldn't be - which is what I'm experiencing.