# Back up, restore, and inspect a PHP site

> Create and download PHP site backups, restore safely, and use logs to diagnose application errors.

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 `404` points to an unmatched file or route, `401` or `403` points to authentication or permission, `429` means request limiting, and `5xx` 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 `index.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](/php-mysql/troubleshooting/) for a structured checklist.

For the shared severity and HTTP-status reference, see [Understand AppLaunch service logs](/support/understand-logs/).