Latest Blogs

Each year, I find myself reminding clients to check that their backups are including new databases. The main system I work with has a new database for each year. Add into that the test and development environments, and the addition to the daily/weekly backups, and you can imagine how much data you suddenly need to take care of. A lot!

With the unprecedented times we are currently living in, there is more risk than ever of databases being created by users without the permission of those responsible for backups.

This time of year also allows us to ask the question of how many of our “old” databases we need keep. Can some be taken offline to aid system performance or be deleted altogether? Perhaps the addition of more data to our daily backups can be offset by removing now redundant data from past years?

I used to battle weekly for storage space on physical backup tapes, finding myself constantly chasing where new databases had appeared from. Right now, I look back and think okay, so I’m at home working, the users are at home working, I don’t always know when or why a new database will appear when we we’re all in the same workplace, so how am I going to know now! How can I know which databases are temporary, which need backups and how often those backups are needed? Yes, there is some amazing technology around now to handle all of this for us, but that doesn’t escape the problem of what is needed to be kept and for how long. That still needs input from the users and system administrators.

Another problem we see a lot of is space running out on servers. Sometimes a database is created with options that don’t reflect the backup strategy. An example of this is database logs which are very useful in rolling back a database to a certain point in time. If we recover from a major system failure, we could put the database back to a point in time based on the log data we have. But what if we have a different backup strategy that allows us to do the same thing using another mechanism? Then we don’t need those logs. Without proper management, log files can eat up all the available disk space on a server, resulting in that server crashing. Just writing that sends shivers through me. I have seen that occur too many times.

This thought takes me to another topic, Disaster Recovery. What happens if the worst happens? What systems are key for our operation? How much data can we afford to lose?

The latter is a particularly interesting conversation to be had with users. We all happily key data in, making changes to documents and databases, and we simply expect that, if the system fails, we won’t lose anything. Hmm. Okay. But we don’t always have the technology, let alone hardware, to make that completely possible. And even if we did, it won’t cover all our data.

Let us take the main system I work with, a scheduling application for lessons and meetings. On a typical day a user would be tweaking data at best, but at certain times of the year, like now, they will be building a whole new year’s worth of scheduled lessons. So how much they can afford to lose will depend on which system and database we are talking about. For some systems, it could be the difference between staying open for business or not.

I would like to end this blog, if I may, with a list of advice based on my own experiences and given the situation right now, where the connection between system administrators and their users is more disconnected than usual. The following is a list of things you should be asking:

• Are users able to create new databases?
• How do you monitor the size of your backups?
• What databases can be moved offline or deleted?
• Do you need database logging? (If yes, how is this managed?)
• Are there any new aspects of the system going live which will impact the amount of data you hold?
• When did you last review your Disaster Recovery plan?
• Have any systems become more urgent since the the last time you checked?
• How much data can you afford to lose, system by system?
• Do you regularly test recovery of databases from your backups?