Back up a Git repository — properly

No. A default git clone gives you one branch's tip and a working tree — every other branch, tag and note is left behind. Running git clone --mirror fixes that by capturing every ref, but only for the instant it runs; the moment someone pushes again, that mirror is stale. A real backup needs full-ref coverage and something that reruns automatically after every push, not a command you remember to type.

Every ref in the repository — branches, tags, notes and the full commit graph, using the same semantics as git clone --mirror. Provider-internal refs such as refs/pull/* and refs/merge-requests/* are deliberately excluded, since every provider rejects pushes to them. A complete backup can also optionally include the repository's metadata — issues, pull requests, reviews, comments, labels, milestones and release notes — captured as JSON alongside the code when the destination is object storage. Git LFS pointer files replicate; the LFS object content itself does not.

As often as the repository changes, which is why a fixed interval is the wrong starting point. GitHub, GitLab and Bitbucket sources back up on every push, the moment your provider delivers the webhook. Self-hosted and custom remotes don't support webhooks, so they sync on a schedule instead — hourly, daily or weekly — or on demand before a risky operation. Push-triggered wherever it's available, with a schedule as the floor everywhere else.

It depends on where the backup lives. If it's a replica on another Git host, point your remote at it — it's already a working repository. If it's an archive in object storage, download the zip, unzip it, and run git push --mirror against a new remote; every ref goes back in a single push. Either way, restoring is an ordinary Git operation, not a proprietary import process.