Thursday, 11 September 2014

Again, again and again on the backups

This is a topic which I find coming back every now and then: backups of the Team Foundation Server.

Team Foundation Server is a SQL Server-based product – hence most of the backups’ work happens there. Full, Copy Only, Differential, Transaction Log: choose your flavour, as long as you are confident it’s good.

IMHO it is a good practice to keep things simple: a daily Full Backup with hourly Transaction Logs Backups provide a good level of protection without involving the (IMHO) complicated Differential Backups.

If you can, use the OOB tool: it is mature enough to do its job without too many worries. But if you happen to need a manual backup, there are a couple of information to keep in mind…

In order to be supported by the Microsoft CSS your backups must be synchronized – no exceptions. The safest way of doing that, as it required manual interaction with the TFS databases, is to follow this MSDN walkthrough. I introduced a slight modification as I manage a big deployment which uses SQL Server AlwaysOn, which is just the verification of the preferred backup instance, but the core steps are the same.

The reason behind that is pretty simple: the Team Project Collection databases refer to objects (like IDs, or identities) stored in the TFS_Configuration database. If you restore a Team Project Collection database which contains something not aligned with the Configuration DB, it is going to end badly…

And remember to test the restore – otherwise you do not have a backup Smile


  1. In your case... which is mine... it is extremely interesting this post .

    I want to add another consideration: in which scenarios do we need backups, given the fact that AlwaysOn guarantees disaster recovery. In my experience they are two: users losing data and setting up a test environment with your production data.

    In other words, backups do not exist to restore your production system anymore and this is a curious feeling.

  2. Actually, backups are still needed for DR. What if the datacentre is burnt to the ground? AlwaysOn is amazing for availability, with a very low RTO, but IMHO it does not replace proper backups.