Backupmanager Laravel Package

Getting Started

Before writing any code, check the package's composer.json constraints against your app. This is a Laravel 5.0–5.4-era package (no package auto-discovery, pinned to Backpack CRUD v2/v3), so it is only a realistic option for a legacy codebase. On anything Laravel 5.5+ you will fight dependency resolution, and on Laravel 6+ it will not install at all.

Minimal install:

composer require dick/backupmanager

Then, because there is no auto-discovery:

1. Register Dick\BackupManager\BackupManagerServiceProvider::class (and the Backpack CRUD provider, if it isn't already) in config/app.php.
2. Publish the config and views: php artisan vendor:publish --provider="Dick\BackupManager\BackupManagerServiceProvider".
3. Make sure the backup destination directory exists and is writable by the web user — by default the underlying backup-manager/backup-manager package writes to storage/app/backups (older releases: app/storage/backups).
4. Add the entry point to the Backpack sidebar menu (in resources/views/vendor/backpack/base/inc/sidebar.blade.php or your menu file):

<li><a href="{{ url('admin/backup') }}"><i class="fa fa-hdd-o"></i> <span>Backups</span></a></li>

Where to look first: the published config file is the whole surface area. It defines the source (MySQL/Postgres dump, or filesystem paths) and the destination filesystems (local, S3, FTP, Dropbox, GCS). Nothing else in the package does much — the admin screen is a thin CRUD wrapper over that config.

First use case: log in to /admin/backup, click Create backup, confirm a new row appears, click Download and verify the dump opens. That single loop — create, verify, download — is 90% of what the package is for.

Implementation Patterns

Nightly backups go in the scheduler, not the UI. The admin button is for humans; production backups belong in app/Console/Kernel.php calling the underlying manager directly:

$schedule->command('backup:run')->dailyAt('02:00');

The UI then becomes a read-only history + manual escape hatch, which is the right division of labour.

Pre-deploy safety net. The most valuable day-to-day pattern: a button or artisan command that runs a backup immediately before migrations. Wire it into your deploy script so a bad migration always has a rollback file on disk:

php artisan backup:run --type=db && php artisan migrate --force

Multi-destination. Configure local and S3 in the same config so the fast-download copy is local and the durable copy is off-box. Don't rely on the UI to prove remote uploads worked — check the S3 bucket directly on day one, since a misconfigured disk fails silently or only in the log.

Restore drills. The package backs up; it does not restore. Document the manual restore path (mysql < dump.sql) and rehearse it quarterly. A backup that has never been restored is a hypothesis, not a backup.

Override the views, don't fork the package. Publish the views and add your own columns/buttons (e.g. a "size" or "created by" column) by copying the CRUD controller into app/Http/Controllers/Admin/ and pointing the route at your copy. This survives a dependency bump and keeps the vendor tree clean.

Pair with a policy. Restrict the backup route to a superadmin middleware or gate. By default it is protected only by Backpack's admin middleware, which in most installations means every staff account can download a full database dump.

Gotchas and Tips

• The package is abandoned (zero dependents, no recent activity). Treat it as vendored code you own. If you're on Laravel 5.4+ and have a choice, use spatie/laravel-backup plus a 40-line custom Backpack CRUD page — you get the same screen, maintained, with notifications and cleanup built in.
• The dick/ vendor name is a genuine namespace, not a typo. Search your composer.json for it when auditing licences.
• Storage path drift. Laravel 5.0 used app/storage/; 5.1+ moved to storage/app/. The default config often points at the old path, so backups "succeed" into a directory nobody looks at. Verify with ls -la storage/app/backups after the first run.
• proc_open / exec must be enabled and the mysqldump binary must be on the PHP user's PATH. Shared hosting frequently disables both; the error surfaces as a generic "backup failed" with no detail — check storage/logs/laravel.log for the Symfony Process exception.
• MySQL 8 vs. old mysqldump: add --column-statistics=0 if your client is newer than the server, and --no-tablespaces if the DB user lacks PROCESS. Both are dump-flag gotchas, not package bugs, but they present as broken backups.
• PHP upload limits. Restoring via the UI is an upload: upload_max_filesize and post_max_size must exceed the dump size. For anything over ~50 MB, skip the UI and restore from the CLI.
• No timeouts on large databases. A multi-GB dump will hit max_execution_time in the web request. Schedule large backups from the CLI only.
• Config caching bites. After editing the config, run php artisan config:clear — the published file is merged at boot and a stale cache will make your disk changes appear to do nothing.
• Verify the dump is non-empty. A failed dump can still produce a 0-byte or header-only file. Add a size assertion to your monitoring rather than trusting the green success row in the UI.
• Extension points are narrow: the config, the published views, and the CRUD controller. If you need anything else (retention policies, encryption, per-tenant backups), you're really extending backup-manager/backup-manager, and at that point you're better off replacing the whole stack.