Backups Laravel Package

Getting Started

• Install the package with Composer, then publish its config and migrations/assets using the package’s documented vendor:publish tags. Check the service provider for publishable tags and command registration if the README is sparse.
• Check the host dependencies before the first run. This package shells out to external binaries for archival and remote transfers, and v0.4.1 specifically ships an rclone compatibility fix for versions older than 1.60. Run rclone version (and any dump binaries your database driver needs) on every machine that will back up or restore, not just your laptop.
• Start in config/backup.php (or the package’s equivalent config file). Confirm the source paths/databases, destination disk, retention policy, and notification settings before running anything.
• Verify the available commands first with php artisan list backup and inspect the restore command with php artisan backup:restore --help; restore arrived in v0.2.0, but the exact flags and confirmation behaviour still matter.
• First practical use case: run a baseline backup with php artisan backup:run, confirm the archive exists on the configured disk, then restore that archive into a local or staging environment using php artisan backup:restore. Treat the first restore as a verification exercise, not a production recovery.

Implementation Patterns

• Schedule regular backups with Laravel’s scheduler, for example Schedule::command('backup:run')->daily() and a separate cleanup/retention command. Keep backup and cleanup schedules visible in version control.
• Use a full restore workflow rather than running backup:restore in isolation: take a fresh backup, enable maintenance mode, restore the selected archive, clear config/cache/view caches, then run smoke tests before disabling maintenance mode.
• Keep environment-specific disks and credentials in .env and config/filesystems.php. Use separate restore credentials from backup-write credentials where possible, especially for S3-compatible storage.
• Pin the rclone binary alongside the PHP version. Since the package delegates remote transfers to rclone, treat its version as part of the runtime contract: standardise on one version across staging and production, and note it in your Docker image or server provisioning so environments do not drift into the compatibility edges that v0.4.1 patches.
• Exercise restores in CI or staging on a schedule. A backup is only proven when a restore succeeds; automate at least a database-only restore smoke test if the command supports selective restores.
• Integrate the command into deployment or recovery runbooks. Use non-interactive flags carefully in scripts, and check exit codes so failed restores fail the pipeline.
• For larger applications, prefer targeted restores (database only or files only) when supported by the command signature, and use the package’s events/notifications to alert on backup and restore failures.

Gotchas and Tips

• backup:restore is destructive. Confirm the command’s prompt/--force behaviour before using it in automation, and add guardrails so it cannot accidentally target production.
• The restore command can only restore archives it can see on the configured disk. Double-check the disk name, path, filename, and credentials; a valid backup on the wrong disk is effectively missing.
• Watch the rclone version. v0.4.1 is explicitly a fix for rclone < 1.60, so environments on old distro-packaged rclone are the ones that historically broke. After upgrading the package, re-run a small backup/restore against each remote disk — a patch release that touches transfer behaviour can regress silently in ways unit tests will not catch.
• Large database dumps can hit PHP max_execution_time, memory limits, or command timeouts. Run restores from CLI with appropriate limits and put the application into maintenance mode first.
• Restoring files can overwrite application storage and introduce ownership/permission problems. Verify file ownership and writable directories after restore.
• Retention/cleanup jobs may delete the exact backup you intended to restore. Pin or copy important archives before running cleanup, and confirm retention settings in non-production environments.
• This is a pre-1.0 package. It has moved from v0.2.0 to v0.4.1 in minor steps, so command signatures and config keys can still shift. Pin the version in composer.json, read the changelog before upgrading, and re-run backup:restore --help after upgrades.
• Log restore output and monitor exit codes. Silent failures in scheduled recovery scripts are worse than backup failures because they are discovered only during an incident.