Weave Code
Tomato Backup Module Laravel Package
tomatophp/tomato-backup-module
A backup management module for TomatoPHP that lets you create, schedule, and restore database and file backups from your Laravel admin panel. Integrates with the TomatoPHP ecosystem for quick setup and a simple UI to manage backup jobs.
Tomato Backup Module is a Laravel package from the TomatoPHP ecosystem that adds a ready-made backup manager to your application. It provides a clean interface for creating, storing, and restoring backups of your database and files, helping you safeguard data with minimal setup.
- Scheduled backups for automated, recurring snapshots
- Multiple storage drivers (local, S3, and other Laravel disks)
- One-click restore from the admin panel
- Seamless TomatoPHP and Filament integration
- Simple configuration via published config files
Frequently asked questions about Tomato Backup Module
- How do I install tomatophp/tomato-backup-module in a Laravel application?
- Install it with Composer as tomatophp/tomato-backup-module, then publish the package config and run migrations for the backup and notification tables. The service provider follows the standard TomatoPHP pattern, so the remaining wiring step is registering the plugin in your Filament panel provider. Check the composer.json constraints first, because the module depends on specific Filament and spatie/laravel-backup major versions. Pin an exact version rather than a caret until the changelog gap between 0.x and 1.0.0 is documented.
- Which Laravel, PHP, Filament and spatie/laravel-backup versions does this module support?
- The package does not enumerate these constraints in its README, so read the composer.json of the tagged release you plan to use. The module is built for the Laravel 10/11, PHP 8.1+ and Filament 3 era, and it hard-depends on a specific spatie/laravel-backup major. Because TomatoPHP packages historically trail Filament releases, expect an upcoming Filament major to force an upgrade. Verify all four constraints before merging anything into a production branch.
- Does this package replace spatie/laravel-backup or wrap it?
- It wraps it. The module is a thin orchestration and presentation layer that gives you a Filament UI over the underlying Spatie package, while dumping, restoring, retention and destination drivers stay with Spatie. That is a favorable architecture because the risky parts are not reimplemented. Keep the Spatie config as your source of truth and let the module supply scheduling and the panel screens. If you only need CLI backups, you can skip the module entirely and call the artisan commands directly.
- Where are backups stored by default and can I use S3 or another disk?
- Backup destinations come from the spatie/laravel-backup config, so local disks and remote disks such as S3 are configured there rather than in the module itself. The published config typically points at a local storage path you can change to a throwaway bucket while testing. Because destinations are driver-based in Spatie, you can switch disks without forking the module. Confirm the disk in a non-production environment before you rely on it for real data.
- Can I restore a backup from the Filament panel?
- Yes, restoring and downloading archives are part of the panel workflow the module exposes, alongside creating, listing and deleting backups. Restore is the highest-risk action in any backup tool, so test it deliberately: restore a fresh archive into a scratch database and diff row counts on two or three critical tables. Do that drill before you depend on the button during an incident. Backup correctness is a production-data risk, not a feature checkbox.
- How do I schedule automatic backups with this module?
- Scheduling is driven through configuration on top of spatie/laravel-backup, so define the frequency in the Spatie config and let the module present it in the panel. Backups should run on a queue, which means a running queue worker is mandatory; no worker means silent failures. Large databases can also time out, so test with realistic data volumes. Keep scheduling declarative and version-controlled rather than relying on ad hoc UI clicks.
- Is this module safe to use for production disaster recovery?
- Treat it as a convenience layer, not your only line of defence. It is a single-vendor module with a small contributor base, and backup failures are silent until the day you need a restore, so you must surface disk-full, timeout and missing-queue-worker problems yourself. Verify restores independently of the package and keep an off-package copy of critical data. Teams already using a managed service such as AWS Backup or PlanetScale PITR are usually better off not layering this on top.
- What changed between the last 0.x release and v1.0.0 of this module?
- The release notes only link to a changelog and give no enumerated changes, no migration notes and no breaking-change list. We cannot confirm whether config keys were renamed, table schemas changed or the Filament API was bumped, so treat the upgrade path as unknown rather than risk-free. Pin the exact version in composer.json and test the upgrade in a staging environment before adopting it. Read the package source for the config and migration files if you need certainty.
- Does this module work with Filament v2 or a non-Filament admin panel?
- It is built for Filament 3, and its value is almost entirely the panel UI, so Filament v2 or a custom admin surface loses most of the benefit. In those cases only the scheduling configuration remains useful, and you are effectively adding a dependency cluster around an artisan command. For API-only services or non-Filament dashboards, call spatie/laravel-backup directly instead. Fit is strongest for projects already running tomato-admin, tomato-settings and tomato-roles.
- How can I verify backups actually restore, and does the repo have CI for that?
- There is no evidence in the release materials that the repository's CI exercises a real backup and restore cycle, so assume manual verification is on you. Run a backup to a disposable disk, restore it into a scratch database, and compare row counts on a few critical tables. Also simulate failure modes: fill the disk, kill the queue worker, and use an oversized database to see what the monitor reports. Repeating that drill on a schedule is the only reliable proof the module works.
Weaver
How can I help you explore Laravel packages today?