What problem would this solve?
Hello,
I would like to suggest some improvements to gitea's health check.
Bitrot (files silently corrupting on disk due to hardware faults) is something that can happen on any system, and I have even observed it on large, name brand cloud providers in past. Gitea provides some assistance via health checks, but this system could be further improved to help keep repos safe.
What do you propose?
1) Warning e-mail
An administrator needs to be alerted promptly of a bitrot situation so repos can be restored from backup. As far as I can tell (but I could be wrong, please correct me if so), check.go only reports to an error log. Without surfacing this more visibly, it is likely an administrator would miss this. In a worst case scenario, backups might rotate and the good copy of the repo might be lost before an administrator becomes aware of the problem.
Sending an e-mail notification on failed fsck would help alert an administrator to take action urgently and restore from backup.
2) git lfs fsck
Looking at check.go, it does not appear to check lfs objects for consistency by running git lfs fsck LFS objects should be checked for consistency and alerted on errors.
3) Healthchecks integration
Healthchecks is a popular self-hostable tool that allows administrators to be pinged when a script either fails or is not run. This second case is particularly useful in case there is corruption so bad that the entire gitea instance is affected to the point where warning e-mails would not trigger (or perhaps cron gets disabled accidentally).
What problem would this solve?
Hello,
I would like to suggest some improvements to gitea's health check.
Bitrot (files silently corrupting on disk due to hardware faults) is something that can happen on any system, and I have even observed it on large, name brand cloud providers in past. Gitea provides some assistance via health checks, but this system could be further improved to help keep repos safe.
What do you propose?
1) Warning e-mail
An administrator needs to be alerted promptly of a bitrot situation so repos can be restored from backup. As far as I can tell (but I could be wrong, please correct me if so), check.go only reports to an error log. Without surfacing this more visibly, it is likely an administrator would miss this. In a worst case scenario, backups might rotate and the good copy of the repo might be lost before an administrator becomes aware of the problem.
Sending an e-mail notification on failed fsck would help alert an administrator to take action urgently and restore from backup.
2) git lfs fsck
Looking at check.go, it does not appear to check lfs objects for consistency by running git lfs fsck LFS objects should be checked for consistency and alerted on errors.
3) Healthchecks integration
Healthchecks is a popular self-hostable tool that allows administrators to be pinged when a script either fails or is not run. This second case is particularly useful in case there is corruption so bad that the entire gitea instance is affected to the point where warning e-mails would not trigger (or perhaps cron gets disabled accidentally).