We are used to creating collections upon request. This implies collections would be created/attached/detached continuously.
What is the impact of these on TFS backup plan?
Does it see new collections or should we re-configure each time?
What about detached collections?
I took some time to probe this. This is what I did. Firstly I scheduled a backup plan.
I have a simple TFS setup. There are no SharePoint or Reporting databases (these aren’t usually affected by collection level activities). Three databases are backed up
Then I added another collection – backup_test.
But that collection is not listed in the wizard. We still see only the three initial databases.
So should we add it? – By manually reconfiguring the backup plan? That would be tedious and also would create new backupset.xml.
Luckily no – we don’t have to.
We should wait for the next scheduled job – in my case a transactional backup in another 3 minutes.
And voila! Once the transaction job is kicked off – the new collection is added to the existing plan.
If you look into the backup folder you will see that it took a full backup of the new collection first and then the transaction log (instead of just the transaction). This is to maintain the SQL backup relationship between a full backup and a transaction/differential backup – the LSN continuity.
Moving forward this database would be backed just like the other databases in the plan.
The same behavior can be seen in a TFS collection delete or detach. The backup plan would modify itself when its next job is kicked off.
PS – Do note this doesn’t apply to Reporting or SharePoint database. Tool doesn’t pick new databases, while a delete of the databases listed in the plan may break the backup schedule. You would have to re-configure the plan to make changes.
Content created by – Venkata Narasimhan
Content reviewed by – Romit Gulati