Scheduling & monitoring

Backups earn their keep when they run on their own and someone is told if one fails. This page covers running backups on a schedule, offloading them to a queue, and monitoring their health.

Scheduling

Enable the built-in schedule to register the commands with the Laravel Scheduler automatically:

1'schedule' => [
2    'enabled' => true,
3    'backup' => '0 2 * * *',    // nightly backup at 02:00
4    'cleanup' => '0 4 * * *',   // retention at 04:00
5    'monitor' => '0 6 * * *',   // health report at 06:00
6],

Set any expression to null to skip registering that command. Make sure your app runs the scheduler:

1* * * * * cd /path-to-your-project && php artisan schedule:run >> /dev/null 2>&1

Prefer to wire it yourself? Leave schedule.enabled = false and add the commands to your app's routes/console.php / scheduler as usual.

Queues

Long-running backups can be pushed to the queue:

1'queue' => [
2    'enabled' => true,
3    'connection' => env('BACKUP_QUEUE_CONNECTION'),
4    'queue' => 'backups',
5    'timeout' => 3600,
6],

When enabled, php artisan backup:run dispatches a RunBackupJob to the queue instead of running inline (make sure a worker is processing the configured queue). Force a synchronous run with --sync:

1php artisan backup:run          # queued when queue.enabled = true
2php artisan backup:run --sync   # always runs immediately

Scheduled backups are registered with withoutOverlapping(), so a slow run never collides with the next one or with retention/monitoring.

Monitoring

Pro feature. backup:monitor, health reports, the backup_history table and the BackupUnhealthy event are part of Backup Manager Pro. The free core backs up, restores and cleans without them.

php artisan backup:monitor reports, per destination:

• whether it is healthy;
• the number of backups and their total size;
• the age of the newest backup.

A destination is unhealthy when it has no backups, or its newest backup is older than:

1'monitoring' => ['max_backup_age_hours' => 25],

The command exits non-zero when any destination is unhealthy, so it doubles as a CI/uptime check.

Events

The package dispatches events you can listen to:

Every lifecycle event is also written to the log by the built-in LogsBackupActivity listener, giving you an audit trail out of the box.

Notifications

Failures can notify you by mail (free core). The Slack channel and the unhealthy trigger are Pro, since they build on monitoring:

1'monitoring' => [
2    'notifications' => [
3        'enabled' => true,
4        'on' => ['failure', 'unhealthy'],   // success | failure | unhealthy
5        'mail' => ['to' => ['ops@acme.test']],
6        'slack' => ['webhook_url' => env('BACKUP_NOTIFY_SLACK')],
7    ],
8],

Notification delivery is best-effort: a failed notification is logged but never breaks a backup or monitor run.