Recent outages made me realize I've been relying too heavily on a single Git hosting provider. Aside from the copies on my development machine, I don't currently have another remote or downloaded backup of my repositories. I'm considering mirroring my most important repositories, encrypting the backups, and storing them with an object-storage provider. How are others handling off-site repository backups, and what should I make sure not to overlook?
4 Answers
I follow a 3-2-1 approach: three copies, stored on at least two different types of media, with one copy off-site. For example, the working copy, a removable local drive, and an encrypted cloud backup. Automating the process is important, since a backup that depends on remembering to run it usually gets neglected.
A second cloud location is a reasonable option, but don’t stop at uploading an archive. Encrypt the backups, automate the mirroring, and perform a restore test on another machine periodically. The backup only counts if you know you can recover the repository when you need it.
I run a small self-hosted Git service on my NAS and push important repositories to it regularly. The NAS itself gets nightly backups to separate storage. Self-hosting can work well, but keep it patched and isolated—an exposed service can introduce a different security problem.
A Git clone is already a backup of the repository itself, and you can keep multiple remotes so changes are pushed to more than one location. For important projects, I’d use a bare mirror with `git clone --mirror`, then run `git remote update` on a schedule. That preserves all branches and tags better than zipping up a working copy.
Keep in mind that issues, pull requests, wikis, and other hosting-service metadata usually aren’t included in the Git repository. Back those up separately through the provider’s API if they matter.
The definition is specifically three total copies, two different storage media, and one copy kept off-site. Extra copies are fine, but that’s the basic rule.