kopiaprofile v0.5.15

kopiaprofile 0.5.15

[0.5.15] - 2026-08-12

Fixed

• Corrected how 0.5.14 describes the timestamp its full-maintenance: auto
  decision rests on. The format blob is written at repository creation but
  rewritten whenever repository parameters change, so it is not the
  never-rewritten creation marker the documentation claimed, and its
  timestamp can be younger than the repository itself - seen live on a
  repository whose oldest snapshot predated its own format blob by a week,
  after its retention parameters had been corrected.

  The behaviour is unchanged and was never unsafe: reading a repository as
  younger than it is defers reclaiming, it cannot start it too early. Only
  the reasoning in README, code comments and log field names was wrong; the
  log now says repository-start instead of oldest-blob.

---

See README.md for installation instructions.

kopiaprofile v0.5.14

kopiaprofile 0.5.14

[0.5.14] - 2026-08-12

Added

• New object-lock.full-maintenance: setting (auto | always | never),
  applied before every snapshot as
  kopia maintenance set --enable-full=<value> in both directions, like
  extend-on-maintenance. Default is auto.

  Under a retention lock, full maintenance is pure cost until the first blobs
  can expire: it walks the whole repository, marks everything the snapshot
  retention dropped as unreferenced, and deletes none of it, because every
  candidate is still locked. Observed live on a multi-terabyte repository,
  snapshot garbage collection grew from five to over twelve hours within a
  week, one cycle reported Found 2167(18.1 GB) unreferenced pack blobs to delete and deleted 0(0 B), and a later run outlived its own timeout, was
  killed, and left the profile lock held long enough to block the next
  scheduled run.

  auto decides per run from the repository itself: the format blob is
  written at creation and never rewritten, so its timestamp plus the
  configured retention period is the earliest moment anything in the
  repository can become deletable. Before that, full maintenance is switched
  off; from then on it is switched back on with no date to remember. Quick
  maintenance runs throughout. The bound is conservative on purpose, so auto
  can defer reclaiming but never deletes early, and a repository age that
  cannot be read leaves the maintenance parameters untouched instead of
  guessed at.

  Note for the transition: the first full cycle after the window opens carries
  all the deferred work and will be long. Give it a window.

---

See README.md for installation instructions.

kopiaprofile v0.5.13

kopiaprofile 0.5.13

[0.5.13] - 2026-08-07

Added

• New maintenance-retry: block (attempts, delay). When a snapshot
  succeeds but the auto-maintenance kopia folds into the same run fails,
  retry kopia maintenance run on its own, spaced delay apart, instead of
  repeating the whole snapshot. Off by default (attempts: 0). Targets the
  same transient Wasabi metadata-read glitch retry: already covers for the
  snapshot itself, which kopia's own ~12s retry budget does not survive.

---

See README.md for installation instructions.

kopiaprofile v0.5.12

kopiaprofile 0.5.12

[0.5.12] - 2026-08-04

Fixed

• attempts now actually reaches the status file. 0.5.10 documented the field
  and set it on the result, but the JSON struct had nowhere to put it, so it was
  dropped at serialisation and no monitoring could ever see a repeated run.

---

See README.md for installation instructions.

kopiaprofile v0.5.11

kopiaprofile 0.5.11

[0.5.11] - 2026-08-03

Added

• New policy: block, which declares kopia's error-handling policy in the
  profile instead of leaving it as hand-set state inside the repository:
  ignore-file-errors, ignore-dir-errors, ignore-unknown-types, globally
  and per path. Each target becomes a kopia policy set pre-command before the
  snapshot, the same way retention: and the ignore rules already work.
• Per-path targets are the reason this exists. A live object store keeps every
  object in its own directory and deletes objects while the snapshot walks
  them, so every run reports a vanished entry as a fatal error while the
  snapshot itself is complete. Tolerating that for the one subtree is a
  different decision from tolerating it for the whole host, and only the
  narrow one is safe to make.
• The fields are *bool, so "not configured" and "configured to false" stay
  distinguishable: false is forwarded to kopia, an omitted field emits no
  flag and leaves the repository's value alone. Same reasoning as the *int
  retention values in 0.5.6, where a plain type silently dropped the setting.
• kopiaprofile display prints the block, with - for an unset field.

---

See README.md for installation instructions.

kopiaprofile v0.5.10

kopiaprofile 0.5.10

[0.5.10] - 2026-07-31

Added

• New retry: block per profile (attempts, delay), which repeats a
  snapshot run that failed without having written a snapshot. It
  targets the one failure class that actually costs a backup: a
  transient backend error before or during the upload. Seen repeatedly
  against S3, which answers a small metadata read with HTTP 200, the
  correct Content-Length and an empty body; five hosts were hit in one
  night, the window is minutes to hours, and an attempt an hour later
  would have saved every one of them.
