Regularly snapshot dev infrastructure.

[nejucomo]

If the dev infrastructure crashes or is maliciously corrupted/deleted, the Tahoe project would be severely set back.

This is in contrast to source code, which is distributed across many dev machines (including revision history which protects against in-history corruption).

To improve reliability of the whole project, the development data, such as tickets and wikipages should be backed up.

Tahoe should eat its own dogfood and backup this crucial data onto a grid with a well-known readcap. This backup should be versioned to protect against in-history corruption. Tahoe naturally protects against out-of-history corruption (ie: altering storage files directly).

This approach would have a single-point of failure *per* snapshotting process, but there can be multiple different snapshot directories.

[warner]

FYI, I implemented a git-based backup of the allmydata.org/trac/tahoe environment on 01-Jul-2009. Every six hours, all non-ephemeral Trac state is copied into a directory and checked into a Git repository. Both zooko and I pull copies of this repo manually (whenever we think about it). The next step will be to automate the pull.

While this approach doesn't use Tahoe, I think it's still pretty robust. Using Git gives us easy access to history as well as significant space savings (the SQL textdump of the trac.sqlite database diffs nicely, and all VCSes are designed to handle text diffs efficiently).

While eating-your-own-dogfood has its merits, in the interests of safety it might make more sense to diversify the tools we use for backup purposes. Imagine the worst-case scenario: an omnipotent (but very selective) rogue AI manages to delete every copy of tahoe in the entire world! Now how do we use our clever tahoe-based backup scheme to recover a copy of tahoe? :-)

[zooko]

Honestly, it makes me sad to eat other people's dog food. Yecch. Also, I haven't gotten around to git cloning that backup, so currently the fate of the trac state rests solely in Brian's hands. I hope the evil AI deletes every copy of git in the world, and I hope that Nathan implements backup of our trac onto Tahoe-LAFS.

Also, slightly more seriously, I think there's almost no difference between the git-based backup that Brian already scripted and the equivalent Tahoe-LAFS-based backup. If someone wanted to do it, especially if that person had sufficient permissions on the allmydata.org server, it would probably be easy.

[zooko]

P.S. Also note that bzr can now be aimed at a Tahoe-LAFS backend: ​https://bugs.launchpad.net/bzr/+bug/294709

[zooko]

I hereby declare that Brian having backups of the dev infrastructure in git is sufficient to close this ticket.