Tess Flynn: Tractorbeam Site Backups
Tractorbeam, an Open Source Website Backup Tool – Is your website backed up? No, we mean is it backed up correctly? The number of sites that are not is simply staggering, a guess, but staggering nonetheless. The absence of a valid site back is most painful when it is immediately needed. Ensuring that a valid open source back up exists is the primary function of the Tractorbeam tool. Listen and learn more about Tractorbeam.
Here's what we're discussing in this podcast:
- What is Tractorbeam?
- Why do website owners need it?
- How did Tractorbeam evolve?
- Why is the open source license for Tractorbeam so important?
- What does the future hold in store for Tractorbeam?
JONATHAN FREED: Hello! You're listening to a TEN7 Audiocast. We're here today to discuss Tractorbeam, open source website backups. I'm Jonathan Freed, and I'm here with Ivan Stegic, founder and president of TEN7. And joining us today is Tess Flynn, TEN7's very own DevOps. Tess let’s jump right into this, can you tell us exactly what Tractorbeam is?
TESS FLYNN: So on galaxy class starships, you have a graviton emitter... sorry wrong tractorbeam. So Tractorbeam is an open source website backup tool that is written in Ansible. So Ansible is a configuration management and automated scripting utility that is created by Red Hat. And we created Tractorbeam to suit a client need for a website offsite backups. Where we didn't have the existing tool kit that we had come to expect.
IVAN STEGIC: And why do you think people need this thing?
TESS: I remember once when I was visiting the IBM Tech Labs in Hursley, and they were talking about geographic backups, and my mind felt like it had expanded, because the idea of creating geographically distributed backups just in case of natural disaster had never occurred to me until that exact moment. Afterward, I'm like "Okay, we need to make sure we track everything here."
JONATHAN: Can you give us a little bit on the evolution of Tractorbeam?
TESS: So we have a client that had a new Drupal 8 site. Part of our requirements for that project was to provide offsite backups and naturally the first that thing we decided to do is reach for the backup and migrate module which did exist and does still exist for Drupal 8. And our thought was "Oh sure! We'll just put NodeSquirrel on it like all of the other sites and that will be it. And then, we found out that there was no NodeSquirrel for Drupal 8, and in fact the more we start looking at the backup and migrate module, the more we discovered that it was at a very early stage. It didn't quite work very well for Drupal 8 at all. And there were a number of other gaps. One of the biggest gaps with NodeSquirrel is that typically it only backs up the database. It doesn't back up your site code and unless if it's configured to do so, it won't backup your upper files. So that's actually a huge problem, because you now have an incomplete backup. If you try recovering from a total hardware or software loss from your site, from the NodeSquirrel backup that is only your database, you'll have a lot of work ahead of you even if you have a local copy of the site code, because if you are using something like stage file proxy, you might not have a local copy of all your uploaded files. And you'll be spending a lot of time. If you're lucky maybe asking your hosting provider for a server level backup to restore those files. But in a lot of cases, you might have a total loss. So when we discovered this gap, we went "Oh Gee! What are we gonna do?" And the wheels started turning shortly there afterwards that as part of of our automation efforts, I have already ready written a backup mechanism for our deployments that every time we do a deployment, we back up a file directory, back up the site code, and we backup the database. And it does that in nice automated script which is all on Github and all Ansible galaxy for anyone to use. The idea of well we need to make this remote as well, and that's where it started. We had the idea of coming up with an intermediary system that would actually execute the Ansible playbooks, to run the backup on the site. Just like we would with the build, but in this case, it would be by Cron job to to run on a regular basis. Furthermore, we enhance that basic functionality by uploading those backups to Amazon S3 or really any S3 compatible cloud hosting provider. This way we actually did get the offsite backup and geographic distribution back up that we wanted that was on all open source code. All of Tractorbeam is hosted on Github and you can start using it whenever.
IVAN: So that's a good point. Tractorbeam as Jonathan described is open source website backups. Why is the open source license for this particular tool so important?
TESS: A lot of the things that we like producing at TEN7 are going to be open source by default. That's one thing we pride ourselves on but furthermore than that, keeping your backups and backing up your site is really, really, really important, and not enough people are actually doing it because in order to it, to do this kind of all site backup situation, it takes a lot of work! So we did the work for you and we open source it so that you can have your site backed up finally.
JONATHAN: Tell us about the future of Tractorbeam.
IVAN: So Tractorbeam right now is a set of tools, a set of Ansible playbooks as Tess described that can do the backups for you logistically. We'd like to beef up the documentation so that people have a much easier time of actually deploying the Ansible playbooks. We'd like to add additional backends so that that it's not just S3 that you can push to, but there are other different backends, Google Cloud engine, a Vanilla SFTP Server, Microsoft Azure, whatever makes sense you should be able to push your backups to. Right now, we could support Drupal 6,7, and 8 as part of the Tractorbeam Ansible playbooks but we'd love to expand that so that it doesn't just include Drupal but that includes Wordpress and ExpressionEngine and anything else that is PHP and MySQL backed. But more so, I think we'd like to see a software as a service company built out of this as well. There is a lot of opportunity for people who just want to set it and forget it. if you could set up a back up that's literally 30 seconds worth of your time and it's outside of your ecosystem of the host you're using like Pantheon or Acquia or Wordpress Engine or Wordpress.com itself then that's something to be said. So look out, there's lots of things coming for Tractorbeam.
JONATHAN: Well that brings us to the end of this Audiocast and I would like to thank Tess Flynn and Ivan Stegic for sharing their insights on Tractorbeam. Please visit us as TEN7.com and keep an eye out on the TEN7 blog for future Audiocasts. This is Jonathan Freed and thank you for listening.