Setting Up Harbor Image Replication for Disaster Recovery

Problem: Single‑site Harbor risk

When a Harbor registry lives in only one datacenter, an outage there makes every image unavailable. CI jobs that need to pull base images fail, and deployments stall until the site is restored. The cost of downtime grows with the number of services that depend on the registry.

Thesis: Use Harbor’s built‑in replication

Harbor can copy selected projects to a second instance automatically. Once a replication policy is active, the secondary registry holds a near‑real‑time copy of the images, giving you a hot standby without extra tooling.

1. Understanding replication policies

A replication policy defines what to copy, where to send it, and when to run. It lives on the primary Harbor and references a target registry endpoint. You can choose:

• Project scope – all repositories in a project or a filtered set.
• Trigger – a cron‑like schedule or an event‑based trigger (e.g., on push).
• Options – enable garbage collection on the target, overwrite existing tags, or skip already‑present manifests.

2. Configure primary and secondary endpoints

On the primary UI go to Administration → Replication → Endpoints and add a new endpoint:

Endpoint name: harbor-dr URL: https://harbor-dr.example.com Username:  Password:  Verify SSL: false   (set true if you use trusted certs)

Make sure the primary can reach the secondary on TCP 443; adjust firewalls accordingly.

3. Create a replication policy

Still under Replication → Policies click New Policy and fill:

Name: dr-sync Description: Disaster‑recovery mirror of production project Source: Namespace/Project = production Destination: Endpoint = harbor-dr, Namespace/Project = production Trigger: Scheduled, every 15 minutes Options: Enable garbage collection on target, Overwrite existing tags

Save the policy; it will appear with status Inactive until the first run.

4. Monitoring and troubleshooting

After the first scheduled run, open Monitoring → Replication. Look for entries with Success and note the timestamp. If you see errors:

• Check the replication log for HTTP status codes (e.g., 401 means bad credentials).
• Verify that the secondary endpoint is reachable from the primary host: curl -k -I https://harbor-dr.example.com.
• Ensure both Harbor versions match (e.g., 2.8.x) to avoid API mismatches.

Worked example

Assume you have admin credentials admin:secret123 on both instances. The steps above create a policy named dr-sync that mirrors the production project from https://harbor-primary.example.com to https://harbor-dr.example.com every 15 minutes. After the first run you can verify:

# List policies via API (run on any host with curl and jq) curl -k -u admin:secret123 https://harbor-primary.example.com/api/v2.0/replication/policies | jq '.[] | select(.name=="dr-sync")'

The output should show status: active (or idle between runs). To test an image:

docker pull harbor-dr.example.com/production/nginx:latest docker inspect --format='{{.RepoDigests}}' harbor-dr.example.com/production/nginx:latest

Compare the digest with the same command pointed at the primary; they should match if replication completed.

Trade‑off / limitation

Replication duplicates storage and consumes bandwidth equal to the size of the transferred layers. Network latency means the secondary may lag a few minutes behind the primary, so treat it as eventually consistent. Critical workloads that require the very latest image should either pull from the primary or accept a short window of staleness.

Actionable closing

1. Start with a low‑risk project (e.g., a test library) and verify the sync.
2. Run docker pull from the secondary and compare digests.
3. If successful, promote critical projects and add the replication health check (e.g., query the /api/v2.0/replication/policies endpoint) to your monitoring system.
4. Review storage usage on the secondary and adjust garbage‑collection settings as needed.