• The retry is deliberately narrow, so it can be enabled everywhere. A
  run is only repeated when the action is a snapshot, the attempt
  failed, and no snapshot reached the repository. Kopia folds a failure
  of its auto-maintenance into the snapshot's own exit code, so a run
  whose backup is in the repository and whose cleanup failed afterwards
  looks like a failure too - repeating that would re-run the same
  failing cleanup for nothing. A run that lost the race for the profile
  lock is not repeated either.
• The retry wraps the pre-commands as well, not just snapshot create.
  The policy pre-commands are the first thing that touches the
  repository, so a failing metadata read surfaces there first.
• The status file gains attempts. start_at stays the first attempt's,
  so duration covers the waiting between attempts, and a monitoring
  check that looks at the age of end_at sees when the run really
  finished.

---

See README.md for installation instructions.

kopiaprofile v0.5.9

kopiaprofile 0.5.9

[0.5.9] - 2026-07-31

First release that actually ships the duplicate-mount exclusion. 0.5.7
and 0.5.8 were tagged but never published: their draft releases were
built while the Windows test job was red, first from an endless loop
(fixed in 0.5.8) and then from the regression test below.

Fixed

• TestDetectDuplicatesSkipsExcludedMountpoints failed on Windows. Its
  first half needs a detected duplicate, and deviceOf has no device
  number to compare there, so the call returned no group at all - the
  same reason TestDetectDuplicatesSameFilesystemTwoMountpoints already
  skipped that platform. Test-only; no change to the binary's behaviour
  on any platform.

---

See README.md for installation instructions.

kopiaprofile v0.5.6

kopiaprofile 0.5.6

[0.5.6] - 2026-07-30

Fixed

• A retention value of 0 in a profile now reaches kopia instead of being
  silently dropped. retention.keep-* were plain ints, so keep-hourly: 0
  was indistinguishable from not mentioning keep-hourly at all: no
  --keep-hourly flag was emitted and whatever kopia already had in its
  global policy stayed. On a fresh repository that is kopia's own default,
  so a profile could declare keep-hourly: 0 and keep-latest: 0 while
  the repository kept expiring against 48 and 10. Zero is how a retention
  class is switched off, so it has to be forwarded.

Changed

• retention.keep-* are now optional (*int) so "not configured" and
  "configured to zero" are distinct, the same distinction kopia makes
  internally with snapshot/policy.OptionalInt. Unset fields still emit no
  flag and leave kopia's value alone; existing profiles are unaffected.
• kopiaprofile display prints an unset retention value as - instead of
  0, and now also shows hourly. Printing both cases as 0 hid exactly
  the difference above.

---

See README.md for installation instructions.

kopiaprofile v0.5.5

kopiaprofile 0.5.5

[0.5.5] - 2026-07-29

Fixed

• object-lock.extend-on-maintenance now actually does something. It was
  read into the config struct and then never used: the function meant to
  apply it existed but had no callers, so every profile could declare
  extend-on-maintenance: true while the repository had extension
  disabled the whole time. Confirmed live across a fleet - every
  repository reported "Object Lock Extension: disabled" while every
  profile claimed otherwise. It is now applied as a pre-command before
  each snapshot, on the same path as the policy pre-commands, so it runs
  against the already-connected repository and cannot silently become
  dead code again.
• The value is written in both directions
  (--extend-object-locks=true|false) rather than only when true, so the
  profile is the single source of truth and flipping it back to false
  actually disables extension instead of leaving a stale setting behind.
• The pre-command password is now loaded whenever any pre-command is
  queued, not only when policy arguments were built. Previously a
  pre-command that ended up being the only one would have run without
  credentials.

Changed

• wrapper.ApplyObjectLockMaintenance is replaced by
  wrapper.BuildObjectLockMaintenanceArgs, matching the other
  Build*Args helpers.

---

See README.md for installation instructions.

kopiaprofile v0.5.4

kopiaprofile 0.5.4

[0.5.4] - 2026-07-29

Added

• run-timeout per profile: caps how long a single kopia invocation may
  run before it is killed, as a Go duration string. The cap used to be
  hardcoded at 24 hours with no way to change it, which silently
  truncated any run that legitimately needed longer. Observed live on a
  multi-terabyte initial snapshot that had written 1.2 TiB when the cap
  killed it after exactly 24h, leaving only checkpoint snapshots in the
  repository and no way to ever complete in one run. Unset still means
  24h, so nothing changes for existing configurations. A malformed or
  non-positive value is an error rather than a silent fallback to the
  default - quietly reinstating the 24h cap on a profile that asked for
  more would reintroduce exactly the truncation the setting prevents.

---

See README.md for installation instructions.