Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
G
gitlab-ce
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
Analytics
Analytics
Repository
Value Stream
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Commits
Issue Boards
Open sidebar
Léo-Paul Géneau
gitlab-ce
Commits
8e691021
Commit
8e691021
authored
Feb 15, 2019
by
Nick Thomas
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Document what features are broken when db_key_base is lost
parent
bbd0a2ce
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
23 additions
and
4 deletions
+23
-4
doc/raketasks/backup_restore.md
doc/raketasks/backup_restore.md
+23
-4
No files found.
doc/raketasks/backup_restore.md
View file @
8e691021
...
...
@@ -806,9 +806,22 @@ If you have failed to [back up the secrets file](#storing-configuration-files),
then users with 2FA enabled will not be able to log into GitLab. In that case,
you need to
[
disable 2FA for everyone
](
../security/two_factor_authentication.md#disabling-2fa-for-everyone
)
.
In the case of CI/CD, if your project has secure variables set, you might experience
some weird behavior, like stuck jobs or 500 errors. In that case, you can try
deleting the
`ci_variables`
table from the database.
The secrets file is also responsible for storing the encryption key for several
columns containing sensitive information. If the key is lost, GitLab will be
unable to decrypt those columns. This will break a wide range of functionality,
including (but not restricted to):
*
[
CI/CD variables
](
../ci/variables/README.md
)
*
[
Kubernetes / GCP integration
](
../user/project/clusters/index.md
)
*
[
Custom Pages domains
](
../user/project/pages/getting_started_part_three.md
)
*
[
Project error tracking
](
../user/project/operations/error_tracking.md
)
*
[
Runner authentication
](
../ci/runners/README.md
)
*
[
Project mirroring
](
../workflow/repository_mirroring.md
)
*
[
Web hooks
](
../user/project/integrations/webhooks.md
)
In the case of CI/CD, variables, you might experience some weird behavior, like
stuck jobs or 500 errors. In that case, you can try removing contents of the
`ci_group_variables`
and
`ci_project_variables`
tables from the database.
CAUTION:
**Warning:**
Use the following commands at your own risk, and make sure you've taken a
...
...
@@ -828,9 +841,10 @@ backup beforehand.
sudo -u git -H bundle exec rails dbconsole RAILS_ENV=production
```
1.
Check the
`ci_
variables`
table
:
1.
Check the
`ci_
group_variables`
and
`ci_variables`
tables
:
```sql
SELECT * FROM public."ci_group_variables";
SELECT * FROM public."ci_variables";
```
...
...
@@ -839,6 +853,7 @@ backup beforehand.
1.
Drop the table:
```sql
DELETE FROM ci_group_variables;
DELETE FROM ci_variables;
```
...
...
@@ -848,5 +863,9 @@ backup beforehand.
You should now be able to visit your project, and the jobs will start
running again.
A similar strategy can be employed for the remaining features - by removing the
data that cannot be decrypted, GitLab can be brought back into working order,
and the lost data can be manually replaced.
[
reconfigure GitLab
]:
../administration/restart_gitlab.md#omnibus-gitlab-reconfigure
[
restart GitLab
]:
../administration/restart_gitlab.md#installations-from-source
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment