What's the best way of backing up the git repository itself? I feel fairly comfortable using a special remote to create an offsite backup in S3 or Glacier or whatnot, but restoring from those still requires I have a working repository somewhere that can map chunks back to files, no?
I can probably just create a repo that has no content, tar it up, and store it on my backup medium (or on bitbucket or wherever), but that seems kinda hackish--it'd be nice to handle this within git-annex. In fact, it'd be really neat if I could handle this with any existing special remote--for example, if there were a way to commit and restore the git repo state (and symlink tree) to the remote. But that doesn't seem to exist. Is there a recommended approach for this? Am I just missing something obvious?
Thanks.
The best way is to make a git remote and let
git-annex syncsync with it. You can put the git remote on github, gitorious, any server with ssh, any server with rsync, a local backup drive, etc.Special remotes are key/value storage; this is not a very good match for the access patterns needed for a git remote.
Thanks for the tip!
Yeah, I get that special remotes aren't meant for this, and backing up a bare (i.e. contentless) git repo somewhere else is pretty trivial. My only point was that it'd be nice to have a single unified offsite backup--if you backup the content to S3, say, and the git repo itself to Github, you now have two points of failure and, in some sense, twice the management hassle. (I now need both my Amazon and Github credentials to restore, for example.)
This seems somewhat undesirable in a backup system.
An easy way around this may be for me to just have a wrapper script that first backs up content to the special remote and then copies the .git repo (minus the objects) to the same place. So it's something I can easily enough work around.
Storing a tarball of the .git repository as a file inside the repository presents a chicken and egg problem when it comes to restoring it. You'll have to find the object file that git-annex has stored in the special remote. If the special remote is encrypted, you may not be able to decrypt it without the key stored in the repository. Etc.
Better to make a clone of the git repository elsewhere.