Each downloaded blob (up to 10GB each per config default) is cached in memory. For large restores with many unique blobs, this can exhaust system memory and crash the process.
Impact
Restoring large backups (hundreds of blobs) will OOM the process
No way to control memory usage during restore
Fix
Implement an LRU cache with a configurable maximum size, evicting the least recently used blobs when the cache exceeds the limit. A reasonable default would be ~1GB or a small number of blobs.
## Bug
In `internal/vaultik/restore.go`, the `Restore` method uses a `blobCache map[string][]byte` that grows without bound:
```go
blobCache := make(map[string][]byte)
for i, file := range files {
if err := v.restoreFile(..., blobCache, result); err != nil {
...
}
}
```
Each downloaded blob (up to 10GB each per config default) is cached in memory. For large restores with many unique blobs, this can exhaust system memory and crash the process.
## Impact
- Restoring large backups (hundreds of blobs) will OOM the process
- No way to control memory usage during restore
## Fix
Implement an LRU cache with a configurable maximum size, evicting the least recently used blobs when the cache exceeds the limit. A reasonable default would be ~1GB or a small number of blobs.
clawbot
self-assigned this 2026-02-08 21:01:10 +01:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Bug
In
internal/vaultik/restore.go, theRestoremethod uses ablobCache map[string][]bytethat grows without bound:Each downloaded blob (up to 10GB each per config default) is cached in memory. For large restores with many unique blobs, this can exhaust system memory and crash the process.
Impact
Fix
Implement an LRU cache with a configurable maximum size, evicting the least recently used blobs when the cache exceeds the limit. A reasonable default would be ~1GB or a small number of blobs.
Moved to disk cache with proper size constraints.