Historically--for the last 15+ years--our server was always set to reserve upon reboot, and this was considered acceptable by the previous administrator. I've continued that practice, and I don't have any evidence that it's caused a problem, although if I am here when it crashes (rarely—once or twice a year) I re-serve a backup from just before the crash. (Backups run every 15 minutes or so. Mission-critical database.)
I'm wondering if I should uncheck that box at the server, and insist that a backup always be served--even if I'm not here to do it. This will not go over well with users/management after years with the "just reboot" approach and no evidence of corruption from this practice. (We have an outside service contracted for emergencies when I am not here. Never had to use them. I have no one in-house with real aptitude or interest.)
I’m posting this now because a crash occurred a month or so ago when I was out. Someone simply rebooted. According to the log, it appears the server actually shut down and restarted OK.
1) If there is a problem, and the post-reboot log shows no inconsistency checks or recovery attempts, is the database OK to serve?
2) Or is the risk great enough that I should fight the battle to uncheck the "Automatically Start Database Server" box... and possibly reawaken "corporate" to again question why we're using software without their I.T. guys in charge? And on a Mac, yet! (We "fought" them --and their antivirus and external backup systems--off years ago. Close call.)
But I also don't want to face creeping corruption obscurely introduced because we re-served a database after a problem.
Details: Large multi-file built-over-time legacy database since 1990s. Currently running FMS13 on OS 10.9.5. 20+ clients (Pro and Advanced, Mac and PC). No mobile users. Battery backup system with delay/shutdown in place.