Data Persistence
How ItemsDB keeps ox_inventory's data files in sync with the database and manages backups.
ItemsDB treats the database as the source of truth, but always keeps ox_inventory/data/items.lua and ox_inventory/data/weapons.lua up to date. This is what makes the fallback work - if ItemsDB fails to load, ox_inventory falls back to files that already reflect the latest state of the database.
File Sync
Every write operation (upsert or delete) and every startup triggers a sync back to ox_inventory's data files. The sync runs in a background thread so it never blocks the write that triggered it.
The output is a valid Lua table literal, formatted and sorted the same way ox_inventory's original files are - so the files remain human-readable and diffable.
Backup Rotation
Before each sync, the existing file is backed up inside ItemsDB/backups/ using a 3-version rotation:
| File | Description |
|---|---|
items.lua.1.bak | Most recent backup |
items.lua.2.bak | One backup ago |
items.lua.3.bak | Two backups ago - dropped on the next backup |
The same scheme applies to weapons.lua. On each backup, older backups shift down one slot and the oldest is discarded.
With a retention of 3 backups, you have a window of 3 changes to catch and recover from a bad update before the last known-good backup is rotated out.
Restoring a Backup
If you need to roll back, copy the desired .bak file over the live file in ox_inventory/data/:
cp ItemsDB/backups/items.lua.1.bak [ox]/ox_inventory/data/items.luaThen run ItemsDB:migrate from the server console to re-import the restored file back into the database.
Security
The file writer only accepts writes that originate from ItemsDB itself, and validates that the target path is inside ox_inventory/data/. Writes from any other source are blocked.