Laravel Backup Manager Laravel Package

Technical Evaluation

Architecture fit: Strong fit for Laravel applications already using scheduler, queues, and multi-disk storage. The release closes a serious multi-profile retention flaw and centralizes cleanup logic in CleanupManager, aligning CLI, queue, dashboard, and MCP paths around one policy application point. This improves consistency for teams operating multiple backup profiles on shared disks.

Integration feasibility: Mostly straightforward for standard installs. The queueable backup:clean command, CleanBackupsJob, and queue.restore_timeout are additive and opt-in. Existing retention calls remain compatible because the new ?string $profile parameter is optional and null preserves prior behavior. Existing stored backups without profile tags still count toward the asking profile, reducing upgrade disruption.

Technical risk: The main breaking risk is for custom SnapshotDriver implementations, which must update applyRetention() signatures to accept the new optional $profile parameter. Behavior changes in backup:list, backup:verify, and backup:restore also mean users will no longer see neighboring profiles’ backups from a shared destination; this is correct but should be validated against existing runbooks and dashboards. Queued cleanup introduces queue-worker dependency and timeout considerations.

Key questions: Do we use multiple backup profiles sharing a disk? Do we maintain any custom SnapshotDriver implementations? Are any scripts or dashboards relying on cross-profile listings? Should backup:clean run through the queue by default in production? What restore timeout is appropriate for our largest datasets? Are we on Laravel 12/Pest 4 or Laravel 13/Pest 5?

Integration Approach

Stack fit: Fits Laravel’s native scheduler, queue, and command patterns. The new BACKUP_QUEUE=true behavior mirrors backup:run, and --sync provides an explicit escape hatch. The new CleanupManager reduces duplicated retention logic across interfaces.

Migration path: Upgrade in staging first. Audit all backup profiles and shared destinations. Update custom SnapshotDriver signatures before deployment. Test backup:list, backup:verify, and backup:restore against shared disks to confirm scoped listings. Validate that legacy untagged backups still clean up as expected. Then enable queued cleanup and tune queue.restore_timeout for restore jobs.

Compatibility: Standard Laravel installs should see minimal friction. Laravel 12 remains on Pest 4; Pest 5 requires PHP 8.4 and Symfony 8 and arrives with Laravel 13. Teams pinning Pest should confirm their environment resolves the intended major. Queue name fallback from empty/null to backups is a safe correction but should be verified against worker configuration.

Sequencing: 1) Review custom drivers and update signatures. 2) Deploy to staging and test multi-profile retention. 3) Verify scoped listings and restore behavior. 4) Configure queue cleanup and restore timeout. 5) Roll out to production with monitoring on failed_jobs and queue depth. 6) Update operational runbooks for profile-scoped listings and queued cleanup.

Operational Impact

Maintenance: Positive. CleanupManager and CleanupReport reduce drift between CLI, queue, dashboard, and MCP cleanup paths. The retention fix removes a silent data-loss class affecting default multi-profile setups. The shared abstraction should make future retention changes easier to reason about.

Support: Support burden may temporarily increase because listings are now profile-scoped and queued cleanup changes where cleanup execution appears. Teams accustomed to seeing all backups on a shared disk may raise questions. Clear documentation on StoredBackup::$profile, belongsTo(), and CleanupReport will help.

Scaling: Queued cleanup is better for large blob pools and avoids running reference-counting work inside the scheduler process on web nodes. This improves memory safety and observability through queue dashboards and failed_jobs. Restore timeout configurability supports large restores that routinely outlast backups.

Failure modes: Queued cleanup depends on workers listening to the configured queue; the new fallback to backups mitigates empty queue names but still requires correct worker setup. Custom drivers that miss the signature change can fail at runtime. Profile-scoped listings may break ad hoc operational scripts. Legacy or unreadable manifests still count toward the asking profile, preserving prior cleanup behavior but potentially masking profile mis-tagging until backups rotate.

Ramp-up: Moderate for standard users, higher for teams with custom drivers or shared-disk multi-profile setups. Most teams can adopt incrementally: upgrade, validate retention and listings, then enable queued cleanup and restore timeout tuning.