- Does backup-manager/laravel work with Laravel 9, 10, or 11?
- No. The package was last released in February 2016 and targets the Laravel 4/5 era, before package auto-discovery, Symfony 4+, Flysystem 2/3, and AWS SDK v3. Its illuminate/* and transitive dependency constraints will conflict with a modern composer.json, so it cannot be installed on Laravel 9, 10, or 11 without forking. Treat it as a reference implementation for legacy apps only.
- Is backup-manager/laravel still maintained?
- No. The last release was 2016-02-22, and the package has essentially no dependents, which is a meaningful adoption-risk signal. There are no security patches, no PHP 8 support, and no updates for deprecated storage APIs such as Dropbox v1 or older S3 signing. For anything in the backup path, unmaintained code is a high-risk category because failures tend to be silent until restore time.
- What Laravel and PHP versions does backup-manager/laravel support?
- It is built for the classic Laravel 4.x and 5.x package pattern and PHP 5.6/7.0-era runtimes. Even on later 5.x versions there is no auto-discovery, so you must manually register the service provider and alias the facade. Expect tight pins on older Symfony, Guzzle, and AWS SDK components.
- How do I install backup-manager/laravel in a Laravel app?
- Install it with Composer in a legacy-compatible project, then publish the package config file. Add the service provider to your config/app.php providers array and register the facade alias manually, since the package predates Laravel 5.5 auto-discovery. Verify the installed dependency versions resolve cleanly before touching production, because conflicts with modern Illuminate packages are likely.
- How do I schedule backups with backup-manager/laravel?
- The package exposes Artisan commands that wrap its backup procedures, so you schedule them through the Laravel scheduler in app/Console/Kernel.php. Define your procedures and retention in the published config, then add the command to your schedule at the cadence your RPO requires. Always confirm the scheduler is actually running and that each run produces a verifiable archive.
- Which storage locations can backup-manager/laravel upload backups to?
- It supports pluggable storage adapters including local disk, Amazon S3, Dropbox, FTP, and SFTP. However, several of those integrations predate current provider APIs and authentication schemes, so Dropbox and S3 are the most likely to have drifted or stopped working. Validate credentials and uploads end to end rather than assuming the adapter still authenticates.
- How do I back up multiple database connections with backup-manager/laravel?
- The package is configuration-driven, letting you define separate backup procedures per database connection alongside file and directory backups. Each procedure specifies its source, destination, and compression settings in the published config file. Test each connection individually, since a silent failure on one connection is easy to miss when several run in the same schedule.
- Does backup-manager/laravel delete old backups automatically?
- Yes, it supports automatic cleanup of old copies as part of the Artisan-driven workflow, typically configured through retention settings per procedure. Because the package is unmaintained, verify the cleanup logic against your actual storage adapter before relying on it. A misconfigured retention rule can either fill your bucket or delete copies you still need, so confirm behavior in a non-production environment.
- What is the best alternative to backup-manager/laravel for modern Laravel?
- For current stacks, spatie/laravel-backup is the maintained choice, with active support for Laravel 9/10/11, PHP 8.1+, Flysystem 3, health checks, and notifications. For database-only needs, orchestrating mysqldump or pg_dump directly, or using managed database snapshots, is often lower risk than any PHP package. Choose platform-native snapshots when your database is a managed service with built-in automated backups.
- How should I test restores before trusting backup-manager/laravel in production?
- Inventory your databases, volumes, and retention requirements first, then prototype the package in a non-production legacy-compatible environment. Validate a full restore into an isolated database, run it in parallel with existing backups for at least one retention cycle, and only decommission the old path after a successful restore drill. Document who owns backup verification and incident response, because an untested backup is not a backup.