Laravel Backup Manager Laravel Package

Product Decisions This Supports

• Build vs. buy for backup/restore infrastructure. This package now covers scheduling, destination management, retention/cleanup, queue-backed execution, and UI-responder hooks. That is a credible "buy" answer for a Laravel product that needs customer-grade backup behavior without owning cron plumbing, disk abstraction, and job orchestration in-house.
• Whether to ship per-tenant / per-disk backup scoping. v3.0.0 makes cleanups and backups targetable to specific filesystem configurations (disks on runners, destination_ids on cleanup schedules, PerformBackupService::dispatchBackupJob() for scoped backups). This unlocks plan-tiered and tenant-isolated retention policies — a real roadmap item, not just a refactor.
• Reliability and observability commitments. Configurable queue options per job type (connection, queue, group, delay, middleware, after-commit) plus several fixes for silently skipped schedules move backups from "best effort" to "auditable." v3.1.1 closes another silent-skip hole: comma-separated scheduler environment lists were being mis-parsed (implode() instead of explode()), so multi-environment configurations could fail to match and skip schedules entirely. If support tickets about missing backups are a recurring cost, this release line directly addresses that class of bug.
• Whether multi-environment scheduling is a supported product capability. Teams running the same app across production/staging/QA can now express "run backups in these environments" as a real list, with whitespace trimmed and empty entries ignored. That reduces config sprawl (separate config files per environment) and the class of deploy-time mistakes where backups quietly stop running after an environment rename.
• Whether to invest in product UI for backup configuration. Destination selection on cleanup schedules now requires deliberate frontend work (picker built from configurations, submitting destination_ids, pre-selecting selectedDestinationIds). That's a scoping decision: ship self-serve backup config to admins, or keep it operator-only behind config files.
• Upgrade timing against the roadmap. v3.0.0 is a major with a required migration (cleanup_schedule_filesystem_configuration), a breaking responder signature change, a service move, and a config re-publish. v3.1.1 is a drop-in patch on top of it. If backup work is already on the near-term roadmap, upgrade now and land on v3.1.1; if not, schedule it rather than absorbing it opportunistically.
• Operational posture for queue infrastructure. Cleanups are now dispatched as jobs instead of the backup:clean command, so a queue worker is required unless the default connection is sync. That is a platform-level dependency decision, not a package detail.
• Data-integrity / abuse-surface decisions. The 255-entry bound on destination_ids and the SelectableDestinationId rule cap lookup fan-out and enforce that destinations are active (or already attached). Useful when arguing that form endpoints are hardened.

When to Consider This Package

Adopt when:

• You run Laravel and need scheduled database/file backups with multiple destination types, and you'd otherwise hand-roll cron + Flysystem + retention logic.
• You need disk-scoped retention — customers, tenants, or environments with separate storage, each with its own cleanup policy. v3 is the first version where that is expressible.
• You run the application across multiple named environments and want one declarative schedule config rather than per-environment files or deploy-time overrides.
• You already run queue workers (Horizon, Redis/SQS) and can absorb backup/cleanup jobs onto a dedicated queue with its own middleware and after-commit semantics.
• You have, or are willing to build, an Inertia/React (or equivalent) admin surface — the package exposes view data and validation but expects you to implement the responders and pickers.
• You can plan a maintenance window for a major upgrade: composer constraint bump, migration publish + run, responder signature update, config re-publish, and UI work to expose destination selection. Treat v3.1.1 as the target patch level, not v3.0.0.

Look elsewhere or defer when:

• You cannot guarantee a queue worker. The cleanup path changed from command to job; on a non-sync default connection, schedules will not execute without workers.
• You need zero-downtime, no-touch upgrades. The CleanupSchedulesUiResponder::renderCreateCleanupSchedule() signature change and the BackupSchedulesService::getAvailableDestinations() removal are hard breaks in application code.
• You want a fully managed, batteries-included backup product with no UI work. This package is a strong engine with an integration surface you must own.
• Your team is not on Laravel, or your backup needs are single-destination and trivial — the upgrade cost outweighs the scheduling sophistication.
• You cannot tolerate the current validation semantics: an empty destination_ids array means "fall back to app-configured destinations," while omitting the key on update means "leave untouched." That distinction must be encoded correctly in your UI or you will silently retarget cleanups.

How to Pitch It (Stakeholders)

To executives: This upgrade is the difference between backups that usually run and backups you can prove ran. It fixes schedules that were being skipped silently when queue options were set, stops cleanups from quietly running against every disk when a destination went inactive, and adds disk-scoped retention — which is what lets us sell tiered storage and per-tenant retention instead of one-size-fits-all. The follow-up patch (v3.1.1) fixes a second silent-skip case: multi-environment schedule configuration was being parsed incorrectly, so backups could stop running in an environment with no error and no alert. Cost is engineering time for a major-version migration plus admin UI work, not new licensing or infrastructure beyond queue workers we already run.

To engineering: Target v3.1.1, which is a drop-in patch over v3.0.0 — it corrects scheduler environment parsing to explode() comma-separated names, trims whitespace, and drops empty values, so multi-environment configs actually match. If you have more than one environment name in the scheduler config today, audit it during rollout; the previous behaviour could have been silently running nothing. v3.0.0 remains a well-tested major — PHPStan configuration, runner tests for null/empty/explicit disk cases, and feature tests for the destination assignment flow — but carries real breaking changes: update the CleanupSchedulesUiResponder signature, replace BackupSchedulesService::getAvailableDestinations() with BackupDestinationsService::getAvailableDestinations(), publish the new cleanup_schedule_filesystem_configuration migration, and re-publish the config to pick up jobs.backup / jobs.cleanup. Cleanups now dispatch CleanupJob rather than backup:clean, so confirm queue workers before rollout. On the UI side, pre-select from $data->selectedDestinationIds — do not filter configurations on is_active, since deactivated-but-attached destinations must stay visible or they get silently detached on save.

Bottom line: worth upgrading if backup configuration is on the roadmap within the next cycle; the disk-scoping and silent-skip fixes are substantive, and v3.1.1 removes one more way schedules can fail without anyone noticing. The major-version migration and required admin UI work should be planned, not squeezed in.