@@ -7,9 +7,9 @@ to "thin out" over time while retaining most recent archives. Your backup
77script runs `borg create`, immediately followed by `borg prune`.
88
99Assume today is 2026-06-04 and you always start your backups at 16:00. You have
10- been creating backup archives starting at 16:00 on most days going back to late
11- 2025. Today, `borg create` took a little longer than usual. It's 16:12 now and
12- you run `borg prune`.
10+ been creating backup archives starting at 16:00, followed by pruning, on most
11+ days going back to late 2025. Today, `borg create` took a little longer than
12+ usual. It's 16:12 now and you run `borg prune`.
1313
1414You want Borg to keep one archive per day for one week, four weekly archives,
1515one archive per month for five months, and two yearly backups. For that, you
@@ -115,16 +115,22 @@ later reference time, e.g. `--since '2026-06-04 23:59:59'`.
115115and `--keep-monthly`, too. The archive is effectively kept by `--keep-daily`,
116116but how this affects other rules differs between *count*- and *interval*-based
117117policies. For *interval*-based rules like `--keep-monthly 5m` it has no effect:
118- The rule simply keeps one archive fewer.
118+ The rule simply keeps one archive fewer in that case .
119119
120120For *count*-based rules like `--keep-weekly 4` it has an effect: The policy
121- tells Borg to keep 4 weekly archives, and if 2026-05-31 is kept by another
122- rule already, Borg compensates by keeping an older archive instead.
123- Consequently, Borg will also keep the 2026-05-03 archive.
121+ tells Borg to keep 4 weekly archives. Weekly slots are identified by ISO week
122+ number; in this example the four kept archives cover weeks 18 through 21. If
123+ 2026-05-31 is kept by another rule already, Borg compensates by keeping an
124+ older archive instead. Consequently, Borg will also keep the 2026-05-03 archive.
124125
125- Since 2026-05-24 and 2026-03-31 were skipped, there are no perfect candidates
126- for that week and month. Borg chooses the next best candidate, so it keeps
127- 2026-05-23 as the weekly and 2026-03-30 as the monthly candidate.
126+ The week 22 slot is consumed by that same 2026-05-31 archive. Any other
127+ archive from that week is not kept by weekly, even if it falls within the
128+ daily window boundary. This is why 2026-05-27 is pruned: it has just fallen
129+ out of the daily window, and no other rule covers it.
130+
131+ Since 2026-05-24 and 2026-03-31 were skipped, Borg substitutes the next best
132+ candidate for each: 2026-05-23 fills the week 21 weekly slot, and 2026-03-30
133+ fills the March monthly slot.
128134
129135The implementation of `--keep-monthly 5m` is somewhat special: Borg defines a
130136month as a fixed 31-day period, independent of the actual calendar dates
@@ -144,6 +150,6 @@ Intervals and counts can be mixed freely. Yearly retention in this example is
144150done by retention count instead of intervals. A count rule paired with interval
145151rules behaves just as it would if all preceding rules were also counts:
146152Archives already kept by earlier rules are excluded from consideration. In this
147- example there is only one "true" yearly candidate, so the oldest archive at
148- 2025-11-15 is kept. This oldest archive will be kept until the rolling backup
149- scheme reaches "steady state" (when all retention rules are fully satisfied) .
153+ example, every yearly slot is consumed by earlier rules; no true yearly
154+ candidate remains, so the oldest archive at 2025-11-15 is kept to preserve
155+ rolling backup semantics .
0 commit comments