Manage backups

For: owners and admins who create and retain backups. Recovery operators also need trusted shell access.

What backups include

A backup holds the database, private and public media, issued originals and an authenticated file manifest. Keep .env and APP_KEY separately.

Create a manual backup

1. Open Settings > Backups.
2. Enter an optional passphrase.
3. Click Create Backup Now.
4. Wait for the completed file to appear.

Download a backup

Click Download beside the file. Keep an encrypted copy outside the server.

Delete a backup

Click Delete and confirm. This removes the server copy; keep any copy your retention policy requires elsewhere.

Restore from a backup

The browser does not offer in-place restore. Follow Restoring from a backup in a separate directory and empty database.

Do not run the web installer on the destination. Preserve the original application key and verify the restored originals before cutover.

Restore risks

Old snapshots omit newer records. Account for those records before using a disaster snapshot. A failed destination stays in maintenance mode.

Testing restore safely

Use separate storage and a disposable database. Keep mail and scheduled work disabled. Follow the recovery test procedure.

Scheduled backups

Choose Daily or Weekly, set the retention count, then click Save Settings. The default is Disabled; retention defaults to 5.

Retention accepts 1 to 100 backups. Command-line and scheduled creation apply it after success. Browser creation does not remove older files.

CLI commands

php artisan backup:create --encrypted
php artisan backup:clean --keep=5

The first command asks for the encryption passphrase without displaying it. The second removes recognized backups beyond the newest 5.

Encryption

Scheduled backups are unencrypted. Restrict access and encrypt the off-site copy. Save both the archive passphrase and original APP_KEY outside the archive.

Shared-hosting permissions

Ask the host to provide proc_open(), mysqldump, mysql and writable private storage. mariadb-dump and mariadb also work. Recovery requires a separate directory and database.

Worked example

Mira keeps 4 weekly backups for Northwind Studio. A successful fifth scheduled backup removes the oldest recognized server copy.

Before moving hosts, she stops requests and scheduled work, drains running jobs and takes a final sealed backup. The original installation stays stopped.

She restores into an empty replacement, verifies EUR and USD invoice balances and downloads the original PDFs. She switches traffic after verification succeeds.

See Final snapshot and cutover for the complete procedure.