2 ms·
> Git repo corruption from snapshotting tech (tarball, zfs, rsync, etc): The link discusses why rsync and tarballs are not good backup solutions. But, those wo
by kentonv 10y ago
> Git repo corruption from snapshotting tech (tarball, zfs, rsync, etc):
The link discusses why rsync and tarballs are not good backup solutions. But, those wouldn't rightly be called "snapshots". "Snapshot" implies atomic, right? Surely an atomic snapshot would not corrupt git -- I would expect git, like any database, is designed to be recoverable after power failure, to which recovering from an atomic snapshot should be equivalent.
Or is that not the case?
- jamesmiller5 10y agoThat is actually not the case. Say a git server is in the middle of a write to refs/heads/master . You atomically snapshot the FS and then a power outage kills the server. The repository state will have a small chance of lock files that are never removed. Depending on the lock, future writes to a ref or to the repository can fail. Not the worst situation as data lose won't occur but definitely not a stable state. If you treat git repositories as a service that needs a recovery step it would be fine, unfortunately most don't. (edit) source: http://joeyh.name/blog/entry/difficulties_in_backing_up_live_git_repositories/ http://joeyh.name/blog/entry/difficulties_in_backing_up_live...
- kentonv 10y agoOK, from your link, it looks like the only problem affecting atomic snapshots is that `.git/index.lock` could be left in existence which will block git from doing any operations until it is deleted. For some reason git will instruct the user to delete this file but will not do it automatically, even though it could actually check if any live processes have the file locked, and assume that, if not, it is stale. Seems like a bug in git IMO, but still reasonably easy to recover from.