Backups are important in the business world. They’re even more important in the digital world. Information is volatile and susceptible to easy deletion, as I’ve recently been reminded.
I’ve been a registered iOS developer for several years now and an OS X dev for about a year. One of the perks of being a developer is being granted beta access to software before it’s fully released to the public. Beta software, however, is usually riddled with bugs. As it turns out, many of my heavily used applications are not compatible with iOS 8.
Immediately after updating my phone, I proceeded to install OS X 10.10 Yosemite on my MacBook Pro. All appeared to be going well until it hung on “5 minutes remaining” for nearly three hours. As is the standard step one for any tech project, I restarted it and tried again to see if it would fix the solution. Sadly, it did not, and I was left with a non-booting laptop.
Thankfully, I have backups, and plenty of them. Until recently, I used Dropbox to store all of my photos and PDF files, though I’m slowly migrating all of that over to ownCloud. I have a 500GB drive attached to my home-office dock that runs hourly TimeMachine backups. I also back up remotely to CrashPlan, ensuring the ability to do a full data recovery in the event of a house fire or some other catastrophic event. My home servers also back up to CrashPlan, and all of my iDevices back up to iCloud.
Backups go beyond data, though. Being a software developer in 2014 means that having access to the Internet is quite important. I can’t get updated code from my peers, deploy a staging site, or respond to emails with funny GIFs without a connection. I have Comcast Internet at home, but I also have the ability to tether off my phone or use a 4G hotspot in case that connection drops. If my motorcycle fails to start, I can take my car into work. If my laptop were to die a horrific death, I could use my iPad with a Bluetooth keyboard to SSH into a remote server and code. One of the the major upsides to coding with vi(m) is that it’s installed on almost every *NIX distro, but that’s a conversation for another day.
At Software for Good, we follow even more rigorous backup policies. Our code is automatically backed up to GitHub as part of our programming workflow. Production Postgres and MySQL databases are backed up every 6 hours, and virtual servers are typically on a 7-day rolling backup schedule. Design files are backed up with BitSync, allowing designers to simultaneously back up files and share them with front-end developers. While each project has a lead developer, that person is rarely the only developer on a project.
In the software development world, there is a concept known as “bus factor.” In short, the bus factor is the number of people who would need to be killed by a bus in order to stop the project dead in its tracks. Sounds morbid, and it is, but it serves a good purpose. If you only have one developer working on a project and then that one dev is no longer available, you now have to do a complete ramp-up of a new developer with almost no knowledge about the project’s current state. To combat this, we usually have second developers check in on projects once or twice a week, just to get a feel of where things are at, be brought up to speed on current issues, and double-check any critical decisions made. While some clients may balk at this, as it is a slight increase in development cost, the long-term gains strongly outweigh the short-term costs. No matter what it is, we make sure to back it up, not only because it’s important to us, but because it’s also important to our clients.
Right now my MacBook Pro is restoring from a TimeMachine backup created last night at 11:42pm. It is estimating to take ~4 hours to complete, though if that ends up being true, it’s far shorter than it would have taken me to set up my machine from scratch.
