Steps to reproduce
- Configure scheduled NS8 application backups with a Backblaze B2 destination.
- Configure a retention policy (
forget --prune --keep-last=7).
- Run the scheduled backup.
- The issue is intermittent and cannot currently be reproduced on demand.
During a scheduled run, the following sanitized sequence was recorded:
2026-07-16T00:05:16+02:00 Remove(<lock/c4fc23a454>) failed:
<lock/c4fc23a454> does not exist
2026-07-16T00:05:22+02:00 Load(<lock/c4fc23a454>, 0, 0)
returned error: unexpected HTTP response (500): 500 Internal Server Error
2026-07-16T00:05:25+02:00 retention policy failed:
restic forget --prune --keep-last=7 returned exit status 11
2026-07-16T00:05:30+02:00 Load(<key/afd159cbff>, 0, 0)
returned error: unexpected HTTP response (500): 500 Internal Server Error
The error affected different application repositories in the same time window, so it was not specific to Traefik application data.
Expected behavior
A transient backend error should not leave the repository permanently unusable. A later scheduled run should either safely remove a stale lock when no Restic process is active, or report a clear recovery action.
Repository access failures should not cause the agent to attempt restic init on an already initialized repository.
Actual behavior
The lock created during the failed operation remained in the B2 repository. Retention failed on every subsequent run with exit code 11:
repository is already locked by PID 1 on ns1 by root
lock was created at 2026-07-15 22:05:08
The same lock was still reported about 216 hours later and again about 240 hours later. Eventually scheduled backups failed until a manual restic unlock was performed.
A later run also tried to initialize the repository after access failed because of the lock, producing the misleading secondary error:
Fatal: create repository failed: config file already exists
Before unlocking, no Restic or backup process was running. After the manual unlock:
restic check succeeded on the affected repositories;- snapshots were readable;
- a complete scheduled backup finished successfully.
Components
- NS8 single-node installation
- Backup destination: Backblaze B2
- Image at first occurrence:
ghcr.io/nethserver/restic:3.20.0
- Current image:
ghcr.io/nethserver/restic:3.21.1
- Affected repositories included Traefik and Loki
- The simultaneous WebTop key-load failure indicates a shared destination/gateway failure rather than an application-specific issue
No credentials, bucket names, customer identifiers or repository UUIDs are included in this report.
See also
Reported from a customer installation; all logs have been sanitized.
Steps to reproduce
forget --prune --keep-last=7).During a scheduled run, the following sanitized sequence was recorded:
The error affected different application repositories in the same time window, so it was not specific to Traefik application data.
Expected behavior
A transient backend error should not leave the repository permanently unusable. A later scheduled run should either safely remove a stale lock when no Restic process is active, or report a clear recovery action.
Repository access failures should not cause the agent to attempt
restic initon an already initialized repository.Actual behavior
The lock created during the failed operation remained in the B2 repository. Retention failed on every subsequent run with exit code 11:
The same lock was still reported about 216 hours later and again about 240 hours later. Eventually scheduled backups failed until a manual
restic unlockwas performed.A later run also tried to initialize the repository after access failed because of the lock, producing the misleading secondary error:
Before unlocking, no Restic or backup process was running. After the manual unlock:
restic checksucceeded on the affected repositories;Components
ghcr.io/nethserver/restic:3.20.0ghcr.io/nethserver/restic:3.21.1No credentials, bucket names, customer identifiers or repository UUIDs are included in this report.
See also
Reported from a customer installation; all logs have been sanitized.