Database Backup Laravel Package

Product Decisions This Supports

• Build vs. buy for backup/DR. This is a narrow, single-purpose package: dump a MySQL database, optionally push the artifact to Google Drive, prune old files on a schedule. That is textbook "buy" territory. Nothing here is differentiating, and the failure modes (disk full, no offsite copy, credentials on disk) are exactly the ones you don't want to discover you got wrong during an incident. Adopt, don't build.
• Whether to greenlight the v2.0 upgrade now or gate it. v2.0 requires PHP 8.4+ and Laravel 13. For most teams this makes the upgrade contingent on an unrelated platform migration, not a backup decision. The PM call is sequencing: if you're already on 8.4/13, upgrade immediately for the security fixes; if not, you are knowingly running versions where the database password was world-readable on the host (0644) and could be left on disk after a failed run. That is a security posture item, not a nice-to-have, and it belongs in the risk register with an owner and a date.
• DR/compliance roadmap. Retention being silently broken (cleanup keyed off ctime, so rsync/chmod stopped all pruning) means environments could have been quietly filling disks. If backup retention is part of a stated RPO/RTO or a customer security questionnaire answer, treat prior behavior as unverified and re-baseline the claim after upgrading.
• Trust level for "just a utility" dependencies. The same release fixes cleanup deleting files it did not create, and a use_both_disks feature that never worked with a local primary disk. Both are the class of bug that turns a convenience package into an outage or data-loss event. The offsetting signal is real: 75 tests (from zero), 100% coverage and type coverage, Larastan at max, Rector, Pint, and a CI matrix across PHP 8.4/8.5 and lowest/highest deps. That is a genuine maturity step, and it's the strongest argument that future releases are safer to take.
• Feature adoption for the newly documented config. Email notifications and the storage options existed but were undocumented; storage.google_disk (defaulting to google) is new. Worth a quick pass to confirm notification routing actually reaches someone who will act, since an unmonitored backup failure is indistinguishable from no backup.

When to Consider This Package

Consider it when:

• You run one or a few MySQL databases on Laravel, and you want scheduled dumps plus an offsite copy without operating a backup service.
• You are on, or are about to be on, PHP 8.4+ and Laravel 13 — otherwise you cannot take the security fixes in this release at all.
• You can live with file-level dumps on a schedule. There is no point-in-time recovery here; the recovery point is "last successful run."
• One maintainer's release cadence is an acceptable support model for a component in your recovery path — and you've accepted that the new test suite is the thing buying you confidence, not a vendor SLA.

Look elsewhere when:

• You need PITR, WAL/binlog shipping, or sub-hourly RPOs.
• You need cross-engine coverage (Postgres, Redis, object storage contents) or coordinated multi-service backups — a broader platform or managed service fits better.
• You have audit/compliance requirements that need documented restore drills, encryption-at-rest guarantees, and vendor attestations. Note the package still writes the DB password to a temp file; 0600 and finally-block cleanup reduce the blast radius but do not eliminate the mechanism.
• You're pinned below Laravel 13 and can't move. Staying on v1.x means carrying the readable-password and orphaned-credential issues. If that's the situation, mitigate explicitly (restrict the temp/backup directory permissions, serialize backup runs so concurrent jobs can't collide) and schedule the framework upgrade rather than deferring indefinitely.

How to Pitch It (Stakeholders)

For executives: We get scheduled, offsite database backups for effectively the cost of configuration, instead of building and operating our own. The v2.0 release is significant for two reasons. First, it closes three real security defects in how the database password was handled — previously readable by any user on the host and left behind after failures — plus a retention bug that could have filled a disk and a cleanup bug that deleted files the tool didn't create. Second, the project went from zero tests to full test coverage and strict static analysis in CI, which means future releases are far less likely to break silently. The catch is that the fixes are only available on PHP 8.4 and Laravel 13, so our exposure depends on our upgrade timeline, and that's the one decision I need.

For engineering: This is a correctness release more than a feature release. Two of the fixes mean documented behavior wasn't actually happening: retention dated files from ctime (so it stopped pruning after any rsync/chmod) and cleanup removed everything in the backup directory rather than its own {prefix}_{date}.sql files. Credential handling is now create-empty → 0600 → write, deleted in a finally, with per-run unique filenames so concurrent jobs don't overwrite each other. use_both_disks now works when the primary disk is local, via the new storage.google_disk (defaults to google). Config moved from boot() to register() so defaults are available outside the console. Upgrade checklist: confirm PHP 8.4+/Laravel 13, verify every storage.disk/storage.google_disk pair, and test a restore before you trust the retention numbers.