Pixar’s Unlikely Backups

Pixar ran into some misfortune that really illustrates the importance of not just a good backup, but a secondary, offsite backup as well.

Each month, Gillware participates in a blog exchange with backup and disaster recovery leader StorageCraft Technology. We’ll feature a post from their Recovery Zone blog and they’ll share a post from the Gillware blog. This post was written by Casey Morgan, Marketing Content Specialist at StorageCraft. We hope you enjoy it, and you can look forward to another like it next month!

The best way to protect your data is to make a copy of it—a backup. Backups are great, but sometimes one backup just isn’t enough.

Pixar ran into some misfortune that really illustrates the importance of not just a good backup, but a secondary, offsite backup as well.

 

The Story

Basically, Pixar was working on the animated film Toy Story 2 (1999) on Linux and Unix machines. As techies know, a lot of the power of Linux and Unix is unlocked through the command line. Well, someone at Pixar entered the command RM* on the file systems where Toy Story 2 was stored. This particular command tells the system to empty its files as quickly as possible. Animators working on the film watched as file after file disappeared, until the most of the entire film was gone—thousands of hours of work were deleted in just a few seconds.

We don’t know why that employee entered the RM* command, but they did, and Pixar had to figure out a way to fix it.

Luckily, multimillion dollar companies don’t mess around when it comes to data, so of course Pixar had backups of their file system.  The trouble came when the systems team looked at the backups more closely and realized they had failed for the last month. The data that should have been backed up never was and the team thought Toy Story 2 was gone forever.

 

A Typical Pixar Happy Ending

Pixar was extremely fortunate. The technical director of the film had been home a lot to be with her newborn son, where she continued working on the film remotely. In order to keep working, the director periodically copied the entire film to her computer. In this case, these copies became a handy offsite backup when the main backups didn’t work. The crew brought her system back into the studios and managed to recover the entire film, all thanks to her need to work from home.

 

The lesson here is two-fold. One: have backups. Two: have secondary backups. Failure can keep backups from functioning, but disaster can completely destroy any on-site backups you have—they might not be salvageable if the equipment itself is obliterated by fire or other damage (though in some cases, they can). If you’ve got backups safely stored offsite, you won’t run into this type of problem at all.

If you’re really hoping to keep your data safe, think in terms of redundancy—the more copies of your data, the safer it will be.