(Feature request) Improve backup information and download

[mechanarchy]

Describe feature

The Options tree already has a page for Backups:

I feel this could be greatly improved by adding two things:

• The date/time of the last backup of each type
• A button to download that backup

For me, the automatic backups go into a docker volume; so while I can pull them out, it would be much less effort to have a download button in the web interface. I imagine this may also simplify things for other users.

Here's a simple mock-up of how it could look:

Additional Information

No response

[zadam]

Hi, I added the information, but not download, because of security considerations.

[mechanarchy]

Thanks zadam, can the front-end please display the ctime/mtime of the file as well? Like the mock-up I showed in the first post.

I understand the security considerations so no issue to prevent download from the web UI.

[B-Souty]

Hi, I added the information, but not download, because of security considerations.

Could an option be added to the config file to toggle backup downloads capability? It would of course be disabled by default.

I'm hosting a couple trilium instances in AWS for friends of mine and it would be really helpful if they could take manual backup and download it to their own machine when needed.

Those instances are password protected so I would say the risk is pretty low.

[sottey]

I totally get the need, and understand the frustration, but really this isn't a Trilium thing.... Trilium generates backups of it's own stuff. If you want to make those files available for download by your users, it would be pretty trivial to spin up a docker container that makes them available or a cron job that copies them to a location they can access.

Like I said, I totally get the need, I just don't know if that is in Trilium's domin.

[zadam]

@mechanarchy good point, added

I originally did that for anonymized databases as well where the timestamp is part of the filename, so it didn't occur to me that it's not in the backup file names ...

[mechanarchy]

I figured the backup download feature could probably be done with a Render HTML note and some crafty javascript, and I had a spare hour, so I threw together this page. In the absence of an official implementation you can import this and use it to fetch backups and logs from your Trilium instance:

>>> Backups and Logs.zip <<<

There's extremely rudimentary security on the download endpoint, and the code is garbage, so use at your own risk.

For some reason you can't just click the links (at least it didn't work for me) but right click -> open in new tab works. By default in my code the backups are downloaded and the logs are opened for viewing, but you can play around with the code to suit your own uses.

(FYI @B-Souty)

[B-Souty]

@sottey Sure you can offload the downloading part to another container but it wouldn't be that trivial. It would require extra compute, some sort of shared volume, setup extra routes, etc. And it forces the user to navigate to another location to download their backup. That's still not a great experience for server instances compared to having a link right where the backups are.

I just don't know if that is in Trilium's domin.

Trilium already takes care of making backups which could technically also be offloaded to another container/cron job so simply making a download link available doesn't seem that far out of trilium domain.

I'm not sure I see the security risk if the option can be setup in the config file only, is togglable and default to false. You could also make it impossible to toggle this option if no password is set.

Thank you @mechanarchy I'll take a look at your work :)

[mechanarchy]

@zadam Can we instead please use mtime for the feature in 87a60e3?

The reason being is that I have recently deleted and restored-from-backup my entire Trilium docker volume, and the ctime for each file is now identical (2023-10-11 00:52:14.923601494 +0000, the time of restore) while the mtime is a more accurate representation of the file date (edited for clarity):

/home/node/trilium-data/backup # stat *
  File: backup-daily.db
Modify: 2023-10-18 20:52:15.637721530 +0000
Change: 2023-10-18 20:52:15.637721530 +0000

  File: backup-monthly.db
Modify: 2023-10-05 04:28:58.990524887 +0000
Change: 2023-10-11 00:52:14.923601494 +0000

  File: backup-weekly.db
Modify: 2023-10-18 04:52:15.627370889 +0000
Change: 2023-10-18 04:52:15.627370889 +0000

This is also more clearly seen in my screenshot above where the log timestamps are nonsensical.

[zadam]

Ok, changed to mtime

[mechanarchy]

Thanks, will close this issue as the extra information requested has now been added, and downloading backups is out of scope of the core codebase and can be accomplished with the exported notes I pasted above.