Wanda,
Our situation is not exactly like you described, but we do support backups of
remote servers on eight campuses around the state. We don't have login rights
to any client servers.
We have a third-party TSM monitoring application that sends an e-mail to the
client admin and opens a ticket in our ticketing system when a backup is mssed
or fails. The monitoring application also sends a daily report to all client
admins showing the status of their clients; successful, missed, failed, not
scheduled, etc.. It's a great report. Nevertheless, we have the same problem.
I don't think technology can solve it.
Client admins have no qualms about ignoring canned messages, from wherever.
Some even filter them from their InBox. My tactic is to escalate after a few
days of misses or failures by calling an admin on the phone. It's more
persuasive than e-mail. If the problem is long standing, and an admin is close
by, I make a house call. These measures usually lead to a solution. If not, I
take out Thor's Hammer and remove a client from the schedule when it has missed
its backup several days in a row. I notify the admin(s) by e-mail, and voila!,
he or she suddenly fixes the problem. It's magical. I have the support of my
manager and my director in doing this.
We're at the mercy of failed backups because they are usually Windows servers
that had a bad systemstate backup, but a good data backup. So, we can't justify
taking them off the schedule. There seem to be an indefinite number of ways a
Windows server can fail a systemstate backup. Many admins aren't concerned
about bad systemstate backups, and few client admins can or will read
dsmerror.log. So we have them send it to us. We find the error, send them the
solution and hope. We can't login to their server and fix it ourselves so we
don't have much leverage.
Failed backups, fail forever, but missed backups come and go. So, we age the
problem for missed backups. Wait a day and it'll be working again. Not always,
but often.
Best wishes,
Keith Arbogast
Indiana University
.
|