feat(web): exposed a job to manually trigger database backup procedures

[l0ll098]

Description

This is a small PR that exposes already present database backup machinery in a way that allow users to manually trigger a database backup, without the needing to wait for the automatic cron job to run.

This is particularly handy if your Immich instance does not run at all times (e.g. on a server/NAS) because, for example, you run it on your main computer and you start it "on demand", meaning you start Immich only when you actually need it, and stop it when your done with it.

The resulting .sql.gz file created in the backup folder will count as a database copy.
Hence, if in the system settings page you set that you only want 3 backups, manually clicking this new button four times, will result in four different backups being produced, but only the latest 3 will be kept, just like with database backups produced by the execution of the scheduled cron job to handle database backups.

I'm also attaching a screenshot of the modified Job Status page.

How Has This Been Tested?

Testing manual backups is straightforward, as you just need to click the Start button in the new section in Job Status page.

Testing manual backups and automated one is a bit more convoluted. These are the steps i followed:

• Create a new DB backup by clicking the Start button
• Change the "Amount of previous backups to keep" in System Settings to a smaller number, let's say 3
• Click the button to trigger a manual database backup enough times (four times in our example)
  • We should have only the latest N backups (three in the example)
• Edit the cron job definition to run in a reasonable amount of time and wait for a new (automatic) backup. You should see a new backup appear

Screenshots (if appropriate)

As you can, a new section for a new job is being rendered. When the Start button is clicked, a new database backup will occur.

API Changes

The only notable change is that /api/jobs can now be invoked with a new manual job, that is backup-database.

Checklist:

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation if applicable
• I have no unrelated changes in the PR.
• I have confirmed that any new dependencies are strictly necessary.
• I have written tests for new code (if applicable)
• I have followed naming conventions/patterns in the surrounding code
• All code in src/services uses repositories implementations for database calls, filesystem operations, etc.
• All code in src/repositories/ is pretty basic/simple and does not have any immich specific logic (that belongs in src/services)

[mmomjian]

I’m not sure I love the fact that it kicks out the old backups right away, tbh. It would be better to have some kind of rudimentary keep last X days IMO

[alextran1502]

I don't imagine this job will be used very often. Perhaps we can put it under the list in Create Job button

[jrasm91]

I was thinking the same thing

[danieldietzler]

Also agree with the others in that it'd make more sense in the "create job" modal

[l0ll098]

Hi @danieldietzler, I've moved it to the Create job modal, so now it looks like this:

Do you have any other suggestions?