How to keep the integrity of a backup chain

This is the second post about issues I often encountered working for Episerver Managed Services. It´s not an Episerver specific blog post per se, but we often saw this problem and it has to do with developers messing up the integrity of a backup chain. For some people this might be obvious and a no brainer, but like I wrote, it was quite a big problem so people need to learn and be aware of this.

The backup chain

In any hosting environment, regardless if you have in-house hosting or with a hosting provider such as Episerver Managed Services there are of course backup jobs running to backup an SQL database. A common setup is to take a full backup once a week and differential backups running each day or perhaps a full backup once and then only differential backups each day. Regardless which approach is used it´s important to keep the integrity of the backup chain.

The issue

All too often partners or customers have access to the production database and performing backups before a deploy. That´s all good and is what should be done, but the developer might not have knowledge about how the backups are run and how a backup chain works, so when they do a backup they do a full backup and are not aware that by not checking the box Copy-only database they are destroying the backup chain causing the database not being able to be restored to the latest differential backup. In the case of trouble and the database have to be restored the previous differential backup can´t be used, it will mess up the database.

Of course the full backup done before the deploy was made could be used but then the backup chain has to be setup again with an initial full backup. And if the database backup in question has been deleted after the deploy or can´t be used for any other reason then a lot of data would be lost when having to revert back to the latest full backup in the backup chain.

The solution

Always check the Copy-only backup box when doing a backup before a deploy, as shown here: