Learning Restic - Hardening & Multi-tenant

#Introduction

Episode 14 secured a single repository. But in a company, one backup infrastructure serves many teams: the payments team, the web team, the data team. If they all share one repository and one key, a single security incident in one team can leak everything — or one mistake can wipe out another team's history.

This episode is hardening at team scale: a multi-tenant model that limits the blast radius.

#One Repository per Tenant

The golden rule: never mix data from different tenants in one repository. Reasons:

• Blast radius: a leaked password in tenant A does not open tenant B's data.
• Separate retention: the payments team needs 1 year of history, the web team only 30 days — the forget policy (episode 8) runs independently.
• Performance: one tenant's check and prune does not block another tenant.

On a rest-server, each tenant gets its own path:

/srv/restic/
├── payments/
├── web/
└── data-platform/

Each client points at its own URL:

restic -r rest:https://backup.example.com/payments backup /data
restic -r rest:https://backup.example.com/web backup /data

#One Key per Repo

Aligned with the rule above, every repository has its own repo key (password) — a natural result since every restic init generates a new master key. Never reuse a passphrase across tenants (the policy from episode 13). If one passphrase leaks, only one tenant is affected.

#Credential Isolation

#Per Tenant on rest-server

Create a different htpasswd user for each tenant:

htpasswd -cb /etc/restic/htpasswd payments 'pass-payments'
htpasswd -cb /etc/restic/htpasswd web 'pass-web'

#Per Tenant on S3/MinIO

Set up separate IAM user + policy that only allows access to their own bucket:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
      "Resource": "arn:aws:s3:::backup-web/*"
    }
  ]
}

Each tenant's credentials are stored in its own secret manager, not in one shared place.

#Least Privilege Storage

The principle: grant the most minimal permissions a task needs.

• Backup client: only needs PutObject/GetObject/ListBucket for its bucket. It does not need bucket-management permissions (DeleteBucket, IAM).
• rest-server: run it as a non-root user (User=restic), chown the data directory to that user.
• SFTP: use Match User + ForceCommand (episode 14) so the backup user cannot execute a general shell.

sudo chown -R restic:restic /srv/restic
sudo chmod 700 /srv/restic

#Access Auditing

Hardening is not complete without observation. Set up routine audits:

• Server logs: monitor rest-server/nginx logs for suspicious login patterns.
• CloudTrail / MinIO audit: track DeleteObject operations — who deleted, when.
• Periodic key review: restic key list per repo; remove the keys of team members who left.

restic -r rest:https://backup.example.com/payments key list

#Conclusion

• One repository per tenant limits the blast radius and separates retention.
• One repo key per repo; never reuse passphrases across tenants.
• Credential isolation: htpasswd per tenant, IAM user + policy per bucket.
• Least privilege: clients only need Put/Get/List for their bucket; the server runs non-root.
• Periodic audit: review restic key list, access logs, and the DeleteObject trail.
• Multi-tenant = isolation + observability; don't compromise either.

In the next episode, episode 16, we enter the recovery space: troubleshooting & recovery — debugging with RESTIC_DEBUG and --verbose, common cases like repo lock, S3 timeout, and wrong password, disaster simulation with restore, and recovery from a corrupted repository.