Automatic / periodical backups

[jtagcat]

Allow making backups automatically, saving to a specified local storage directory.

Cleanup may be left to the user or implemented with 'keep last n backups'.

[Mellowor]

Hi, i would like to try implement this feature, could you assign it to me @louislam ? Also this is one of my first contributions do you have some specific advice beyond the contribution file?

[louislam]

Hi, i would like to try implement this feature, could you assign it to me @louislam ? Also this is one of my first contributions do you have some specific advice beyond the contribution file?

Thank you so much!

But I would not recommend to implement this in the current stage, because the backup is done via the frontend in the current implementation, which means that you have to rewrite the backup feature in backend before you start to implement this feature. I don't think it is an easy task.

Also, as most Uptime Kuma users are able to access the machine, using any existing backup tools such as rsync/zip/cron is more reliable and flexible in my opinion.

[b-a0]

If you are using docker you can backup the volume with the data periodically using the offen/docker-volume-backup image. It can take care of writing to remote storage, pruning old back-ups and sending notifications in case of backup failure.

The full compose file would look something like:

version: '3'

services:
  uptime:
    container_name: uptime
    image: louislam/uptime-kuma:1
    volumes:
      - uptime-kuma:/app/data
    environment:
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    labels:
      - docker-volume-backup.stop-during-backup=true
    restart: always

  backup-kuma:
    container_name: backup-kuma
    image: offen/docker-volume-backup:v2.27.0
    restart: always
    env_file: ./.backup.env
    volumes:
      - uptime-kuma:/backup/uptime-kuma_mount:ro
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - /home/user/backups:/archive
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro

With the .backup.env containing:

BACKUP_ARCHIVE="/archive"
BACKUP_CRON_EXPRESSION="0 0 * * 0"
BACKUP_FILENAME="uptime-backup-%Y-%m-%dT%H-%M-%S.tar.gz"
BACKUP_PRUNING_PREFIX="uptime-backup-"
BACKUP_RETENTION_DAYS="31"
NOTIFICATION_URLS=ntfy://ntfy.sh/example_uptime_backup_topic?title=Uptime%20Kuma%20backup

Above example would backup the volume uptime-kuma to the location /home/user/backups on the docker host, every Sunday at midnight. It would keep backups of the past 31 days, after which it will prune older backups. In case of error it sends a notification via ntfy.sh.

_{No affiliation, just a happy user of the volume-backup image.}

[Genc]

This is no longer necessary. Can we close issue? @louislam

[CommanderStorm]

This is no longer necessary. Can we close issue?

Why is this no longer necessary? @Genc

[Genc]

This is no longer necessary. Can we close issue?

Why is this no longer necessary? @Genc

Actually, this feature request is not a problem related to Kuma's responsibility. Taking backups is user-related. Kuma already provides the necessary convenience. Too many features will cause the product to lose its main purpose. @CommanderStorm

[CommanderStorm]

Taking backups is user-related

Having good backup options is an important part of operating any software. We should support good operational practices and offer solid backup functionality.

Kuma already provides the necessary convenience

Disagree. In 1.18.3, we deprecated the current backup feature due to lacking maintaiance. In 2.0 we remove the current approach as the amount of support (read: bad user experice) this broken feature is causing for us was not manageable.

New approaches should use the db directly for taking/ingesting backups and include tests to ensure that this does not suddenly breaks. Our contribution guide can be found here: https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md

Too many features will cause the product to lose its main purpose

Sort of true, but this is not a main source of complexity / effort.

=> leaving this open