User Backup Lib Laravel Package

Getting Started

With 0 stars, 0 dependents, and a single maintainer, treat this as a library you read before you trust. Budget 20 minutes to skim the source before wiring it into anything.

composer require fin/user-backup-lib
php artisan vendor:publish --provider="Fin\UserBackupLib\UserBackupServiceProvider"

If the provider isn't auto-discovered (older Laravel or a non-standard namespace), register it manually in bootstrap/providers.php / config/app.php. If there is no service provider at all, the package is framework-agnostic and you'll instantiate classes directly — check composer.json for a laravel key in extra to know which world you're in.

Read in this order:

1. composer.json — PHP version constraint, required extensions (pdo_mysql, pdo_pgsql), and whether it pulls in symfony/process (a strong hint it shells out to mysqldump/pg_dump rather than doing pure-PHP dumps). This single fact changes your deployment story.
2. config/ — the published config is the real API. Connection keys, output paths, retention, and table/column filters live here.
3. src/Contracts/ — the driver/strategy interfaces tell you what's pluggable and what isn't.
4. README.md — likely thin at this maturity level; don't expect a full cookbook.

First use case: a scheduled nightly dump of the users table (plus whichever related tables hold PII) across your primary and reporting databases, written to object storage. Start with one connection and one table before turning on the rest.

Implementation Patterns

Config-driven multi-connection runs. The whole value proposition is iterating several DB connections in one pass. Define each connection in the package config, pointing at Laravel's existing database.connections keys rather than duplicating credentials — single source of truth, and config:cache stays consistent.

// config/user-backup.php (shape will vary — verify against source)
'connections' => [
    'mysql'  => ['driver' => 'mysql',  'tables' => ['users', 'profiles']],
    'pgsql'  => ['driver' => 'pgsql',  'tables' => ['users', 'consents']],
],
'disk' => 's3-backups',
'path' => 'user-backups/{connection}/{date}',

Scheduler over cron. Wrap the package command in routes/console.php and get withoutOverlapping() + onOneServer() for free. Multi-DB backups are long-running; overlapping runs are the fastest way to corrupt your retention logic.

Schedule::command('user-backup:run')
    ->dailyAt('02:30')
    ->withoutOverlapping(120)
    ->onOneServer()
    ->runInBackground();

Queue it for anything non-trivial. If the package ships a job or lets you inject the backup service, dispatch per-connection jobs so one slow database doesn't block the others, and so a failure is retried in isolation. Pair with $backoff and a failed() handler that alerts.

Compose with your existing backup tooling, don't replace it. If you already run spatie/laravel-backup for full-database dumps, use this for the narrower, more frequent, PII-scoped extraction — the artifact you can hand to legal or load into a staging environment without dragging the whole schema along.

Custom drivers for exotic sources. If your "users" live in a legacy MSSQL box or an analytics warehouse, implement the package's driver contract and register it via the container or the config's driver map. This is the extension point that justifies the package over a hand-rolled mysqldump loop.

Verify by restoring. A backup you've never restored is a hypothesis. Add a weekly CI job (or a manual runbook entry) that loads the latest artifact into a throwaway schema and asserts row counts and a column checksum. Cheap insurance against a silently-empty dump.

Testing. Point the config at sqlite in-memory with a couple of fixture tables and assert the artifact exists and is non-empty. If the package doesn't ship fakes, put your own thin wrapper around it so your application tests never call the real thing.

Gotchas and Tips

Zero stars means zero field reports. There's no Stack Overflow corpus for this. Pin an exact version in composer.json ("fin/user-backup-lib": "1.0.3", not ^1.0) and read the diff before every bump. The 2026-08-05 release date is a red flag for metadata quality — confirm what Composer actually resolves against Packagist.

Shell-out vs. pure PHP. If it wraps mysqldump/pg_dump, your container needs those binaries and a matching client version (a MySQL 8 client against a 5.7 server can produce unusable dumps). If it's PDO-based, watch memory: SELECT * on a large users table will OOM a 512MB worker. Check for chunking support or set chunk_size in config.

Config caching bites. config:cache snapshots everything at deploy time. If connection credentials come from a runtime source (Vault, tenant-specific DBs), the package may read a stale value — confirm whether it resolves connections from DatabaseManager at runtime or from the config array. The former works; the latter doesn't.

Timeouts, not just memory. max_execution_time, queue worker --timeout, and retry_after must all exceed your longest dump. A worker killed mid-dump can leave partial files on the disk — sweep for .tmp artifacts, or write to a temp path and rename atomically on success.

Disk quotas and retention. If the package doesn't implement retention, you own it: an S3 lifecycle rule on the backup prefix is more reliable than any PHP cleanup code. Also check that the configured disk isn't local on an ephemeral container filesystem — a surprisingly common way to lose every backup silently.

PII and encryption. These artifacts contain user records in plaintext by default. Encrypt at rest (SSE-KMS, or gpg/openssl in the pipeline), restrict bucket policy, and log who reads them. If you're GDPR-scoped, note why you're copying user data to a second location and document the retention window — an auditor will ask.

Transactions and consistency. Multi-table dumps need --single-transaction (MySQL InnoDB) or a repeatable-read snapshot, otherwise you can capture a user with a profile row that didn't exist a millisecond earlier. Grep the source for transaction handling; if it's absent, that's a correctness bug worth a PR.

Column filtering cuts both ways. Excluding password/remember_token is good hygiene, but a backup missing the columns you need to restore is a trap. Keep a documented, tested restore path that re-joins the excluded fields from the primary DB.

Debugging: start with the package's own logging channel (likely Log::channel('user-backup') or your default stack), run the command with -vvv, and assert the artifact's size and header magic bytes (-- MySQL dump / PGDMP) before assuming success. An empty file with a 200 return code is the classic failure mode.

Contribution leverage. At this adoption level, a well-tested PR for retention, encryption, or a pg_dump driver has an outsized chance of being merged — and gives you a maintainer relationship you'll want if you depend on this in production.