Using Ledge
DocsScheduled and manual database backups, how long they're kept, and how to restore one.
Ledge can take an encrypted backup of a site's database on a schedule or whenever you ask. The plugin or package makes the dump on your server, encrypts it there and sends it to Ledge, which stores it separately from your hosting.
Backups cover the database only. Uploaded files, code and environment variables aren't included, so keep your asset storage versioned or backed up separately.
LEDGE_ACQUIRE_ENABLED=true and check the requirements for Craft or Laravel: a running queue, a dump tool and enough free disk.The site needs an active health check, because Ledge sends the backup request through the same connection. Backups need ledge-craft 5.2.3 or later on Craft 5, or ledge-laravel 1.0.0 or later.
| Setting | Options | Default |
|---|---|---|
| Frequency | Nightly, Every 12 hours, Every 6 hours | Nightly |
| At (UTC) | Any hour, for nightly backups | 03:00 |
| Keep for | 1 to 3,650 days, or empty to keep them forever | 365 days |
Nightly backups start early in the hour you choose, in UTC. Backups every 6 or 12 hours run that long after the last one, and the first starts within about 15 minutes of saving.
If a scheduled backup fails, Ledge tries again at the next scheduled time, not straight away.
Click Back Up Now on the Backups page, for example before a deploy or a big content change. You can start up to 4 manual backups an hour per site, and only one backup runs at a time.
The dump can add some load to the server for a minute or two on large sites.
| Status | What it means |
|---|---|
| Queued | Ledge is about to send the request to your site. |
| Backing up | The site is dumping, encrypting and sending the database. This includes waiting in the site's queue. |
| Stored | The backup is stored and ready to download. |
| Failed | No backup was stored. The row shows the reason. |
A backup fails if it hasn't arrived within an hour, including time spent waiting in the site's queue. The most common cause is a queue that isn't running. Other reasons include a missing dump tool, not enough free disk space, or a dump larger than the 500 MB default limit. See Recommended site setup for how to keep the database lean.
Deleting a site in Ledge deletes all of its backups.
Click Download on any stored backup. Only the site's owner can download backups. The file arrives decrypted, as a .tar.gz archive named after the site and the time the backup finished:
example-site-db-backup-2026-11-09-030412.tar.gzInside is a single dump.sql, a plain SQL dump made with your database's own tool.
To download from a script or an AI assistant, use download-backup through the MCP server. It returns a link that works once and expires after 15 minutes.
Ledge doesn't restore backups for you. You download the dump and import it with the usual tools, so you stay in control of when and where it's restored.
Restoring replaces the data in the target database. Take a fresh backup first, and restore to a staging copy when you can.
php craft db/restore dump.sqlCraft restores the dump into the database the site is configured to use. Run php craft up afterwards if the backup came from an older version of the site.
Clear the application's caches so they don't serve data from before the restore: php craft clear-caches/all for Craft, or php artisan optimize:clear for Laravel.
When a backup fails, Ledge sends a Backup failed alert to the channels in the site's notification policies. Later failures don't send new alerts while that one is open. The next successful backup closes it. See Alerts.