Maintain storage and integrity

Savorum keeps every version of every recipe and book, so your library grows over time. Check now and then how much space it uses and whether the database is healthy.

Check space and health

Run these against your database. They use the same storage setting as the server, so add SAVORUM_STORAGE_ACCESS=group if your server uses group storage.

savorum storage \
  --database /data/savorum.db \
  --assets /data/assets \
  --backup-directory /backups

savorum check-database --database /data/savorum.db

storage prints a JSON report of the space used, including old versions and the room a backup needs. It never deletes anything. check-database checks the database for damage.

Check photos and files

With Savorum stopped, check that the photos and files on disk match what the database expects:

savorum scrub-assets \
  --database /data/savorum.db \
  --assets /data/assets

It reports missing, extra, or changed files. It doesn’t guess which copy is right or repair anything.

Free up space

There’s no setting that trims old versions. To free space, add storage, or permanently delete recipes you no longer need from the trash. That’s the only way to reclaim space, and it removes the recipe’s history too. Make and check a backup first.

When the disk is full or nearly full:

1. Stop new uploads.
2. Free unrelated space, or stop Savorum and move it to a larger local disk.
3. Run check-database and scrub-assets.

Don’t delete the -wal file or old versions to make room. To remove photos and files nothing uses any more, run savorum gc-assets --database PATH --assets PATH --grace DURATION with a grace period you choose. It checks again before deleting. Never delete files from the assets folder by hand.

Cap growth and memory

On a shared or small server, you can set hard limits:

• --durable-byte-limit BYTES caps how much the library stores, measured as the size of a full backup. Above it, changes that add data fail with 507 storage-capacity-exhausted. Reading, permanent deletion, and cleanup still work. 0, the default, sets no cap.
• --sqlite-memory-limit BYTES caps the memory the database may use. When it runs out, the request fails with 503 operation-memory-exhausted and changes nothing; try again once the server is less busy. 0, the default, uses at most a quarter of the server’s memory.

Upgrade Savorum

1. Make and verify a backup.
2. Install and start the new version. It may update the database when it starts.
3. If the update fails, Savorum undoes it and stops. Fix the reported problem, then start the same or a newer version.

There’s no way to undo a database update. To go back to an older release, stop Savorum and restore a verified backup made before the upgrade, using the older release.

Good to know

• Plan your disk with room to grow. Each edit keeps a full copy of the recipe, and each replaced photo keeps the old one. For example, 10,000 recipes, a quarter of them with a photo replaced once, need about 10 GB for the photos alone at 2 MB a photo.
• Keep the database and assets on a local disk. Never put them on a network drive such as NFS or SMB.
• Never copy the live database file on its own: without its -wal file, the copy can be missing recent changes. Use savorum backup instead.
• The storage report warns when the disk is about 75% full. Uploads and imports stop when less than 512 MiB would be left. If the disk does fill up, the change that hit the limit fails, and nothing already saved is lost.
• checkpoint and rebuild-search are rarely needed. Make and verify a backup before running either.

Next: Troubleshoot an instance.