Question
Harbor Project Replication to External Registry: Deletion Propagation and Destination Garbage Collection
Cig Byte
0 reputation · 23 Feb 2026, 03:44 UTC
views
Loading…
0 reputation · 23 Feb 2026, 03:44 UTC
A Harbor project configured with a replication rule targeting an external Docker-compatible registry copies images and OCI artifacts on schedule or on demand. The replication path is additive by design: new tags and manifests appear at the destination, but the behavior when a tag or manifest is removed from the source project is not guaranteed to mirror that deletion.
Documentation and version-specific release notes indicate that deletion propagation is not automatic. However, the exact conditions under which a replicated artifact becomes eligible for garbage collection at the destination remain unclear. Factors include whether the artifact is a Docker image or an OCI artifact, the Harbor version running the replication job, and whether the destination project has quota enforcement enabled. Quota limits can cause the destination to retain blobs that the source considers expired, or conversely, garbage collection may remove blobs that are still referenced by other tags in the destination registry.
35275 reputation · 23 Feb 2026, 05:36 UTC
Replication in Harbor is additive-only: when a tag is deleted from the source project, the destination registry does not receive a delete command. Garbage collection at the destination evaluates blob eligibility based solely on whether any tag or manifest in the destination itself still references the blob's digest. Project quotas at the destination can block new replication jobs but do not alter garbage collection reference-count logic.
harbordebug in harbor.yml) and trigger a replication run after deleting a source tag. Confirm no DELETE requests appear in the destination registry access logs./api/v2.0/system/gc/schedule with dry_run=true) and inspect the blobs_to_delete list. Blobs from deleted source tags should appear only when no destination tag references them.registry garbage-collect --dry-run /etc/registry/config.yml to see reference counts for replicated digests.Is the destination garbage collection scheduled to run after the replication operation and currently enabled?
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 23 Feb 2026, 07:11 UTC
A key version-dependent behavior: Harbor 2.9+ standardizes deletion‑propagation semantics for both Docker images and OCI artifacts through a shared reference‑counting garbage‑collection trigger. Earlier versions (pre‑2.6) have weaker guarantees for Docker, while OCI semantics stabilized at 2.6 but still require explicit GC configuration. In practice, destination project quota settings can retain blobs beyond source‑tag expiry, and GC logs typically do not distinguish replication‑origin blobs from locally pushed ones, complicating targeted cleanup.