Site Backup Bundle Laravel Package

Getting Started

• Install with composer require nowo-tech/site-backup-bundle, pinning an exact tag while the package has 0 stars/dependents. Check the tag's composer.json for PHP >=8.2 and Symfony ^7.0 || ^8.0 compatibility before adopting.
• Register the bundle in config/bundles.php if Flex does not do it automatically, then import its routes (the restore UI is route-driven, not just a console tool).
• Look first at: README.md → DependencyInjection/Configuration.php (all config keys and defaults) → the controllers/commands behind the backup and restore UI → the checksum service. Those four files tell you most of what the bundle does.
• Configure config/packages/site_backup.yaml with a backup directory outside var/cache (for example var/backups or an absolute path on a separate volume), the database DSN, and include/exclude globs. Clear the cache after changing it.
• First use case: create a manual backup from the UI or console, confirm the checksum file is produced, then restore that backup into a disposable staging clone. Do not use production as your first restore target.

Implementation Patterns

• Scheduled backups: call the bundle's backup command from cron or Symfony Scheduler. Keep the schedule in your app (not inside the bundle) so it is visible in deployment config.
• Pre-deploy safety net: in CI/CD, run a backup as a deploy step, verify the checksum artifact, and publish it to off-host storage. Treat a failed checksum as a failed deploy.
• Safe restore choreography: put the app into maintenance/read-only mode, verify the checksum, restore into a temporary location, run migrations and cache:clear, swap files atomically, then run a health check before leaving maintenance mode. The bundle's UI is designed not to break the app mid-restore, but your deploy process still needs a maintenance boundary.
• Wrap the bundle service: inject the backup/restore service into your own application service so you can add audit logging, Slack/email notifications, and consistent error handling without touching vendor code.
• Use events/listeners: subscribe to the bundle's pre/post backup and restore events to record who triggered a restore, from where, and which archive was used. This is the cleanest extension point.
• Environment-specific config: exclude var/cache, var/logs, node_modules, and vendor in all environments; include uploads and .env only where policy allows. Keep dev config minimal so test backups are fast.
• Storage strategy: point backups at a dedicated volume or object-store mount and keep them out of the deploy artifact. Add a retention policy (e.g. 7 daily, 4 weekly) as a separate cron job.
• UI integration: override the bundle's Twig templates in templates/bundles/... for branding and to add an extra confirmation step. Never edit vendor/ or generated assets under src/Resources/public/build.
• Monitoring: expose the latest backup timestamp and checksum status to your monitoring. A silent backup failure is worse than no backup at all.

Gotchas and Tips

• The restore UI is a loaded gun. Restrict it with a firewall role, an IP allowlist, or disable the routes in production and restore from CLI only. Add re-authentication before destructive actions.
• Filesystem permissions matter. The PHP/web user needs read/write access to the backup directory and, during restore, write access to the project root. Avoid running restores as root; it leaves files the app cannot later write to.
• Secrets live in backups. Archives may contain .env, APP_SECRET, and database dumps. Encrypt at rest and restrict download endpoints.
• Database consistency: use native dump flags such as --single-transaction for MySQL/MariaDB or pg_dump for PostgreSQL. Naive file copies of a live database produce corrupt backups.
• Disk space and limits: a restore needs roughly twice the archive size. Large sites will hit max_execution_time and memory_limit; run backups and restores from CLI with generous limits.
• Checksums are necessary but not sufficient. Abort the restore on mismatch, and also verify after copying to the restore target. Large archives make checksumming slow; do not skip it to save time.
• Cache after restore: clear var/cache and run cache:warmup after a restore, otherwise stale container/config caches can make the app appear broken.
• Config caching: in production, changed bundle config requires cache:clear; a stale cached container is a common cause of "the setting has no effect".
• Debugging restores: run the console command with -vvv, inspect the bundle's log channel, and reproduce on a copy of the site. The UI hides intermediate steps by design, so logs are your best window.
• Pin versions and read the changelog. With 0 dependents and an early-stage score, the bundle is a reasonable tool but not a battle-tested default. Pin tags, review release notes, and keep a manual fallback restore procedure.
• Extension points: bundle configuration, service decoration, Twig template overrides, and event subscribers. Prefer these over patching vendor files.
• Coming from Laravel? This is a Symfony bundle, not a Laravel package; there is no service provider or config/backup.php equivalent. For Laravel projects use a Laravel-native backup package instead.