Forgejo production backups getting too large, need to modify pruning system #363
Labels
No labels
Backlog Status
Needs Review
Backlog Status
Ready
Chore
points
01
points
02
points
03
points
05
points
08
points
13
Priority
High
Priority
Low
Priority
Medium
Sprint Status
Blocked
Sprint Status
Done
Sprint Status
In Progress
Sprint Status
Review
Sprint Status
To Do
Technical Debt
Work Item
Bug
Work Item
Epic
Work Item
Spike
Work Item
Task
Work Item
User Story
Backlog Status
Needs Review
Backlog Status
Ready
chore
documentation
points
01
points
02
points
03
points
05
points
08
points
13
Priority
High
Priority
Low
Priority
Medium
Sprint Status
Blocked
Sprint Status
Done
Sprint Status
In Progress
Sprint Status
Review
Sprint Status
To Do
Technical Debt
Work Item
Bug
Work Item
Epic
Work Item
Spike
Work Item
Task
Work Item
User Story
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
forge/forge#363
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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:
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.
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.
Incorporated the os-control01 system into the backups01 management.