Update to say that I restarted the server, updated it to v5, and changed one of my evening backups to not do a file check (so at least I'm getting my backups). I left one doing it, to test.
Do make sure to check the FMS event log for any indications of trouble, going to back to that rogue backup.
One of the things you could have tried was to close the admin console and restart the admin server part of FMS (not the whole FMS) to see if this was just an admin console refresh issue.
To restart the admin server, from the command line do: fmsadmin restart adminserver
I've had this happen repeatedly with versions 10-11, not with 12 or 13 yet. The problem was usually associated with:
a) Collision of scripts
b) Errors occurring during backup process
c) Disk storage accessability
Rarely, and I do say rarely, was it ever an admin console issue. One solution that I implemented in my last contract, when I was having these issues, was to create a windows task schedule to execute a batch file to restart FM Server prior to running night scripts and nightly backups. Cured it for me.
Thanks to both of you! Wim - I really don't think it can be just a refresh issue, since it's keeping my nightly backups from running, while the daytime one (without check) is running fine. Again, my log says the backup is done and consistency check is passed - but some finish line isn't being crossed to tell the Admin Console it's done, and can get ready to run again the next day. However, I will try that fancy restart adminserver trick next time before I have to reboot the server again. (when I tried fmsadmin restart server, I got "error connecting to server" or something close. I am not a Windows person, and command line in Windows is not my favorite place.)
Aryden - I've never had a problem with backup schedules colliding, but just to be sure I changed the spacing of my 2 nightly backups (one goes offsite) so as to give the first plenty of time to finish before the 2nd one happens. It still keep running.
As for "disk storage accessability," could you say more? FMS12 is installed on a Virtual server, and it's installed on an E drive (not on C, with the rest of the system.) Could this be causing a problem? Once again, I don't know windows, so am relying on in-house tech for the hardware configuration. But I can ask for more or different resources, if I can figure out what's causing the problem.
The other thing to watch out for is any other process that runs around that time: any external backup process, anti-viurs. volume snapshots,... all of these have to be turned off or explicitly configured to exclude FMS folders and files
Though Wim is corrrect in many instances, I have found that most of the time, these things do not "have to be" turned off at the time of the scripts, it just really helps.
I was referring to collisions of scripts themselves with the backups. So for instance you have a script that runs at 12am and needs 25 minutes to process, meanwhile you are attempting backup, they can and in my experience, have, interfered with one another.
I experience that same thing, "my log says the backup is done and consistency check is passed - but some finish line isn't being crossed to tell the Admin Console it's done, and can get ready to run again the next day", once in a while and have a similar environment, Windows 2008 R2, FMS 12. I also like how you phrase that, because it fits what I see happening every so often, too.
I will see that files of the backup set complete, consistency completes good 639, and clones are produced 720, but no 150 backup set complete and 126 backup set. reschedule.
My gut tells me feels like its a part of the virtualization environment. There are times I've logged in to the server after not seeing a 150 completion in email, only to see things sort of "wake up" and proceed, and then finish. But other times, I think too much time passes and that 150 gets lost somewhere.
Does that last 150/126 completion/reschedule depend on the admin console in anyway?
I do believe that host snapshots may have something to do with the admin console getting goofed up, and possibly the backup set 'tracking' getting goofed up, too. My only trouble is finding a good time at night for these to run, as I don't have any visibility as to when the snapshots run.