Back up, restore, and inspect a PHP site

The site's Backups tab protects its files and database. The Logs tab shows runtime output used to diagnose failed requests and application startup problems.

Create a manual backup

1. Open Dashboard → Services → your PHP service → PHP Sites.
2. Choose the site and open Backups.
3. Click Create Backup.
4. Add an optional name and confirm.
5. Wait until the backup status is Completed.

Only one active backup job can run at a time, and the plan's manual-backup quota still applies. Do not close or retry the action just because a large site takes time.

Download or rename a backup

Completed backups can be downloaded. Keep the browser tab open while a large authenticated download is being prepared. Manual backups can be renamed; automatic backups cannot. Renaming changes only the display name, not the backup UUID.

Restore a backup

Restoring replaces the site's current files and database with the selected snapshot.

1. Choose a completed backup and click Restore.
2. Enable Create safety restore point unless you intentionally do not want a snapshot of the current state.
3. Optionally name the safety restore point.
4. Click Restore Now.
5. Wait for the service restore status to finish before using file, database, or runtime controls.
6. Test the site and database afterward.

Without a safety restore point, changes made since the selected backup may be unrecoverable. AppLaunch retries a failed restore, but retrying cannot recreate data that was never backed up.

Delete a backup

Delete only after confirming that another usable copy exists. Deletion is permanent. When the node is offline, existing backups may still be downloadable, but create, restore, and delete actions are unavailable.

Read application logs

Open Logs, reproduce the problem once, then refresh or follow the newest entries. Match the timestamp to your test and look for the first application error rather than later secondary errors.

Choose Logs for structured runtime entries containing a timestamp, severity, and message. CRITICAL or ERROR means an operation failed; WARNING or NOTICE describes a condition that may still allow the request to continue; INFO and DEBUG provide normal or detailed diagnostic context. The application or PHP runtime assigns the level, so confirm that the line matches the failing request.

Choose Access for requests. An entry can show the client IP, HTTP method, path, and response status. A text404 points to an unmatched file or route, text401 or text403 points to authentication or permission, text429 means request limiting, and text5xx means the server or PHP application failed. Use the same timestamp and path to find the corresponding runtime error.

Select 50, 100, or 500 recent lines. Live streams new entries; Live (fallback) polls when the live WebSocket is unavailable. Auto-scroll follows new lines until you scroll away.

Common causes include a missing textindex.php, incorrect file paths or permissions, unsupported PHP syntax, missing environment values, and database credentials or privileges that do not match Database → Connection.

Never paste passwords, API keys, session cookies, or full customer records into a support ticket. See PHP troubleshooting for a structured checklist.

For the shared severity and HTTP-status reference, see Understand AppLaunch service logs.