Skip to content

Safe Updates, Templates and Backups

Back up matching files and data before updating or restoring.

Update the main and asset resources together. Follow the release instructions for database changes, edited configuration and existing recipes.

1. Prepare before stopping service#

Record the current package version and selected framework/inventory providers. Close new customer orders independently, then fulfill or resolve existing obligations. Tell active staff that temporary preparations and device batches are not restored after restart.

Back up the complete configured database at a consistent recovery point, plus matching resource files, edited configuration, translations, inventory item definitions and images. Restaurant uses 0resmon_restaurants and related 0resmon_restaurant_* tables, including migration history, recipes, publications, staff, stock, packages, orders and finance records. A few selected restaurant/recipe tables are not a complete backup. Use your database provider's supported backup method and retain its successful result.

Keep players out of Restaurant features while Restaurant or its inventory system is unavailable. Remove old scripts or commands that open a separate Restaurant stash.

2. Deploy the matching resource files#

Replace the delivered resources through your normal controlled update process. Preserve the original folder names. Compare your edited config against the new file comments rather than overwriting a new config with an old whole-file copy that omits required fields.

Apply inventory definition/image updates to the selected provider when the release requires them. Start dependencies and keys/maps as appropriate, then 0r-restaurant_assets before 0r-restaurant. Check the first startup error before reopening player access.

3. Separate database and template compatibility#

A schema migration1 updates the database. A template upgrade2 updates saved recipe presets. Follow the release instructions for each; completing one does not complete the other.

Back up existing data before an update. Apply SQL by hand only when the release instructions require it. Keep the original error if the database update fails.

For an update error, follow Database Startup. Avoid changing migration records just to clear a warning.

4. Review affected saved recipes#

Resource startup loads supported saved publications; it does not silently apply all new starter defaults. Use the panel's explicit supported upgrade when offered, inspect affected draft copies and placements, then save and publish.

Saved station models also need review when their names change. A restart does not rename models in saved recipes. For Donut, check the preparation bowl, mixer and decoration tray against the matching installed models: 0r_donut_mixing_bowl, 0r_donut_mixer and 0r_donut_tray_empty. Re-select the supported object and check its placement in the recipe editor, then Save draft and Publish. Keep the oven and other working steps unless they also need a change.

If a recipe shows Incompatible, follow its upgrade or remove-and-add-again instructions. Keep healthy recipes. Repair the affected copy rather than deleting the whole kitchen.

Normal profile and sales edits do not upgrade a template. Coffee and Cocktail recipe-book changes need a main-resource restart.

5. Verify before reopening#

Before reopening, check the database connection, panel access and published staff list. Produce an item and transfer it to inventory. If you use orders, test storage, a paid order and its banking or refund result. Test vehicle spawn and return if you use mobile service.

Test these actions in FiveM and record their results. Review any money or item transfer interrupted during the update before trying it again.

Restoring a backup#

Restore a matching backup of the resource files, configuration and database during maintenance. Check money and inventory changes made after the backup; restoring SQL cannot undo those outside transactions. Resolve each affected order or transfer before reopening.

See Business Recovery for uncertainty and Configuration File Map for setting owners.

Verify a restore in a separate test environment#

Use a separate test server and database, with matching framework/inventory data and matching resource/config backups. Keep its providers isolated from live accounts. Confirm restored migrations initialize, the expected restaurant and staff exist, one recipe publishes/produces, stock and orders match the recovery point, and the corresponding money/inventory evidence agrees.

Restoring only Restaurant SQL cannot reverse later framework bank credits or item transfers. Compare those external effects and resolve each affected operation before reopening the real server.

Footnotes

  1. A database update that Restaurant runs during startup. Read the definition. ↩

  2. Updating a saved recipe with the latest preset definition. Read the definition. ↩