2021-01-29 00:20:46 +05:30
---
2021-03-08 18:12:59 +05:30
stage: Enablement
group: Distribution
2021-02-22 17:27:13 +05:30
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
2021-01-29 00:20:46 +05:30
---
2021-04-29 21:17:54 +05:30
# Restoring from backup after a failed upgrade **(FREE SELF)**
2016-06-02 11:05:42 +05:30
Upgrades are usually smooth and restoring from backup is a rare occurrence.
However, it's important to know how to recover when problems do arise.
## Roll back to an earlier version and restore a backup
In some cases after a failed upgrade, the fastest solution is to roll back to
2021-04-29 21:17:54 +05:30
the previous version you were using. We recommend this path because the failed
upgrade will likely have made database changes that can not be readily reverted.
2016-06-02 11:05:42 +05:30
First, roll back the code or package. For source installations this involves
checking out the older version (branch or tag). For Omnibus installations this
2020-07-28 23:09:34 +05:30
means installing the older
[`.deb` or `.rpm` package ](https://packages.gitlab.com/gitlab ). Then, restore from a
backup.
2016-06-02 11:05:42 +05:30
Follow the instructions in the
2020-05-24 23:13:21 +05:30
[Backup and Restore ](../raketasks/backup_restore.md#restore-gitlab )
2016-06-02 11:05:42 +05:30
documentation.
## Potential problems on the next upgrade
When a rollback is necessary it can produce problems on subsequent upgrade
attempts. This is because some tables may have been added during the failed
upgrade. If these tables are still present after you restore from the
older backup it can lead to migration failures on future upgrades.
Starting in GitLab 8.6 we drop all tables prior to importing the backup to
prevent this problem. If you've restored a backup to a version prior to 8.6 you
may need to manually correct the problem next time you upgrade.
Example error:
2020-04-08 14:13:33 +05:30
```plaintext
2016-06-02 11:05:42 +05:30
== 20151103134857 CreateLfsObjects: migrating =================================
-- create_table(:lfs_objects)
rake aborted!
StandardError: An error has occurred, this and all later migrations canceled:
PG::DuplicateTable: ERROR: relation "lfs_objects" already exists
```
Copy the version from the error. In this case the version number is
`20151103134857` .
>**WARNING:** Use the following steps only if you are certain this is what you
need to do.
### GitLab 8.6+
2020-04-22 19:07:51 +05:30
Pass the version to a database Rake task to manually mark the migration as
2016-06-02 11:05:42 +05:30
complete.
2020-04-08 14:13:33 +05:30
```shell
2016-06-02 11:05:42 +05:30
# Source install
sudo -u git -H bundle exec rake gitlab:db:mark_migration_complete[20151103134857] RAILS_ENV=production
# Omnibus install
sudo gitlab-rake gitlab:db:mark_migration_complete[20151103134857]
```
2020-04-22 19:07:51 +05:30
Once the migration is successfully marked, run the Rake `db:migrate` task again.
2021-02-22 17:27:13 +05:30
You might need to repeat this process several times until all failed
2016-06-02 11:05:42 +05:30
migrations are marked complete.
### GitLab < 8.6
2020-04-08 14:13:33 +05:30
```shell
2016-06-02 11:05:42 +05:30
# Source install
2020-04-08 14:13:33 +05:30
sudo -u git -H bundle exec rails console -e production
2016-06-02 11:05:42 +05:30
# Omnibus install
sudo gitlab-rails console
```
At the Rails console, type the following commands:
2020-04-08 14:13:33 +05:30
```ruby
2016-06-02 11:05:42 +05:30
ActiveRecord::Base.connection.execute("INSERT INTO schema_migrations (version) VALUES('20151103134857')")
exit
```
2020-04-22 19:07:51 +05:30
Once the migration is successfully marked, run the Rake `db:migrate` task again.
2021-02-22 17:27:13 +05:30
You might need to repeat this process several times until all failed
2016-06-02 11:05:42 +05:30
migrations are marked complete.
