Back up what you cannot get again: internal packages you published, the mirror's configuration, repository definitions, users, roles and tokens metadata. Skip the proxy cache of public packages, because it refills from upstream. Then test a restore, since an untested backup is a hope, not a plan.
Sort the contents into three buckets
A mirror usually holds three kinds of data, and they deserve different treatment.
| Bucket | Examples | Back up? |
|---|---|---|
| Irreplaceable | Internal packages and images you published, release artifacts | Yes, with versions and history |
| Configuration | Repository definitions, routing rules, cleanup policies, permissions, certificates | Yes, and keep a copy in version control where possible |
| Replaceable | Cached copies of public packages | Usually no |
The third bucket is often the biggest. Backing it up wastes storage and slows recovery.
There is one exception. If a public package may be deleted upstream and you rely on your copy, decide that deliberately. The question of keeping or purging a package removed upstream is covered in a separate post, mirror keeps a package deleted upstream.
What a restore must bring back
Think about the first hour after losing the mirror host. You need clients to be able to install again, and you need your internal packages. Order the restore like this:
- Stand up the mirror software at a known good version.
- Restore configuration and certificates.
- Restore internal repositories.
- Point a test client at it and install a small project.
- Let the cache refill, and watch upstream rate limits.
A backup routine for a small team
- Write down where the mirror stores internal artifacts and configuration, and who owns that path.
- Schedule backups to a location the mirror host cannot overwrite, such as separate storage with its own credentials.
- Keep several generations, so a corrupted state is not the only copy.
- Protect the backups like the mirror itself. They contain your internal code and access metadata.
- Restore into a scratch environment once a quarter and time it.
- Record the result in a short log with date, duration and gaps found.
Keep the secrets in mind
Backups may contain token hashes, user lists and certificates. After any restore from backup following an incident, rotate tokens and review user accounts, because you cannot know what an attacker saw. Also confirm that the restore did not bring back an account you had removed since.
Pair backup with availability planning
A backup restores data. It does not keep builds running during the outage. Decide whether clients fall back to upstream, fail closed, or use a local cache. The right answer differs by team, and a related post on falling back when the mirror is down covers the tradeoffs.
Where Safeguard fits
Safeguard's asset discovery and SBOM features help you keep an inventory of what your projects depend on, which makes it easier to know what a restored mirror must serve. A free scan is at gold.safeguard.sh/scan.
Quick check
How often should we back up?
Match the rate at which you publish internal packages. If you publish daily, back up daily.
Do we need to back up the public cache?
Usually no. It rebuilds from upstream, though a very large cache can take time to refill.
Last reviewed: 19 October 2026.
