You need to monitor the process. I do a morning check up for issues with the back ups every work day to look for issues with the backups. Not only could verification fail, there's a bug that gums up scheduled backups in my version of server (version 10) that can't be fixed without restarting the server computer.
Verification failed is an indication that your file may be damaged and thus the backup copy failed it's verification test. You should run a recover on the original of every file where you have gotten this message to see if it is OK or not.
How do I know which file it is that's the problem?
If it's back up failed verification, use Recover check the original for damage. I'd also use a utility to check your hard drive out for problems in case it's a "bad write" that's producing copies that fail verification.
In the end, I went to the 'databases' tab, ran "verify all". I noticed one file remained closed, so I went into the filemaker folder, double-clicked it, and 'lo-and-behold, it was corrupted and prompted me to recover.
Once I recovered, i went back to the schedules and ran them, and they worked great. Thanks for the tips. I wish FMSA would still backup with faulty files, at least to back up the good ones.
Things to keep in mind about Recover:
While Recover almost always detects and fully corrects any problems with your file...
- Recover does not detect all problems
- Recover doesn't always fix all problems correctly
- Best Practice is to never put a recovered copy back into regular use or development. Instead, replace the damaged file with an undamaged back up copy if this is at all possible. You may have to save a clone of the back up copy and import all data from your recovered copy to get a working copy with the most up to date information possible.
Thanks for the tip. Luckily, it's not a file where the data is important (it's a training file), so I have no problem using the recovered copy.
Yes, but your recovered copy still may not be perfectly recovered. Problems may exist in your file that won't affect current execution, but might cause problems at a later date. The odds that this is the case are very small, but not zero.
If you've got a back up copy that does not report problems when you perform a recover on it, you should use it in place of the recovered copy--even if you have to recreate a few of the last changes made to your file.