Forgejo production backups getting too large, need to modify pruning system #363

Closed
opened 2026-01-22 11:50:21 +00:00 by dkirwan · 2 comments
Member

Every night we do a backup. This involves a cronjob running on the os-control or os-control.stg systems which execs inside the forgejo container and runs forgejo dump, which creates a DB dump along with all the repos, then zips it all up. The cron then rsyncs it out of the container to the os-control system.

A second cronjob prunes and manages the backups. It does the following:

  • keep last 7 daily backups
  • every week, take the last daily and make it a weekly, then prune the rest
  • keep the last 4 weekly backups and once a month make it a monthly, then prune the other weekly backups
  • keep the last 12 monthly backups, once a year make the last monthly a yearly backup, prune the other monthly backups
  • keep all the yearly backups indefinitely.

My original idea was to then keep all these in AWS S3, but having an issue with the pruning aspect, as I can't delete from the mounted S3 filesystem.. so I need to revisit that and figure out what to do about it.

These backups in prod are already 25GB and rising as more people use the forge. This might take a while to stabilise but we are already using more space than available on the os-control system. Hoping that the solution will also then also work for the distgit instances coming down the line.

Every night we do a backup. This involves a cronjob running on the os-control or os-control.stg systems which execs inside the forgejo container and runs `forgejo dump`, which creates a DB dump along with all the repos, then zips it all up. The cron then rsyncs it out of the container to the os-control system. A second cronjob prunes and manages the backups. It does the following: - keep last 7 daily backups - every week, take the last daily and make it a weekly, then prune the rest - keep the last 4 weekly backups and once a month make it a monthly, then prune the other weekly backups - keep the last 12 monthly backups, once a year make the last monthly a yearly backup, prune the other monthly backups - keep all the yearly backups indefinitely. My original idea was to then keep all these in AWS S3, but having an issue with the pruning aspect, as I can't delete from the mounted S3 filesystem.. so I need to revisit that and figure out what to do about it. These backups in prod are already 25GB and rising as more people use the forge. This might take a while to stabilise but we are already using more space than available on the os-control system. Hoping that the solution will also then also work for the distgit instances coming down the line.
dkirwan added this to the Backlog project 2026-01-22 11:50:21 +00:00
dkirwan modified the project from Backlog to Sprint 12 2026-01-22 11:51:05 +00:00
dkirwan self-assigned this 2026-01-22 11:51:08 +00:00

Sent an email on this... I think the easy thing to do right now is just add these to our current backups.

So, do what you are doing now for getting them to os-control01, then we just have our backups backup that dir... then we can store a bunch on backup01.

Sent an email on this... I think the easy thing to do right now is just add these to our current backups. So, do what you are doing now for getting them to os-control01, then we just have our backups backup that dir... then we can store a bunch on backup01.
humaton modified the project from Sprint 12 to Sprint 13 2026-01-26 10:14:29 +00:00
Author
Member

Incorporated the os-control01 system into the backups01 management.

  • backups the forgejo backup dump location on the os-control01 system
  • further restricted the number of backups being to now only the last 2 successful backups
  • should prune the rest
Incorporated the os-control01 system into the backups01 management. - backups the forgejo backup dump location on the os-control01 system - further restricted the number of backups being to now only the last 2 successful backups - should prune the rest
Sign in to join this conversation.
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
forge/forge#363
No description provided.