summaryrefslogtreecommitdiff
path: root/doc/future_proofing.mdwn
diff options
context:
space:
mode:
authorGravatar Joey Hess <joey@kitenet.net>2011-03-09 01:56:24 -0400
committerGravatar Joey Hess <joey@kitenet.net>2011-03-09 01:56:24 -0400
commit42b7f244060bb9f49f9cbe9e93ee8024a678771d (patch)
tree52a9e261665fa114f74cd773a838d3d8323da2ab /doc/future_proofing.mdwn
parentd7b4c8372b3901e09a0268d55b0a567a878166f2 (diff)
update
Diffstat (limited to 'doc/future_proofing.mdwn')
-rw-r--r--doc/future_proofing.mdwn9
1 files changed, 9 insertions, 0 deletions
diff --git a/doc/future_proofing.mdwn b/doc/future_proofing.mdwn
index d9a36ff73..4fc8246b6 100644
--- a/doc/future_proofing.mdwn
+++ b/doc/future_proofing.mdwn
@@ -25,3 +25,12 @@ problem:
* What is the hardware interface of the drive? Will hardware still exist
to talk to it?
+
+* What if some of the data is damaged? git-annex facilitates storing a
+ configurable number of [[copies]] of the file contents. The metadata
+ about your files is stored in git, and so every clone of the repository
+ means another copy of that is stored. Also, git-annex uses filenames
+ for the data that encode everything needed to match it back to the
+ metadata. So if a filesystem is badly corrupted and all your annexed
+ files end up in `lost+found`, they can easily be lifted back out into
+ another clone of the repository.