Backup Tables Laravel Package

Getting Started

This release (1.5.4) is a compatibility release at heart: it adds Laravel 13 support and refreshes CI/dependency automation. There are no breaking changes, no deprecations, and no new configuration surface. If you're on 1.5.3 and Laravel ≤12, upgrading is a one-line composer update with no code changes. If you're evaluating the package for the first time, this is the version to start on.

Minimal steps:

1. composer require watheqalshowaiter/backup-tables — package discovery registers the service provider automatically.
2. Publish the config and read it before writing any code: php artisan vendor:publish --provider="WatheqAlshowaiter\BackupTables\BackupTablesServiceProvider" (run php artisan vendor:publish without arguments to list the exact tag available in your version). Everything day-to-day is driven from this file — which tables are included/excluded, where dumps land, and which disk is used.
3. Run php artisan list and find the command in the package's namespace; execute it once against a scratch database with a throwaway table enabled. Confirm the artifact appears on the configured disk before wiring it into anything scheduled.
4. Adjust the table list. The default config is deliberately broad; trimming it to the tables you actually care about is the single highest-leverage change you'll make.

First real use case: taking a snapshot of a handful of tables immediately before a risky migration, backfill, or data-fix deploy. That's where the package earns its keep — it's a targeted, table-level safety net, not a full-database disaster-recovery tool. If your requirement is "restore the whole app to yesterday morning," reach for a proper backup solution instead and use this alongside it.

Implementation Patterns

Pre-deploy snapshot. Chain the backup ahead of the migration in your deploy script or a php artisan wrapper: backup the affected tables, then migrate. Failing the deploy if the backup step fails is the whole point — don't make it best-effort with || true.

Scheduling. Register the command in routes/console.php (Laravel 11+) or app/Console/Kernel.php on older versions. Nightly is the obvious cadence, but the more valuable schedule is event-driven: on deploy, on a data import, before a batch job. Use ->onOneServer() and ->withoutOverlapping() so overlapping runs don't collide on the same output path.

Environment-scoped config. Guard in the published config with env()/app()->environment() so production backs up to durable storage while local dev writes to a scratch directory — or skips entirely. Excluding sessions, cache, jobs, failed_jobs, and any log/audit tables keeps artifacts small and diffs meaningful.

Disk strategy. Point the config at an S3-compatible disk in production and local in development. Because it goes through Laravel's filesystem layer, Storage::fake('backups') in tests gives you assertions on the generated path without touching the real disk — the cleanest way to test that your scheduling and config wiring actually fire.

Driving it programmatically. For jobs and import pipelines, invoke the command via Artisan::call() rather than shelling out, so you inherit the app's config, environment, and error handling. Wrap it in a queued job with an explicit $timeout sized to your largest table, and treat queue-worker memory limits as a first-class concern.

Upgrade hygiene. The 1.5.4 support matrix now includes Laravel 13. That means you can move a Laravel 13 app onto this package, but it also means CI matrices that pin both PHP and Laravel versions are worth adopting for your own app — the release notes show the maintainer doing exactly that.

Gotchas and Tips

• This is not a full-database backup. Table-level dumps mean you own the restore story: order matters when foreign keys are involved, and pivot/morph tables are easy to leave out of the config. Write down the restore procedure once, and actually run it against a scratch database.
• Large tables are the failure mode. A multi-hundred-megabyte table will blow through PHP memory_limit or the queue/command timeout long before you notice anything wrong. Test with a realistic row count, not a 50-row fixture.
• Config caching bites. After editing the published config, php artisan config:clear (or re-run config:cache) — otherwise your table list change appears to do nothing and you'll debug the package instead of the cache.
• Retention is not handled for you. Artifacts accumulate. Add a pruning step (a scheduled Storage cleanup, S3 lifecycle rule, or a dated path convention with a cleanup job) at the same time you set up the backup — not six months later when the bucket bill arrives.
• Backups are a data-export surface. Dumps contain personal data in plaintext. Restrict disk access, encrypt at rest, and be deliberate about which environments and which developers can read the destination.
• Verify, don't assume. A file exists ≠ a valid dump. Periodically check size and open one artifact; silent truncation from a killed process is the classic failure.
• Upgrading to 1.5.4: purely additive — no migration steps, no config key renames, no signature changes. The dependency bumps (fetch-metadata, nick-fields/retry) are CI-only and don't affect your runtime. If your app is on Laravel 13, this is the version that unblocks you; on Laravel ≤12 there is no urgency.
• Extension points live in the config and Laravel's filesystem/console layers: custom disk definitions, a custom table list resolved at runtime, and your own artisan wrapper commands that compose the package command with pre/post logic. Prefer those over forking the package — nothing in 1.5.4 changes them.