Back when I was an undergrad, the fire alarm went off while I was working in the lab. As people gathered outside the building, it became clear that it wasn’t a drill – I don’t recall specifics, but I think it was actually an issue in a neighboring building that caused someone in our building to pull the fire alarm. In the end, it wasn’t a big deal (even for the neighboring building!) But while people were standing around outside, the conversation turned to how much data would be lost if there was a full-on fire. It was clear that lots of people did not have complete backups of their lab notebooks and other data files.
When I was telling about this experience to a friend, Brooks Kuykendall, he told me of his father Bill’s related horror story. In the fall of 1963, Bill had completed his PhD research at Johns Hopkins in Archaeology, and started teaching at Erskine College in rural South Carolina. In the summer and early fall of 1964, after his first year of teaching, he had managed to finish writing his dissertation. In early October, he had assembled the six copies (and these were the days of carbon copies) ready to be submitted to his committee. They were stacked on the floor of his office, needing only to be packed off to go in the mail.
And then that night Bill heard the sirens. Rushing to his office, he found that the building was on fire. The firemen had cordoned it off, but somehow two students—of whom he forever after spoke with gratitude—managed to get in through the window of his ground-floor office, recovering only 1) a single rough draft for the whole text, and 2) a box that had the originals for all of the illustrations. The copies on the floor—and virtually everything else in the office—were ruined by the water.
If not for the illustrations, Bill said he would have given up. Going back to Hopkins to restart everything wasn’t really an option. As it was, even with the illustrations and the earlier draft, it delayed him finishing by two years. And, not surprisingly, while he worked on rewriting his dissertation, he kept multiple copies — one in a neighbor’s safe and another in his car. He could not afford to lose it again!
Perhaps because of hearing this story early on in my research career, I’ve generally been pretty careful about backing up data. I didn’t want anyone to feel compelled to run into a burning building on account of my data! Fortunately, backing things up has gotten much easier since the 1960s. I remember being told very early in my career that the goal was to have the originals of your lab notebooks, datasheets, etc. at work and the backup at home— and I remember being told that the rationale was that, if something happened to both those places at once, your data would not be high up on your list of concerns. So, as a grad student, I would regularly carry my lab notebook and data sheets to the copier down the hall, photocopy them, and bring them home where they gathered in stacks. (I eventually collated them and put them in binders.)
I continued to use and recommend that system, at some point switching from paper copies to pdfs, after I started my own lab. But, over time, technology has shifted to the point where that old system didn’t seem to make sense (and, just as importantly, where people weren’t generally doing it – though one undergrad did think it was pretty cool to actually use a photocopier, which he clearly viewed as an archaic piece of equipment.) At some point, we switched to a plan where people in the lab were supposed to take a picture of their lab notebooks and data sheets and upload them to an app that stores things in the cloud. But follow through with that was not good, in part because people were running into upload limits.
Clearly we needed a new system. And, as we prepared to move to a new building, I realized that it was especially important that we make sure all our notebooks, data sheets, etc. were backed up in case something went missing in the move. One lab notebook disappeared in our move from Georgia Tech to Michigan – if something happened in the move to our new building here at Michigan, I wanted to make sure everything was backed up! And, of course, backing up data is an important part of a data management plan, which is required by NSF.
So, I asked on twitter about what other labs do and ended up deciding that a solution offered by Elizabeth Ostrowski made the most sense for the lab:
I’ll describe the system more tomorrow but, in my opinion, the most important thing is: people are actually using it!
(Many thanks to Brooks for assistance with this post! Brooks has his own musicology blog, Settling Scores. I have no idea what the potential readership overlap is between Dynamic Ecology & Settling Scores, but I suspect it’s greater than zero. Here’s a post that mentions both his dad and Louis Agassiz, and here’s one about the soundtrack of Star Wars.)
Dynamic Ecology 
The post mentioning his dad and Agassiz is about “phylogenetic reconstruction” in music. It’s very interesting, and only a bit of it was above my head (I was a drummer in school, I can only read rhythms, not notes). Many of our readers will want to click through, I think!
Pingback: My lab’s new lab notebook backup system. Part 2: The system | Dynamic Ecology