Backups and monitoring

Use customer-visible backups, statuses, and logs to protect data and understand an app or service failure before you act.

Create and download backups

Open Backups to see the latest customer-accessible runs. Select Trigger backup, choose a service when asked, and select Trigger.

Database dumps are supported for PostgreSQL, MySQL, MariaDB, and MongoDB. Redis, Valkey, Meilisearch, ClickHouse, OpenSearch, and Kafka are not dumpable through this screen.

Wait for a run to show success and a file size. Select Download and store the file in a protected place. A pending or failed row is not a usable recovery point.

Backup schedules

Under Backup schedules, select Edit. Choose manual, daily, or weekly, set retention days, and keep the schedule enabled. Review later runs to confirm the schedule is producing successful files.

Retention removes old recovery points.Choose a period that covers your release and data-change risk. Download any file you must keep outside that window.

Restore a backup

Restore overwrites current data.Restore is shown in the interface, but customer accounts cannot run it. Contact DeployGrove support with the project, service, and backup time. Do not send the backup file or any secret until support gives you a secure path.

Before requesting a restore, stop writes if your app allows it, record the current incident time, and choose the newest known-good successful backup. A restore does not roll application code back.

Health and logs

Application releases

Open Projects, select the project, and review the current status and deployment output. The first failed phase usually gives the best cause.

Service output

Open Services and select Logs beside the service. Read the first error before using Stop, Start, or a restart action.

What to record

Keep the project or service name, time, commit, visible state, failed phase, and sanitized error lines. Never include credentials, tokens, connection strings, or recovery codes.

What success looks like

You have a usable recovery point.The latest scheduled or manual backup reports success, has a downloadable file, and the current app and services report healthy running states.

Troubleshooting

A backup stays pending

Refresh after a short wait. If no finish time appears, record the service and start time, then contact support.

A backup fails

Read the row’s error. Confirm the service is running and is one of the four supported database types. Trigger a new backup only after the cause is fixed.

An app is stopped or unhealthy

Inspect deployment output before rebuilding. For a service, inspect Logs before starting it again. Repeated failures need a support request with sanitized evidence.