restart the admin console via command line:
fmsadmin restart adminserver
FMS13v5 is rock-solid if running on Windows Server on our 4 servers.
we had also issues with the admin console and the log - the server never crashed serving the files.
from time to time the admin console needs to be restarted - fortunately it is a process of its own.
I'm afraid I already performed this step, and it still insists that the scheduled backup is currently running, and shows no errors of any kind - like I said, I checked the actual Event.log to see if anything was up, and it just thinks everything is fine.
when was the last time you restarted the server? i would shut down all property thru the command line and start fresh.
normally this resolves it.
i meant "properly"
We had this issue previously starting on the 15th, and actually performed a restart this Thursday when we managed to get our users shuffled off. It makes it all the more strange that it insists its last backup was the 9th, and it still needs to run the successful one it actually performed, even according to Event.log, on Friday the 23rd.
In any case, it performed it's single good backup, and is back to being odd. I don't want to have to restart the server every night just to get my backup to generate!
Also, to be clear, it shut down and came back up completely normally, save for its insistence on the 9th being its most recent backup.
i would trash the schedule and recreate a new one and see how it behaves.
Sorry for the delay getting back to you on this one - but your suggestion cracked the case wide open!
For some reason, the old schedule wasn't producing an error, but as soon as I recreated it, and ran it, it finally spat out an Error 8003 - thread lock! I managed to trace it to some scripts that were running overnight doing cleanup on our part number DB interfering with the method scheduled backups attempt to pause activity.
I managed to recreate the behavior in our development system to confirm this was the case, and we've since stopped the script from running simultaneously with our backup. I'm just curious now as to why this script would cause 8003... just too many record operations to cope with?
Thanks for all your help,
i think your conclusion is correct michael.
scheduled backups if interfering with other scheduled scripts is something you should avoid.