Restore feature into Nova UI

[scramatte]

Hi,

I would to add support to restore in laravel nova UI
https://github.com/operativeit/spatie-nova-backup-tool

Can you give me an hand with this?
Basically I will need to launch queued job that runs restoration silently

Regards

[stefanzweifel]

Hey there.

The package heavily uses Action-classes, which can be used in whatever context needed.
It should be fairly trivial to build up PendingRestore-object and pass it to a queued job to do the restore in the background.

These actions aren't documented, but you can see how they are used in the Aritsan command here:
https://github.com/stefanzweifel/laravel-backup-restore/blob/main/src/Commands/RestoreCommand.php#L54-L99

I would suggest you clone this repository locally and explore the code and use the Action you need.

---

Edit: I haven't used Laravel Nova in more than 2 years and have no intention to provide a first-party-tool to restore a backup. Feel free to create and publish your own solution.

[scramatte]

Hi, I’ve tried to achieve it using job that dispatch artisan command, but it doesn’t work as restore drop jobs table, any suggestion? I've taken a look to see if I can ignore jobs tables with spatie/laravel-backup but it doesn't look possible with v9 Thank you

[stefanzweifel]

The config file of spatie/laravel-backup explains, how you can exclude tables from your backup.
https://github.com/spatie/laravel-backup/blob/main/config/backup.php#L53-L64

I don't know how you intend to use this package or the underlying code.
I just want to warn you, that running a database restore process in production can be dangerous.

I would never let a user trigger a database restore process from a UI. Especially if this would override the database of the app the process is triggered on. Also keep in mind, that running a restore process can take up a lot of time. (In apps I work with, it takes ~15 minute for a full restore; your queue system would have to support such long running processes)

[scramatte]

I've been able to get it running. You're totally right, and I'm going to think how to improve security and check what you told me about queues.

Moreover excluding "jobs" table is a problem if we want to do a full restore. In this case, if you run backup:restore command directly from shell , it would be interesting to migrate first minimal laravel tables before restore anything. In my case at least "jobs" table.

May you can add an option in the command for this?

Regards

[stefanzweifel]

Moreover excluding "jobs" table is a problem if we want to do a full restore. In this case, if you run backup:restore command directly from shell , it would be interesting to migrate first minimal laravel tables before restore anything. In my case at least "jobs" table.
May you can add an option in the command for this?

I don't see me ever adding this to this project. There is no "fixed" set of Laravel tables; or we can't really hard code them. I myself work in a legacy database where Laravel was introduced later. We already had a jobs-table for example and had to adjust the config of the app to make the Laravel jobs work.

We also can't exclude tables from the restore or change the restore-priority. spatie/laravel-backup creates a single dump file for the respective database driver. And we use the respective database binaries to import the files.

---

Restoring the database in a production environment for the same database connection the app is currently using, is also something I can't see me ever doing in the future.

For your app/approach/problem, I would probably create a separate database connection in config/database.php and reference that connection in the PendingRestore. And then somehow switch the entire app to that new connection.