#3604 PR open: BORG: Add opt-in node-specific restore filter and hard-fail mechanism

davi2td opened issue at 2026-05-07 12:07:

If ENABLE_BORG_NODE_FILTER is set to "yes", ReaR will:

  • Filter available BORG restores to only the latest backup for the current node (archive with the highest suffix, by BORGBACKUP_ARCHIVE_PREFIX).
  • Abort restore (with clear error) if no such archive exists, preventing accidental restoration of data from the wrong node in shared repositories, even with AUTO_CONFIRM enabled.

Fully backward compatible—feature is disabled unless user explicitly opts in.

Relax-and-Recover (ReaR) Pull Request Template

Pull Request Details:
  • Type: New Feature / Enhancement
  • Impact: High (for anyone using ReaR+BORG with shared repositories)
  • Reference to related issue (URL): N/A (no existing issue, but addresses a longstanding risk)

How was this pull request tested?

  • Manually tested in shared BORG repo environments with multiple nodes.
  • Verified safe-guard abort when no matching backup is present.
  • Confirmed restore works as before when not enabled.

Description of the changes in this pull request:
This PR introduces an opt-in safety mechanism for ReaR+BORG in multi-node (shared repo) environments:

  • If ENABLE_BORG_NODE_FILTER="yes" (set in local.conf):
    • ReaR only offers and autoselects the latest backup for the current node (by archive name/number) during restore.
    • If NO matching archive is found for the node, the restore process aborts immediately with a clear error, preventing any possible restoration of another node's data.
    • This enables safe, fully-automated AUTO_CONFIRM="yes" restores across all hosts in a shared BORG repository with zero cross-contamination risk.
  • By default, this feature is OFF—users must explicitly enable it.
  • No change to existing flows unless variable is set.

How to enable:
Add to your /etc/rear/local.conf:

ENABLE_BORG_NODE_FILTER="yes"
export ENABLE_BORG_NODE_FILTER

#### <img src="https://avatars.githubusercontent.com/in/56611?v=4" width="50">[codacy-production](https://github.com/apps/codacy-production) commented at [2026-05-07 12:08](https://github.com/rear/rear/pull/3604#issuecomment-4396956064):

## Up to standards :white_check_mark:
<details><summary><strong>🟢 Issues</strong>  <code>0 issues</code></summary>

> <br/>
>
> 
>
> **Results:**
> `0` new issues
>
>
>
> [View in Codacy](https://app.codacy.com/gh/rear/rear/pull-requests/3604/issues)
> <br/>
</details>







<sub>`NEW` Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. [Enable AI reviewer](https://app.codacy.com/organizations/gh/rear/integrations/provider)</sub>
<sub>`TIP` This summary will be updated as you push new changes.</sub>

<!-- a1b2c3d4-e5f6-7890-abcd-ef1234567890 -->

#### <img src="https://avatars.githubusercontent.com/u/888633?u=cdaeb31efcc0048d3619651aa18dd4b76e636b21&v=4" width="50">[gdha](https://github.com/gdha) commented at [2026-05-20 14:07](https://github.com/rear/rear/pull/3604#issuecomment-4499221075):

@davi2td Could you please explain what your reason was to introduce this variable? In short the use case. Doesn't have each node its own borg repository?

#### <img src="https://avatars.githubusercontent.com/u/888633?u=cdaeb31efcc0048d3619651aa18dd4b76e636b21&v=4" width="50">[gdha](https://github.com/gdha) commented at [2026-05-30 07:40](https://github.com/rear/rear/pull/3604#issuecomment-4582126959):

### According AI:

In the context of BorgBackup (Borg), a deduplicating archiver, a repository is a filesystem directory where backup data is stored. 
While Borg is fundamentally designed to assign a unique repository to each machine, a _shared Borg repository_ allows multiple clients or multiple local directories to back up into the same master repository.

_**How it Works & Its Benefits**_

**Cross-Machine Deduplication:** 
When multiple servers back up to a single shared repository, Borg scans and compresses matching file chunks across all clients. This saves massive amounts of disk space if multiple machines store similar operating systems or duplicated files.

**Simplified Management**: 
Administrators only need to maintain, prune, and monitor a single storage location rather than managing dozens of separate repositories.

_**The Drawbacks & Risks**_

**Security & Encryption:** 
Borg assumes that all clients accessing a shared repository ultimately trust each other. Every client that backs up to the repository must use the exact same encryption key/passphrase. This means no client has true privacy from the others, and a compromised client means all backups are vulnerable.

**Locking Conflicts**: 
Borg places an exclusive lock on the repository while backups are running. If two clients attempt to back up at the exact same time, one will be blocked or fail.

**Performance Hit:** 
Borg requires a local cache on the client machine to keep track of stored file chunks. When multiple clients share a repository, this cache frequently becomes out-of-sync, forcing time-consuming cache rebuilds.

**Recommendations**
While technically possible, shared Borg repositories are generally not recommended due to security and concurrency constraints. For large environments with many clients, the standard best practice is to use one dedicated repository per client or dataset.


-------------------------------------------------------------------------------



[Export of Github issue for [rear/rear](https://github.com/rear/rear).]