Backing up projects on Octopus Tentacles? Think twice

I’ve noticed many of our Octopus teams use the File System – Backup Directory step template from the library to implement a backup step. Unfortunately, I’ve seen minimal prudence from said teams implementing backups. Many of these teams simply backup their project across most if not all of their environments while having no rollback steps whatsoever. Don’t get me wrong, I love the Octopus Step library, but the backup directory step (or similar steps) are seldom worth implementing. It’s very tempting to use them and I can understand the appeal. Backups seem like the right thing to do for your automated deployment, but it can be fools gold. But how can backing up be a bad thing?
For one, the need to explicitly backup projects on Octopus tentacles is practically non-existent. With NuGet packages and NuGet feeds, they are the mechanism for redeploying backups. If a deployed package is bad or you want to revert back, just redeploy the package you want as long as it’s available in your feed. It’s simple to do and no changes to your deployment process are necessary.
Second, most backups don’t need to run across all of your environments. It seems obvious, but I see a lot of teams do it for most if not all their environments. I can understand the argument to backup a production site, but if anything, you only need to back it the previous project files – there’s no need for extensive backup history.
And lastly, there are some pitfalls people tend not to realize beforehand. Here’s a few we’ve stumbled on:

• You use up storage with each deployment – teams just continually backup the application folder without deleting the previous copy. Some of our teams use the “Create TimeStamped Backup Folder” option. Unfortunately, it’s a waste of storage and deployment time to do any kind of backups on your development or staging servers. What value is there in backing up non-production server? If you need a previous version, use the NuGet package in your feed.
• Backup snafus – it’s easy to do and one team that used backup step template made a subtle but severe mistake. Can you spot it?
  

  Source: D:\Apps\MyCoolApp\Service\Web
  Destination: D:\Apps\MyCoolApp\Service\Web\Backup

  If you look at the paths carefully, you’ll see it’s a recursive backup. Since the destination is within the source, the backup keeps recursively copying itself over and over; it won’t stop until there’s no storage left or you cancel the process. The team that did this also made the mistake of creating steps for each individual environment rather than sharing steps between environments so this could have been caught in a non-production environment but unfortunately, this was a production error. After several hours of backing up and no storage space (over 10GB consumed for this backup), they contacted us and we were able to hunt down this issue.

• Need to create automatic rollback step(s) – so you’ve backed up your application on your server. Congratulations! Now, how are you going to put it back into place? Hmmmmmmm. Remote Desktop? That’s not ideal now is it? So now you need to make another step if the initial Deploy NuGet package step fails.

To wrap up my rant, I don’t think backups in Octopus are worth the effort. While backups always seem like a solid principle, they seldom are in practice within Octopus Deploy. With NuGet packages at your disposal and source control at the ready, there’s no need to keep creating and storing backup baggage. If left unchecked, backing up your backup directories can consume storage space which ultimately becomes a long-term resource to manage. Backups also lengthen your deployment time. If you want to automate the rollback process you have to add more steps to your process and in practice, there’s no value in backing up non-production environments. They’re may be some value doing production backups by keeping the last previous copy. Our Octopus server has over a hundred teams, several hundred projects, over five hundred attached tentacles and thousands of deployments, I have yet to see a team actually use a backup. Yet many teams continue to backup and in a few cases, this has led us to deployment issues for a handful of teams. While backups are always a good idea in general, within Octopus Deploy I think it’s fools gold and not worth the time or effort.