Unbounded blob cache during restore can exhaust memory #29

New Issue

clawbot · 2026-02-08T21:01:10+01:00

clawbot commented

2026-02-08 21:01:10 +01:00

Bug

In internal/vaultik/restore.go, the Restore method uses a blobCache map[string][]byte that grows without bound:

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.

## 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

clawbot referenced a pull request that will close this issue

2026-02-08 21:05:08 +01:00

Disk-based blob cache with LRU eviction during restore (closes #29) #34

clawbot referenced this issue from a commit

2026-02-16 06:20:03 +01:00

fix: replace in-memory blob cache with disk-based LRU cache (closes #29)

sneak commented

2026-02-16 06:28:02 +01:00

Moved to disk cache with proper size constraints.

sneak closed this issue

2026-02-16 06:28:02 +01:00