- How do I install the marekmiklusek/database-backup package in Laravel?
- Install it with Composer using composer require marekmiklusek/database-backup, then publish the package configuration with the vendor:publish command so you get a config file you can edit. After that you point the config at a Laravel filesystem disk and run the package's Artisan backup command once to confirm the dump lands where you expect. Because version 2 requires PHP 8.4 or newer, Composer will simply refuse to resolve it on an older platform, so check your runtime first.
- Which PHP and Laravel versions does this database backup package require?
- The current release targets PHP 8.4 and 8.5 and Laravel 13, and it is tested across both PHP versions with lowest and highest dependency sets. That means applications still on Laravel 11 or 12 cannot install this version at all, and the reliability and security fixes in it are unavailable until the framework upgrade lands. If you are pinned to an older Laravel, plan the platform upgrade before adopting the package.
- How do I schedule automatic database backups in Laravel with this package?
- The package exposes an Artisan command, so scheduling is the standard Laravel story: register it in your console kernel or routes/console.php with ->daily(), ->hourly(), or any cron expression you prefer. There is no daemon or queue worker requirement, which keeps the failure domain small and easy to alert on. Just remember that scheduled backups still depend on the mysqldump binary and a writable local disk being present on whichever host runs the scheduler.
- How do I choose where backups are stored, and can I upload to the cloud as well?
- Backups are written through Laravel's filesystem abstraction, so you configure a disk name in the package config and can use local, S3, or any other registered disk driver without code changes. The package also supports an optional secondary upload such as Google Drive plus email notification, so you can push a copy offsite after the local dump completes. Verify the secondary path actually works in your environment, because earlier releases had a bug where use_both_disks did nothing when the primary disk was local, leaving teams with no offsite copy while believing they had one.
- Which databases does this Laravel backup package support?
- It is built around dumping via the database connection configured in Laravel, shelling out to a dump binary rather than reimplementing a dumper in PHP. In practice that means MySQL and MariaDB on hosts with a compatible mysqldump binary are the well-trodden path, and anything else should be validated against your driver before you rely on it. Two infrastructure prerequisites follow from that design: the dump binary must be on every host that runs the command, and the process needs a writable local filesystem with sane permissions.
- How does backup retention and cleanup work in this package?
- Cleanup prunes files that match the package's naming pattern, {prefix}_{date}.sql, once they are older than your configured retention window. That is safer than the earlier behaviour, which could delete unrelated files in the target directory, but it also means renamed, moved, legacy-named, or differently-prefixed artifacts will never be pruned and will accumulate silently. Do a one-time manual sweep of the backup directory and add a size or file-count alert so orphaned dumps cannot quietly fill the disk.
- What changed in version 2 and is the upgrade breaking?
- Version 2 merges its config in register() instead of boot(), which is an improvement because defaults are then available in queued and HTTP contexts, but it should be validated under config:cache. The configName container binding was replaced by a class constant, a minor internal API break if any of your own code resolved it from the container. Retention semantics also changed, cleanup now only removes files matching the package naming pattern, so budget a manual review of existing artifacts rather than assuming the upgrade is purely forward-looking.
- Is this database backup package safe to run in production?
- Architecturally yes: it is config-driven, lives entirely on the console path, and has no request-path coupling, which makes it a failure domain you can isolate, monitor, and replace. The practical risks are operational, namely the mysqldump binary version on each host, the permissions on the local temp and backup directories, and concurrency if two runs overlap. Earlier releases wrote a temporary credentials file with the process umask and deleted it after exec() rather than in a finally block, so if you ran those versions on a shared host or shared volume, sweep temp directories for residue and consider rotating the database password.
- How is this Laravel package tested, and what quality tooling does it use?
- The project went from having no tests to roughly 75 tests with 100% code and type coverage, and it runs PHPStan with Larastan at max level, Rector, and Pint in CI across PHP 8.4 and 8.5 against both lowest and highest dependency sets. That is a real maintainability improvement and lowers third-party risk compared with the previous state. Treat the coverage number as a starting point rather than proof, since it does not guarantee correct handling of shell exit codes, and re-verify the posture on each release.
- How does it compare to spatie/laravel-backup as an alternative?
- Spatie's package is a much broader platform: pure-PHP dumping, health checks, notifications, and multi-destination policies, at the cost of a larger surface area and heavier dependency graph. This package is deliberately minimal, one Artisan command, one config file, dumps written to a Laravel disk, plus optional secondary upload and email notification, which is easier to reason about in an audit. Choose it when you want a small, replaceable backup lane that fits your existing scheduler and monitoring, and choose Spatie when you need the wider feature set out of the box.