Developer Center Blog » 18611

18611

[Public]

Protecting your data: A cautionary tale

Posted Mar 12 2010, 09:49 AM by jbierman

Filed under:

Requirements:

Discuss

There are moments when we do things that seem like a good idea at the time, but wind up putting ourselves (or our data) in danger. Take the details of a recent support case as an example.
Conceptual image of databases in the MetaCommunications product colors.Ray is the production manager at his company. He also happens to manage his company’s Workgroups system and the related servers. Late one Friday afternoon, Ray called me at technical support. "The drive where my database was located was full, so I deleted some files to free up some space," he said. "Now I can't log in to my database." While not the ideal reason to have to use one, this is the reason we have backups. So I asked Ray if we could just restore from backup. "Uhhh, I think I may have deleted my most current backups too." The panic was rising in his voice. "My boss is going to kill me," he said. Ray was beyond nervous.

Upon examination of the server, I determined that Ray had in fact deleted part of his database by deleting the transaction log file. "I thought it was an old backup file, so I deleted it," Ray explained. Ray had also deleted the previous night's full backup from the server. Indeed, things did not look good for Ray. Without a full backup, the database would be lost.

Then something dawned on Ray. "Hey, let me check the tapes... I may have backed this server up to tape last night," he said, hopefully. It turned out that the backups he deleted were on the tape. He was in luck because of this, and we were able to help him recover his database.

The object lesson for all of us is this: Recovering from a database loss shouldn’t come down to luck.

You should have a plan in place to ensure that you can recover your database in the event of any type of failure. Here are some things to consider when protecting your own Workgroups data:

  1. Make a full backup of your database daily. If possible, this backup should be kept on a drive where the database DOES NOT also reside. You should also make frequent transaction log backups throughout the day.
  2. Back up your database backups to tape as a part of your network backups and rotate those tapes off-site regularly.
  3. If you have Approval Manager, your proof files should be backed up to tape on a regular basis. If possible, you should also re-direct the location where the proof files are stored by Approval Manager.

MetaCommunications Technical Support is currently working with customers to help them review and verify how their data is being backed up. If you have questions about your own backups, please contact us to schedule a time to review your data protection scheme. A few minutes of preparation will save headaches when, like Ray, you need to recover your database.