Add --protect-last=N option (server-side partial immutability)

[tkn777]

Hi, and thanks for maintaining Borg!

I’d like to propose a small server-side feature to improve ransomware resilience:

a --protect-last=N option for borg serve, similar to --append-only, which keeps the most recent N archives undeletable.
The idea is minimal, fully backward-compatible, and I’d be happy to prepare a PR if the concept fits the project’s scope.

🧭 Background

Borg’s --append-only mode is an excellent protection against ransomware and compromised clients — but it’s all-or-nothing:
once enabled, no archive can be deleted without a manual reset of the repository.

In practice, many admins want a middle ground:

• automatic pruning and housekeeping for older backups,
• while ensuring that the most recent N archives are physically immutable.

This would prevent accidental or malicious prune operations from wiping recent data,
without disabling regular maintenance entirely.

---

💡 Proposal

Introduce an additional repository option or server flag, for example:

borg serve --protect-last=N
# or within authorized_keys:
command="borg serve --restrict-to-path /data/repo --protect-last=3",restrict ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQ...

Behavior:

• The most recent N archives are marked as undeletable within the repo manifest.
• prune skips these archives, even if retention rules would normally delete them.
• borg delete would require an explicit --force or --ignore-protection flag.

This feature should be enforced server-side, configured in authorized_keys,
so that compromised clients cannot disable or modify it.
It complements the existing --append-only mode by offering partial immutability.

---

🔐 Security model (server-side enforcement)

The --protect-last option is intended to be defined on the repository host,
not in the client configuration. This follows the same design as --append-only,
where security policies are enforced through SSH command restrictions.

Example:

command="borg serve --restrict-to-path /data/repo --protect-last=3",restrict ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQ...

This ensures that the repository host defines protection rules,
and even a ransomware-infected client cannot bypass or alter them.

---

⚙️ Implementation idea

• Extend Manifest metadata with a small immutable list of protected archive IDs.
• prune and delete commands check against this list before any deletion.
• Configuration originates from the server (authorized_keys or repo config).
• Unit tests verify that protected archives survive prune/delete operations.

---

✅ Benefits

• Protects the last N archives even if a client or script is compromised.
• Enables secure automation (no need for manual resets).
• Adds meaningful ransomware protection with minimal complexity.
• Compatible with --append-only for full immutability when needed.

---

🔍 Example use case

borg prune --keep-daily=7 --keep-weekly=4
# Server-side policy: protect-last=3

This keeps the last 3 archives immutable,
while still applying normal retention rules to older ones.

---

🧱 Compatibility

• No new dependencies.
• Backward compatible; ignored by older clients.
• Non-disruptive to existing append-only and lockfile semantics.
• Simple to deploy through SSH authorized_keys configuration.

---

💬 Contributor note

I'm prepared to implement this feature as a pull request (including tests and documentation)
if the maintainers agree in principle that it fits the project scope.

The goal is to make this a small, self-contained, security-oriented improvement,
not a major change in repository behavior.

[ThomasWaldmann]

I don't think it is a good point in time to implement this. Also, I guess it would not be a small change.

We currently have 1.4.x out as stable release and the feature is too big and risky to implement as a patch release. Also, it could not be ported to borg2.

The next release after that shall be borg 2.0, which works completely differently already at the repository level (no log-like appending and no transactions) and at least one more big change is currently considered (pack files), so it also does not fit in there either as long as all is in flux.

If you like, have a look at borg2 and think about how it could be implemented. But be prepared that the way the repo works might change again for packs.

[tkn777]

Thanks for the clarification, Thomas - that makes perfect sense.

My initial thought was that this kind of server-side protection would conceptually belong in borg 2 rather than 1.x,
but I understand that the repository layer is still evolving and it’s not the right time to add new logic there.

I’ll keep an eye on the ongoing structural work and revisit the idea once things have settled.