2020-07-30 08:09:33 -04:00
---
stage: Create
2021-03-14 23:09:11 -04:00
group: Gitaly
2020-11-26 01:09:20 -05:00
info: "To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments"
2020-07-30 08:09:33 -04:00
type: reference
---
2021-02-19 13:10:51 -05:00
# Repository checks **(FREE)**
2016-04-04 11:23:43 -04:00
2020-04-21 11:21:10 -04:00
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/3232) in GitLab 8.7.
2016-04-04 11:23:43 -04:00
2020-04-21 11:21:10 -04:00
Git has a built-in mechanism, [`git fsck` ](https://git-scm.com/docs/git-fsck ), to verify the
2016-05-30 01:30:16 -04:00
integrity of all data committed to a repository. GitLab administrators
2016-04-12 11:32:58 -04:00
can trigger such a check for a project via the project page under the
2021-02-15 19:09:01 -05:00
Admin Area. The checks run asynchronously so it may take a few minutes
before the check result is visible on the project Admin Area. If the
2021-01-27 19:09:33 -05:00
checks failed you can see their output on in the
[`repocheck.log` file. ](logs.md#repochecklog )
2016-04-04 11:23:43 -04:00
2021-01-27 19:09:33 -05:00
This setting is off by default, because it can cause many false alarms.
2020-03-23 23:09:28 -04:00
2016-04-13 05:15:36 -04:00
## Periodic checks
2016-04-04 11:23:43 -04:00
2018-04-23 10:33:18 -04:00
When enabled, GitLab periodically runs a repository check on all project
2018-05-03 15:14:48 -04:00
repositories and wiki repositories in order to detect data corruption.
2021-01-27 19:09:33 -05:00
A project is checked no more than once per month. If any projects
fail their repository checks all GitLab administrators receive an email
2018-05-03 15:14:48 -04:00
notification of the situation. This notification is sent out once a week,
2018-09-20 05:10:57 -04:00
by default, midnight at the start of Sunday. Repositories with known check
failures can be found at `/admin/projects?last_repository_check_failed=1` .
2016-04-04 11:23:43 -04:00
2016-04-06 06:26:29 -04:00
## Disabling periodic checks
2021-02-15 19:09:01 -05:00
You can disable the periodic checks on the **Settings** page of the Admin Area.
2016-04-04 11:23:43 -04:00
## What to do if a check failed
2016-04-13 06:20:43 -04:00
If the repository check fails for some repository you should look up the error
2020-05-14 20:08:06 -04:00
in the [`repocheck.log` file ](logs.md#repochecklog ) on disk:
2018-04-23 10:33:18 -04:00
2021-01-27 19:09:33 -05:00
- `/var/log/gitlab/gitlab-rails` for Omnibus GitLab installations
2020-05-14 20:08:06 -04:00
- `/home/git/gitlab/log` for installations from source
2018-04-23 10:33:18 -04:00
2021-06-15 14:09:57 -04:00
If the periodic repository check causes false alarms, you can clear all repository check states by:
1. On the top bar, select **Menu >** ** {admin}** **Admin** .
1. On the left sidebar, select **Settings > Repository** (`/admin/application_settings/repository`).
1. Expand the **Repository maintenance** section.
1. Select **Clear all repository checks** .
2021-03-14 23:09:11 -04:00
## Run a check manually
[`git fsck` ](https://git-scm.com/docs/git-fsck ) is a read-only check that you can run
manually against the repository on the [Gitaly server ](gitaly/index.md ).
- For Omnibus GitLab installations, repositories are stored by default in
`/var/opt/gitlab/git-data/repositories` .
- [Identify the subdirectory that contains the repository ](repository_storage_types.md#from-project-name-to-hashed-path )
that you need to check.
To run a check (for example):
```shell
sudo /opt/gitlab/embedded/bin/git -C /var/opt/gitlab/git-data/repositories/@hashed/0b/91/0b91...f9.git fsck
```
You can also run [Rake tasks ](raketasks/check.md#repository-integrity ) for checking Git
repositories, which can be used to run `git fsck` against all repositories and generate
repository checksums, as a way to compare repositories on different servers.
