If a menu edit removes half your website, ask your provider four things: what can be restored, how recent the backup is, who can restore it, and how long recovery is expected to take. Then ask to see the process demonstrated safely. A backup schedule alone does not tell you whether your restaurant can get back to serving guests online.
For restaurant website backup and restore planning, start with a specific mistake: an employee accidentally deletes a menu page. This is routine recovery after content loss, not a plan for rolling back a new website launch. The useful outcome is a written agreement on what gets recovered and what the restaurant must check afterward.
Identify what needs to come back
List the parts of your site that guests and staff depend on. For many restaurants, that means menu pages, prices, photos, hours, location details, contact information and links to ordering or reservations. Include catering forms, event pages and accessibility information if you use them.
Content is only one piece. Your site may also rely on settings for its domain, page addresses, ordering buttons, reservation links and staff access. A backup of page text may not restore those settings. Ask your provider to identify which items are covered and which live in a separate system.
Start the inventory with the person who edits the site. Ask your manager which pages change most often and which errors would interrupt service. Ask the website provider for a list of stored content and configuration. If ordering or reservations use another provider, ask that provider what it can restore and how the connection is checked.
Keep a current copy of critical business information somewhere your staff can reach independently: published menu items and prices, hours, contact details and the addresses of important service pages. Decide who is allowed to access that copy and keep it current. It is a reference for checking a restored site, not a substitute for a complete backup.
Domain control deserves a separate check. A restored site is less useful if nobody on your team can access the domain account or reach the person who can. The domain ownership guide covers questions to ask about that account.
Ask about retention, restore access and cost
Ask how often backups are made, how long each version is kept and whether you can choose a restore point. A backup from before a bad edit may recover the deleted page, but it may also lack later menu changes. Find out whether the provider can restore one page or asset, or whether recovery replaces the whole site.
Also ask where backups are stored and what happens if the main website service is unavailable. Can the restaurant request a restore without signing in to the affected site? Which staff members are authorized to make that request? Keep those names and the provider's support contact in a place that does not depend on the website being up.
Use this questionnaire when comparing providers or reviewing your current arrangement:
- Which content, images, settings and connections are included? What must we rebuild or reconnect?
- How often are backups created, and how long are versions retained? Can we select a date and time?
- Can you restore a single page without replacing newer changes elsewhere? If not, how do we preserve those changes?
- Who can request and perform a restore? What happens outside support hours?
- Can we inspect a restored copy before it becomes public? How do we return it to the live site?
- What recovery time do you expect, when does the clock start, and what can make it longer?
- What does routine backup cost? Are there separate restore, after-hours or data export charges?
Get answers in writing and distinguish an expected time from a contractual commitment. A provider may need to identify the right version, obtain approval and check connections before a page can be published. Ask whether its estimate includes those steps or only the technical restore.
For a cost comparison, request a quote that separates recurring backup charges from per-restore and after-hours charges. Ask what is included in each. A low monthly charge is not the whole operational cost if an urgent recovery carries a separate fee. If contract terms need interpretation, consult a qualified adviser.
Run a controlled restore test
A demonstration should answer a practical question: can the right content be recovered and checked without creating real guest activity? Agree on the scope with the provider first. Use a nonpublic test copy or another isolated environment, and confirm that ordering, payment, guest notifications and dispatch are disabled or simulated. Never use a real card payment, guest message or courier dispatch to practice.
Hypothetical example: A restaurant updates its dinner menu on Tuesday. On Wednesday, an employee accidentally removes the menu page. The provider proposes restoring a copy saved after Tuesday's update. The owner asks for that page to be recovered into an isolated test environment before any live change.
The manager compares the recovered dishes, prices, photos and hours with the restaurant's current reference copy. The provider explains whether the ordering button and its destination are included in the restore. The team checks the button's destination without placing a real order. It also checks the page on a phone and follows internal links within the test copy.
If the only available copy predates Tuesday's update, the manager records the missing changes and decides who will re-enter them. If the provider can restore only the entire site, the team first identifies newer changes on other pages that could be overwritten. Either result is useful: it reveals work the restaurant must plan for before a real incident.
Record the exercise while it happens. The sample below is illustrative, not a result from an actual test. Its final row matters as much as the restore itself: an isolated simulation can show what to check, but it does not prove a live recovery will take the same time or behave identically.
| Record item | Example entry | Follow-up |
|---|---|---|
| Scenario and restore point | Deleted dinner menu; copy saved after Tuesday's update | Confirm the copy contains the latest approved menu |
| Scope and safety | Menu page in an isolated test copy; transactions and notifications simulated | Confirm no live ordering or dispatch is triggered |
| Checks | Compare dishes, prices, photos and hours; inspect the ordering link and mobile view | Assign the manager to approve content |
| Timing and gaps | Record request, restore and approval times separately | Ask how live support hours and publishing could change the estimate |
After the exercise, save the record with the provider's answers. Note the date, people involved, restore point used, missing items and any corrective work. Repeat the check after a major website change or a change in provider, because the recovery steps may have changed too.
Assign responsibility before an error happens
Turn the answers into a short recovery sheet. Name a primary restaurant contact and a backup, the provider's support channel, the staff member who approves content, and the person who can authorize publication. Include the location of your menu reference copy and the accounts needed to reach the domain and related services.
Write the sequence in plain language: report the error, stop further edits if appropriate, identify the last good version, request the restore, review the recovered copy and approve publication. After publication, check the live menu, hours and key links. Confirm the status of any connected services with their providers before relying on them.
Agree on what staff should do while recovery is underway. For example, they might take phone orders using the current menu reference and tell callers where to find accurate hours. Make sure that temporary instructions do not direct guests to an outdated menu or a broken ordering page.
Set an expectation for both content loss and downtime. If backups occur at a given interval, ask how much work might need to be recreated after a restore. Separately, ask how long each step from the initial request through approval and publication may take. Those are different questions: a recent copy can still take time to publish, and a quick restore can still omit recent edits.
If you are comparing a new restaurant website setup with your current one, include recovery in the buying conversation alongside editing and mobile usability. For a site connected to online ordering, ask specifically who checks the ordering connection after a restore. Do not assume that restoring website pages also restores every separate service.
Next step: Use the questionnaire and test record to review your current setup. Then ask Fleksa about its restaurant website, the recovery arrangements relevant to your setup, and verified US availability.
Frequently asked questions
How often should a restaurant website be backed up?
Choose a schedule based on how much recent work you can afford to recreate. A restaurant changing prices or specials frequently may need more frequent restore points than one with a rarely edited site. Ask how long those versions remain available.
Can a provider restore just one deleted page?
That depends on the provider and backup method. Ask whether a single page and its images can be restored separately, and how newer changes elsewhere are protected if a full-site restore is necessary.
Does restoring the website restore ordering and reservations too?
Not necessarily. Website content, buttons and connected services may be managed separately. Ask each relevant provider what is covered and who will verify the connections before guests use them.
