Backups, restore and uptime

What gets backed up

A backup includes the project files, a database dump and Docker volumes. After writing the SQL, the panel reads the dump back, checks for the Dump completed footer and verifies that the number of CREATE TABLE statements matches the number of tables in the database. Volumes without an SQL dump are archived after the container is frozen, to reduce the risk of writing incomplete files.

Prepare off-host storage

Set up a second server or NAS and an SSH connection. Transfer uses rsync, and a failed upload triggers an alert. The panel does not manage rotation or free space on the target server. Those tasks remain your responsibility.

Set a schedule

In a single view you schedule backups, shell commands and cron jobs. Match the frequency to how often your data changes. You can run a backup at night and send it off-host right after it finishes.

Restore data deliberately

A restore overwrites the project database and requires confirmation. Keep a backup of the current state before you start; the panel offers to make one. After restoring, check that the application works.

Check that the site responds

The panel sends a GET request every two minutes. Two failed attempts trigger an alert; a further notification tells you when the site is back. A container status of Up does not hide an HTTP 500 error.

The check covers the HTTP response, not the page content. A blank page with status 200 will pass. Checking whether forms or orders work requires separate tests; monitoring is not an SLA for the application.