Dry Run Backup

(A PreventativeAction project management pattern.)

Pattern Name: Dry Run the Backup Procedure

Problem: Lost or corrupted files can temporarily destabilize a project.

Context: You are leading a software development project. Project members may be distributed across a local-area or wide-area network. There may (good) or may not (not good) be centralized source-code control. You are concerned about the risk to project stability of lost or corrupted files.

Forces:

• Organizational backup plans are often made without knowledge of individual project requirements.
• Server configurations evolve over time, and may not be accounted for in the backup plan.
• Procedures for recovering files from backup media may have grown stale or gotten lost.
• The project may not have arranged to have all required source files and documents in the "right" places to be backed up.
• "Murphy's Law"

Partial Solution: Before a real disaster strikes, simulate one. Obtain a copy of the organizational back-up plan. (If there isn't one, you may find yourself assigned the task of creating one, so phrase the request carefully.) Compare the plan against your project's requirements, and look for holes.

Next, arrange for someone else on the project to "lose" several critical files that have been backed up; one from the day before, and one from a previous week. Either the files can be retrieved in a timely manner (leading to greater comfort on the part of team members), or they can't, and you've provided the organization with an opportunity for process improvement.

Resulting Context:

• A backup plan that's aligned with project requirements.
• A project plan that's aligned with the backup plan.
• Raised awareness of the importance of a good backup and recovery process.
• One less source of potential project instability.

See also: CarsBreakSittingInTheGarage

-- DaveSmith 11/1/95

Half the projects I've worked on over the past 10 years have had to rediscover this the hard way.

---

This reminds me of the story AlwaysUseScratchMonkeys. (I think that is the name.)

The lesson is similar to DryRunBackup but it involves the death of a monkey! 8^(

-Patrick Logan

---

I've filled in the reference above but I'd say it's really a separate pattern altogether. Perhaps DontTestInProduction??

-BlakeCoverett

---

I'm embarrassed to now say that this pattern applies to home computers, as well. It's easy to get lulled into a false sense of security by a shiny new home Pentium, only to have that go out the window when the hard drive starts making "running out of oil" sounds. Moving parts do fail. And tape backup is fairly inexpensive these days. At the low end, 200 USD can buy an 800Mb Travan tape drive and a tape.

For me, this was a case of "if I don't think about it, it won't happen, and I won't have to think through the mess of recovering onto a new drive." Sigh.

-- DaveSmith (8/27/96)

...and nowadays, you should be able to get hold of a dvd burner and some media for 200 USD... and what new computer doesn't come with at least a cd burner nowadays?

---

Dare I suggest that there's no excuse for not using a centralized CM system these days? CVS (http://www.cyclic.com) is free, runs on everything, works wide-area, encourages concurrent work, scales (largest project I've heard of using CVS involves 22,000 source files - 2 Gig of source) and is a nice SimpleTool as well. Combine that with a cron job to backup your repository and fear not.

Of course DryRunBackup might be useful as a stress test anyway. But perhaps there's a more realistic test to do?

--PeterMerel

Who setup the cron job, and where is the backup going? Can you get it back? If it's going onto tape, is there a schedule by which the tapes goes offsite? The point is to avoid taking the vague assurance that things are O.K. at face value, and confirm that the net is in place before take your team across the highwire.

UnstableBackups is another reason to do a dry run. --DaveSmith