Skip to content
downpipes docs

Remove a destination without orphaning your backups

Removing a destination is owner-only, and the engine will refuse it in two different situations. The two look similar in the moment and are not the same: one you can override, and one you cannot.

Refusal one: a downpipe pins it

If any downpipe names this destination explicitly, as its primary or as a replica, the removal is refused and there is no force for this one. The message names the downpipes.

The reason it is absolute is that a pinned destination id never silently falls back to something else. Removing it would leave those downpipes pointing at an id that does not exist, and their next run would fail rather than quietly writing somewhere sensible. Reassign them first, then remove.

Refusal two: it holds the only proven copy

This is the data-loss guard, and it is the one force overrides.

Under 3-2-1 failover a run may have sealed here and not yet been replicated anywhere else. This destination is that run’s recorded origin, and for the moment it is the only proven copy. A run stops counting against this guard once another destination’s replication has caught up past it.

The refusal names the count and the downpipes: the only proven copy of N backed-up runs.

Unpinned downpipes count too. A downpipe with no explicit destination seals to whatever the default is and records no origin id, so removing the sole default still counts those runs against the guard. You do not have to have pinned anything to be protected by it.

What forcing actually costs

Forcing does not merely un-reference those archives. The destination’s credentials go with it, so the bytes stop being readable at all. An archive whose only proven copy was at a destination you have force-removed is not recoverable afterwards by re-adding the destination from memory, because the stored credential is gone.

So the guard is not being cautious about tidiness. It is the difference between N runs you can still restore and N runs you cannot.

Forcing is still allowed, because sometimes dropping those copies is the deliberate decision. When you do, the engine records how many runs it just orphaned, computed before the removal and kept as the magnitude of the loss. That count exists so the event is auditable later rather than being reconstructed from what someone remembers choosing.

Usually the right move is to wait

The replication pass copies the backlog every tick, so this guard clears itself. The count falls as the runs it names get copied elsewhere, and then the removal succeeds with no force at all.

Three options, in the order worth trying them:

  1. Wait. Watch the redundancy map, which shows each run as N of M copies. When the runs this guard names have a second copy, the refusal stops.
  2. Reassign the downpipes to another destination, so new runs seal elsewhere while the backlog drains.
  3. Force, having decided those copies are expendable.

The default is promoted silently

One side effect worth knowing before you remove anything: if the destination you remove is the current default, the next remaining destination silently becomes the default. Nothing asks you to confirm which one, and it is chosen by position rather than by any preference of yours.

So after removing a default, check which destination is now the default before the next run seals to it. Every unpinned downpipe follows that choice.

What is recorded

A removal request raises a destination-change alert, and it says explicitly when force was used, so a forced drop is distinguishable from an ordinary one in your notifications rather than only in the engine’s own records. The two refusals are also recorded as separate classes, so “the engine refused to drop the only proven copy” and “an operator gave up” are distinguishable after the fact.

Where this fits

Last updated .