Category Archives for "SQL Server"

Jul 10

Why Choose SQL Server to Run Your Databases?

By Charles | SQL Server

Why choose SQL Server? This is a fantastic question as there are so many RDBMS (Relational DataBase Management Systems) out there.SQL Server Database Services


The biggest threat to businesses right now are cyber security attacks. They might be targeted attacks or your systems might just end up as collateral damage but the risk is real.

According to the National Institute of Standards and Technology, SQL Server has had the fewest security vulnerabilities over the Continue reading

Jul 03

Who Loves SQL Server? Linux loves SQL Server 2017

By Charles | Architecture

You read that correctly SQL Server 2017 is coming to LINUX.


Good question. Linux has been around for decades and is a very stable and solid platform but it has usually been offered ‘free’. I started using Linux before I had used SQL Server so my excitement is at record levels right now. In fact I can actually remember a client asking if it was possible to run SQL Server on Linux back in 2008! If you are after a Continue reading

Apr 29

When’s too Late to Sort Your SQL Backup strategy?

By Charles | Business

[h2_heading]Do you have a SQL backup strategy in place?[/h2_heading]

You have at most, between now and the next disaster situation to sort out your backup strategy, the catch however is that you will never know when that disaster will strike. So you really only have one option. Sort your SQL backup strategy now once and for all.

SQL database backup

I personally can not sleep knowing that a SQL backup strategy is either non existent or worse not fit for purpose. False hope is no hope at all.

[h2_heading]Are there any rules for a backup strategy?[/h2_heading] There are certainly things to remember here are three of the things I think about.

  1. If you do not have 3 seperatly stored copies of your data, you do not have any data
  2. If you do not regularly do test restores from backups, you do not have any backups
  3. The business leads when it comes to determining acceptable data loss / recovery times

So what do I mean by 3 separate copies. Well you have your production data which is one copy of your data but that’s not really a backup it’s your live system. A local backup to a backup drive would be considered one copy. Doing a flat file backup of these backup drives would be a second copy. This might be to disk on another SAN. The third copy would be having that SAN replicate to another SAN offsite or taking a copy and putting them on tape which are then stored offsite or by a third party. These 3 copies must be in place for every single days backups and at least one copy must be off site.

Regularly test restoring a copy of your systems from your backups. If you do not know that you can restore your backups and use the restored data then you might as well not take the backup in the first place. Taking a backup is just half the battle and can give you a false sense of security as you check the backup software status and it says everything is green so you believe it. Everything continues on until a production system requires a restore to roll back a failed change, when you find out the backup cannot be restored due to an error. I have been there and it is not a nice place to be. It resembles Azkaban and you feel like you are receiving a kiss from a Dementor. You end up having to go back to an even earlier backup and lose some data then try to recreate what has been lost. Do not end up in this position just test your restores its much easier.

Contrary to popular belief the DBA does not choose the data loss and recovery times of a system. Both the RPO (Recovery Point Objective) and RTO (Recovery Time Objective) must be decided by the BUSINESS. The DBA will then implement a backup strategy to enable the recovery inside both the RPO and RTO.

Hopefully after reading this you won’t have trouble sleeping. As always if you would like to discuss a SQL backup strategy contact us.