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:
This is very true and something non-dba are not aware of!
Good points. The problem you're highlighting here is a perfect example of shoot-from-the-hip devops.
Whether the customer has Managed Services, a remote hosting partner, or hosts the servers inhouse - if you don't know what you're doing, stay the hell away from the databases.
The developer is the very last person who should tamper with the DBs or the backup scheme - in 99% of cases that's someone else's job.
I wrote a blog post about this kind of thing a few years back.. which hat is yours?
https://www.epinova.no/en/blog/your-hat-reveals-your-developer-type/
That was a funny post! I think I´m The Soldier :)
I am a cowboy....
any hat for Spartans?
Good point there, thanks Petra!