How-to guide

Restore a database

Database restores run in place and temporarily place the App in maintenance mode. Writes made after the selected restore point are discarded. How backups and restores work explains recovery points, safety backups, and the single restore slot.

Confirm restore availability

Before starting:

you must be a Team owner or admin;
restore must be enabled for the App;
no database, file, or folder restore can be active;
the selected database backup must show Succeeded, or the selected time must be inside the portal’s restorable window;
the App name must be available for the typed confirmation.

If restore is turned off, contact support. If a just-finished restore is still releasing its operation lock, wait a few minutes and retry instead of submitting repeated restores.

Restore from a database backup

Open the App and select Backups.
Under Database backups, find a recovery point with status Succeeded.
Select Restore.
Review the backup time, maintenance-mode warning, and data-loss boundary.
Enter the typed App name exactly as prompted.
Select Restore database.

The portal returns to the Backups page and shows restore progress.

Restore to a point in time

Open Backups.
Under Point-in-time recovery, select Restore to a point in time.
Choose the restore time and time zone.
Wait for the preview. Confirm that the resolved base backup and requested time are correct. The preview includes its own freshness timestamp.
Continue and review the exact recovery time.
Enter the typed App name and select Restore database.

The selectable range is the actual restorable window shown by the portal, not the retention period of every backup type. Presets outside the current window are disabled.

The preview is advisory. The restore validates the live recovery data again before changing the database. If the base backup or recovery window changed, the restore stops before applying an invalid request.

Follow progress

Only the database is restored. App files and media are unchanged.

Before overwriting the database, synsmarts creates a safety backup of the current database. The App shows its maintenance page while recovery runs. The operation usually takes minutes but can take longer for a large database.

If the status says Needs attention, our team is handling the restore. Keep the App in its current state and don’t submit another restore. The operator wait is bounded. If it expires, the restore fails safely, the App is brought back online, and Restore history reports that the restore was stopped and your site was brought back up.

Verify the restore

When the restore reports success:

Open the App’s live URL.
Verify a record that should exist at the selected restore point.
Verify the primary customer flow.
Review scheduled integrations that may retry work from after the restored time.
Confirm background jobs, webhooks, email, and payment systems won’t recreate or duplicate discarded work.

Undo a restore

The restore history identifies the pre-restore safety backup as the Undo point. Selecting Undo starts another full restore. Undo also replaces current data, including writes made since the first restore.

The Undo action disappears when the safety backup is no longer available.

Recover from a problem

Restore could not be started: no database change began. Retry with a new request after the reported problem is corrected.
Restore failed: review the customer-safe reason in Restore history and contact support if retry guidance isn’t shown.
Needs attention: wait for our team to resolve the active restore. If the decision window expires, the restore stops and the App returns online.
Restore appears stuck: refresh the Backups page. If the status and stage remain unchanged, contact support with the App and restore identifier.

If a restore fails or remains active without progress, contact support with the App and restore identifier.