Back up and restore GitLab · Gitlab 中文文檔

# Back up and restore GitLab > 原文：[https://docs.gitlab.com/ee/raketasks/backup_restore.html](https://docs.gitlab.com/ee/raketasks/backup_restore.html) * [Requirements](#requirements) * [Backup timestamp](#backup-timestamp) * [Back up GitLab](#back-up-gitlab) * [Storing configuration files](#storing-configuration-files) * [Backup options](#backup-options) * [Backup strategy option](#backup-strategy-option) * [Backup filename](#backup-filename) * [Rsyncable](#rsyncable) * [Excluding specific directories from the backup](#excluding-specific-directories-from-the-backup) * [Skipping tar creation](#skipping-tar-creation) * [Uploading backups to a remote (cloud) storage](#uploading-backups-to-a-remote-cloud-storage) * [Using Amazon S3](#using-amazon-s3) * [Digital Ocean Spaces](#digital-ocean-spaces) * [Other S3 Providers](#other-s3-providers) * [Using Google Cloud Storage](#using-google-cloud-storage) * [Specifying a custom directory for backups](#specifying-a-custom-directory-for-backups) * [Uploading to locally mounted shares](#uploading-to-locally-mounted-shares) * [Backup archive permissions](#backup-archive-permissions) * [Configuring cron to make daily backups](#configuring-cron-to-make-daily-backups) * [Limit backup lifetime for local files (prune old backups)](#limit-backup-lifetime-for-local-files-prune-old-backups) * [Restore GitLab](#restore-gitlab) * [Restore prerequisites](#restore-prerequisites) * [Restore for installation from source](#restore-for-installation-from-source) * [Restore for Omnibus GitLab installations](#restore-for-omnibus-gitlab-installations) * [Restore for Docker image and GitLab Helm chart installations](#restore-for-docker-image-and-gitlab-helm-chart-installations) * [Restoring only one or a few project(s) or group(s) from a backup](#restoring-only-one-or-a-few-projects-or-groups-from-a-backup) * [Alternative backup strategies](#alternative-backup-strategies) * [Additional notes](#additional-notes) * [Troubleshooting](#troubleshooting) * [Restoring database backup using Omnibus packages outputs warnings](#restoring-database-backup-using-omnibus-packages-outputs-warnings) * [When the secrets file is lost](#when-the-secrets-file-is-lost) * [Reset CI/CD variables](#reset-cicd-variables) * [Reset Runner registration tokens](#reset-runner-registration-tokens) * [Reset pending pipeline jobs](#reset-pending-pipeline-jobs) * [Container Registry push failures after restoring from a backup](#container-registry-push-failures-after-restoring-from-a-backup) * [Backup fails to complete with Gzip error](#backup-fails-to-complete-with-gzip-error) # Back up and restore GitLab[](#back-up-and-restore-gitlab-core-only "Permalink") GitLab 提供了 Rake 任務來備份和還原 GitLab 實例. 應用程序數據備份將創建一個包含數據庫，所有存儲庫和所有附件的存檔文件. 您只能將備份還原到與其創建時**完全相同的** GitLab **版本和類型（CE / EE）** . 將存儲庫從一臺服務器遷移到另一臺服務器的最佳方法是通過備份還原. ## Requirements[](#requirements "Permalink") 為了能夠進行備份和還原，您需要在系統上安裝兩個基本工具. * **Rsync** ：如果您安裝了 GitLab： * 使用 Omnibus 軟件包，您已經準備就緒. * 從源代碼中，確保已安裝`rsync` . 例如： ``` # Debian/Ubuntu sudo apt-get install rsync # RHEL/CentOS sudo yum install rsync ``` ## Backup timestamp[](#backup-timestamp "Permalink") **注意：**在 GitLab 9.2 中，時間戳格式從`EPOCH_YYYY_MM_DD`更改為`EPOCH_YYYY_MM_DD_GitLab_version` ，例如`1493107454_2018_04_25`將變為`1493107454_2018_04_25_10.6.4-ce` . 備份存檔將保存在`config/gitlab.yml`文件中指定的`backup_path`中. 文件名將為`[TIMESTAMP]_gitlab_backup.tar` ，其中`TIMESTAMP`標識創建每個備份的時間以及 GitLab 版本. 如果您需要還原 GitLab 并且有多個備份可用，則需要時間戳. 例如，如果備份名稱為`1493107454_2018_04_25_10.6.4-ce_gitlab_backup.tar` ，則時間戳為`1493107454_2018_04_25_10.6.4-ce` . ## Back up GitLab[](#back-up-gitlab "Permalink") GitLab 提供了一個簡單的命令行界面來備份整個實例. 它備份您的： * Database * Attachments * Git 存儲庫數據 * CI / CD 作業輸出日志 * CI / CD 作業工件 * LFS 對象 * 容器注冊表圖像 * GitLab 頁面內容 **警告：** GitLab 不會備份任何配置文件，SSL 證書或系統文件. 強烈建議您[閱讀有關存儲配置文件的信息](#storing-configuration-files) . 如果您已通過 Omnibus 軟件包安裝了 GitLab，請使用以下命令： ``` sudo gitlab-backup create ``` **注意**對于 GitLab 12.1 和更早版本，請使用`gitlab-rake gitlab:backup:create` . 如果您已經從源代碼安裝了 GitLab，請使用以下命令： ``` sudo -u git -H bundle exec rake gitlab:backup:create RAILS_ENV=production ``` 如果您正在 Docker 容器中運行 GitLab，則可以從主機運行備份： ``` docker exec -t <container name> gitlab-backup create ``` **注意**對于 GitLab 12.1 和更早版本，請使用`gitlab-rake gitlab:backup:create` . 如果您正在 Kubernetes 集群上使用[GitLab Helm 圖表](https://gitlab.com/gitlab-org/charts/gitlab) ，則可以通過`kubectl`在 GitLab 任務運行`backup-utility`窗格上使用`backup-utility`腳本運行備份任務. 有關更多詳細信息，請參考[備份 GitLab 安裝](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/doc/backup-restore/backup.md#backing-up-a-gitlab-installation) ： ``` kubectl exec -it <gitlab task-runner pod> backup-utility ``` 與 Kubernetes 情況類似，如果已擴展 GitLab 集群以使用多個應用程序服務器，則應選擇一個指定節點（不會自動擴展）以運行備份 Rake 任務. 由于備份 Rake 任務與主 Rails 應用程序緊密相連，因此通常在該節點上您還運行 Unicorn / Puma 和/或 Sidekiq. 輸出示例： ``` Dumping database tables: - Dumping table events... [DONE] - Dumping table issues... [DONE] - Dumping table keys... [DONE] - Dumping table merge_requests... [DONE] - Dumping table milestones... [DONE] - Dumping table namespaces... [DONE] - Dumping table notes... [DONE] - Dumping table projects... [DONE] - Dumping table protected_branches... [DONE] - Dumping table schema_migrations... [DONE] - Dumping table services... [DONE] - Dumping table snippets... [DONE] - Dumping table taggings... [DONE] - Dumping table tags... [DONE] - Dumping table users... [DONE] - Dumping table users_projects... [DONE] - Dumping table web_hooks... [DONE] - Dumping table wikis... [DONE] Dumping repositories: - Dumping repository abcd... [DONE] Creating backup archive: $TIMESTAMP_gitlab_backup.tar [DONE] Deleting tmp directories...[DONE] Deleting old backups... [SKIPPING] ``` ### Storing configuration files[](#storing-configuration-files "Permalink") The [backup Rake task](#back-up-gitlab) GitLab provides does **not** store your configuration files. The primary reason for this is that your database contains encrypted information for two-factor authentication, the CI/CD ‘secure variables’, and so on. Storing encrypted information along with its key in the same place defeats the purpose of using encryption in the first place. **警告：**機密文件對于保留數據庫加密密鑰至關重要. **至少** ，您必須備份：對所有人; * `/etc/gitlab/gitlab-secrets.json` * `/etc/gitlab/gitlab.rb` 從源安裝： * `/home/git/gitlab/config/secrets.yml` * `/home/git/gitlab/config/gitlab.yml` For [Docker installations](https://docs.gitlab.com/omnibus/docker/), you must back up the volume where the configuration files are stored. If you have created the GitLab container according to the documentation, it should be under `/srv/gitlab/config`. 對于 Kubernetes 集群上的[GitLab Helm 圖表安裝](https://gitlab.com/gitlab-org/charts/gitlab) ，必須遵循[備份機密](https://docs.gitlab.com/charts/backup-restore/backup.html)說明. 您可能還想備份所有 TLS 密鑰和證書以及[SSH 主機密鑰](https://superuser.com/questions/532040/copy-ssh-keys-from-one-server-to-another-server/532079#532079) . 如果您使用 Omnibus GitLab，請參閱一些其他信息[來備份您的配置](https://docs.gitlab.com/omnibus/settings/backups.html) . 萬一機密文件丟失，請參閱[故障排除部分](#when-the-secrets-file-is-lost) . ### Backup options[](#backup-options "Permalink") GitLab 提供的用于備份實例的命令行工具可以使用更多選項. #### Backup strategy option[](#backup-strategy-option "Permalink") 在 GitLab 8.17 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/8728) . 默認的備份策略實際上是使用 Linux 命令`tar`和`gzip`將數據從相應的數據位置流式傳輸到備份. 在大多數情況下，這可以正常工作，但是在數據快速變化時可能會引起問題. 當`tar`讀取數據時更改數據時，錯誤`file changed as we read it`可能會`file changed as we read it`發生`file changed as we read it`將導致備份過程失敗. 為了解決這個問題，8.17 引入了一種名為`copy`的新備份策略. 該策略在調用`tar`和`gzip`之前將數據文件復制到一個臨時位置，從而避免了錯誤. 副作用是備份過程將占用額外的 1X 磁盤空間. 該過程盡力在每個階段清理臨時文件，這樣問題就不會復雜化，但是對于大型安裝而言，這可能是一個相當大的變化. 這就是為什么`copy`策略不是 8.17 中的默認策略的原因. 要使用`copy`策略而不是默認的流策略，請在 Rake task 命令中指定`STRATEGY=copy` . 例如： ``` sudo gitlab-backup create STRATEGY=copy ``` **注意**對于 GitLab 12.1 和更早版本，請使用`gitlab-rake gitlab:backup:create` . #### Backup filename[](#backup-filename "Permalink") **警告：**如果使用自定義備份文件名，則將無法[限制備份的壽命](#limit-backup-lifetime-for-local-files-prune-old-backups) . 默認情況下，將根據上面["備份時間戳記"](#backup-timestamp)部分中的規范創建一個備份文件. 但是，可以通過設置`BACKUP`環境變量來覆蓋文件名的`[TIMESTAMP]`部分. 例如： ``` sudo gitlab-backup create BACKUP=dump ``` **注意**對于 GitLab 12.1 和更早版本，請使用`gitlab-rake gitlab:backup:create` . 生成的文件將是`dump_gitlab_backup.tar` . 這對于使用 rsync 和增量備份的系統很有用，并且將導致更快的傳輸速度. #### Rsyncable[](#rsyncable "Permalink") 為了確保生成的歸檔文件可以通過 rsync 智能傳輸，可以設置`GZIP_RSYNCABLE=yes`選項. 這會將`--rsyncable`選項設置為`gzip` . 這僅在與設置["備份文件名"選項](#backup-filename)結合使用時才有用. 注意，不能保證`gzip`中的`--rsyncable`選項在所有發行版中都可用. 要驗證它在您的發行版中是否可用，您可以運行`gzip --help`或查閱手冊頁. ``` sudo gitlab-backup create BACKUP=dump GZIP_RSYNCABLE=yes ``` **注意**對于 GitLab 12.1 和更早版本，請使用`gitlab-rake gitlab:backup:create` . #### Excluding specific directories from the backup[](#excluding-specific-directories-from-the-backup "Permalink") 您可以通過添加環境變量`SKIP`選擇從備份中免除的內容. 可用的選項有： * `db` (database) * `uploads` (attachments) * `repositories` （Git 倉庫數據） * `builds` （CI 作業輸出日志） * `artifacts` （CI 作業工件） * `lfs` （LFS 對象） * `registry` （容器注冊表圖像） * `pages` （頁面內容）使用逗號同時指定多個選項：所有 Wiki 將作為`repositories`組的一部分進行備份. 備份期間將跳過不存在的 Wiki. 對于 Omnibus GitLab 軟件包： ``` sudo gitlab-backup create SKIP=db,uploads ``` **注意**對于 GitLab 12.1 和更早版本，請使用`gitlab-rake gitlab:backup:create` . 對于源安裝： ``` sudo -u git -H bundle exec rake gitlab:backup:create SKIP=db,uploads RAILS_ENV=production ``` #### Skipping tar creation[](#skipping-tar-creation "Permalink") 創建備份的最后一部分是生成包含所有部分的`.tar`文件. 在某些情況下（例如，如果備份是由其他備份軟件獲取的），創建`.tar`文件可能會浪費精力，甚至直接有害，因此可以通過將`tar`添加到`SKIP`環境變量中來跳過此步驟. 將`tar`添加到`SKIP`變量`SKIP`包含備份的文件和目錄保留在用于中間文件的目錄中. 創建新備份時，這些文件將被覆蓋，因此您應確保將它們復制到其他位置，因為系統上只能有一個備份. 對于 Omnibus GitLab 軟件包： ``` sudo gitlab-backup create SKIP=tar ``` 對于源安裝： ``` sudo -u git -H bundle exec rake gitlab:backup:create SKIP=tar RAILS_ENV=production ``` #### Uploading backups to a remote (cloud) storage[](#uploading-backups-to-a-remote-cloud-storage "Permalink") 從 GitLab 7.4 開始，您可以讓備份腳本上載它創建的`.tar`文件. 它使用[Fog 庫](http://fog.io/)執行上傳. 在下面的示例中，我們使用 Amazon S3 進行存儲，但是 Fog 還允許您使用[其他存儲提供商](http://fog.io/storage/) . GitLab 也為 AWS，Google，OpenStack Swift，Rackspace 和 Aliyun [導入了云驅動程序](https://gitlab.com/gitlab-org/gitlab/blob/30f5b9a5b711b46f1065baf755e413ceced5646b/Gemfile#L88) . [也可以使用](#uploading-to-locally-mounted-shares)本地驅動程序. [Read more about using object storage with GitLab](../administration/object_storage.html). ##### Using Amazon S3[](#using-amazon-s3 "Permalink") 對于 Omnibus GitLab 軟件包： 1. 將以下內容添加到`/etc/gitlab/gitlab.rb` ： ``` gitlab_rails['backup_upload_connection'] = { 'provider' => 'AWS', 'region' => 'eu-west-1', 'aws_access_key_id' => 'AKIAKIAKI', 'aws_secret_access_key' => 'secret123' # If using an IAM Profile, don't configure aws_access_key_id & aws_secret_access_key # 'use_iam_profile' => true } gitlab_rails['backup_upload_remote_directory'] = 'my.s3.bucket' ``` 2. [Reconfigure GitLab](../administration/restart_gitlab.html#omnibus-gitlab-reconfigure) for the changes to take effect ##### Digital Ocean Spaces[](#digital-ocean-spaces "Permalink") 該示例可用于阿姆斯特丹（AMS3）中的存儲桶. 1. 將以下內容添加到`/etc/gitlab/gitlab.rb` ： ``` gitlab_rails['backup_upload_connection'] = { 'provider' => 'AWS', 'region' => 'ams3', 'aws_access_key_id' => 'AKIAKIAKI', 'aws_secret_access_key' => 'secret123', 'endpoint' => 'https://ams3.digitaloceanspaces.com' } gitlab_rails['backup_upload_remote_directory'] = 'my.s3.bucket' ``` 2. [重新配置 GitLab](../administration/restart_gitlab.html#omnibus-gitlab-reconfigure)以使更改生效 **注意：**如果通過使用 Digital Ocean Spaces 看到`400 Bad Request` ，則可能是由于使用了備份加密. 由于 Digital Ocean Spaces 不支持加密，因此刪除或注釋包含`gitlab_rails['backup_encryption']`的行. ##### Other S3 Providers[](#other-s3-providers "Permalink") 并非所有 S3 提供程序都與 Fog 庫完全兼容. 例如，如果嘗試上傳后看到`411 Length Required`錯誤， `aws_signature_version` [于此問題](https://github.com/fog/fog-aws/issues/428) ，您可能需要將`aws_signature_version`值從默認值降級為 2. 對于源安裝： 1. Edit `home/git/gitlab/config/gitlab.yml`: ``` backup: # snip upload: # Fog storage connection settings, see http://fog.io/storage/ . connection: provider: AWS region: eu-west-1 aws_access_key_id: AKIAKIAKI aws_secret_access_key: 'secret123' # If using an IAM Profile, leave aws_access_key_id & aws_secret_access_key empty # ie. aws_access_key_id: '' # use_iam_profile: 'true' # The remote 'directory' to store your backups. For S3, this would be the bucket name. remote_directory: 'my.s3.bucket' # Turns on AWS Server-Side Encryption with Amazon S3-Managed Keys for backups, this is optional # encryption: 'AES256' # Turns on AWS Server-Side Encryption with Amazon Customer-Provided Encryption Keys for backups, this is optional # This should be set to the encryption key for Amazon S3 to use to encrypt or decrypt your data. # 'encryption' must also be set in order for this to have any effect. # To avoid storing the key on disk, the key can also be specified via the `GITLAB_BACKUP_ENCRYPTION_KEY` environment variable. # encryption_key: '<key>' # Specifies Amazon S3 storage class to use for backups, this is optional # storage_class: 'STANDARD' ``` 2. [重新啟動 GitLab](../administration/restart_gitlab.html#installations-from-source)以使更改生效如果要將備份上傳到 S3，則可能需要創建具有受限訪問權限的新 IAM 用戶. 要使上載用戶僅能上載備份，請創建以下 IAM 配置文件，將`my.s3.bucket`替換為存儲桶的名稱： ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "Stmt1412062044000", "Effect": "Allow", "Action": [ "s3:AbortMultipartUpload", "s3:GetBucketAcl", "s3:GetBucketLocation", "s3:GetObject", "s3:GetObjectAcl", "s3:ListBucketMultipartUploads", "s3:PutObject", "s3:PutObjectAcl" ], "Resource": [ "arn:aws:s3:::my.s3.bucket/*" ] }, { "Sid": "Stmt1412062097000", "Effect": "Allow", "Action": [ "s3:GetBucketLocation", "s3:ListAllMyBuckets" ], "Resource": [ "*" ] }, { "Sid": "Stmt1412062128000", "Effect": "Allow", "Action": [ "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::my.s3.bucket" ] } ] } ``` ##### Using Google Cloud Storage[](#using-google-cloud-storage "Permalink") 如果要使用 Google Cloud Storage 保存備份，則必須首先從 Google 控制臺創建訪問密鑰： 1. 轉到存儲設置頁面[https://console.cloud.google.com/storage/settings](https://console.cloud.google.com/storage/settings) 2. 選擇"互操作性"并創建訪問密鑰 3. 記下"訪問密鑰"和"秘密"并將其替換為以下配置 4. 在存儲桶高級設置中，確保選擇了訪問控制選項"設置對象級別和存儲桶級別權限" 5. 確保您已經創建了存儲桶對于 Omnibus GitLab 軟件包： 1. Edit `/etc/gitlab/gitlab.rb`: ``` gitlab_rails['backup_upload_connection'] = { 'provider' => 'Google', 'google_storage_access_key_id' => 'Access Key', 'google_storage_secret_access_key' => 'Secret', ## If you have CNAME buckets (foo.example.com), you might run into SSL issues ## when uploading backups ("hostname foo.example.com.storage.googleapis.com ## does not match the server certificate"). In that case, uncomnent the following ## setting. See: https://github.com/fog/fog/issues/2834 #'path_style' => true } gitlab_rails['backup_upload_remote_directory'] = 'my.google.bucket' ``` 2. [重新配置 GitLab](../administration/restart_gitlab.html#omnibus-gitlab-reconfigure)以使更改生效對于源安裝： 1. Edit `home/git/gitlab/config/gitlab.yml`: ``` backup: upload: connection: provider: 'Google' google_storage_access_key_id: 'Access Key' google_storage_secret_access_key: 'Secret' remote_directory: 'my.google.bucket' ``` 2. [重新啟動 GitLab](../administration/restart_gitlab.html#installations-from-source)以使更改生效 ##### Specifying a custom directory for backups[](#specifying-a-custom-directory-for-backups "Permalink") Note: This option only works for remote storage. If you want to group your backups you can pass a `DIRECTORY` environment variable: ``` sudo gitlab-backup create DIRECTORY=daily sudo gitlab-backup create DIRECTORY=weekly ``` **注意**對于 GitLab 12.1 和更早版本，請使用`gitlab-rake gitlab:backup:create` . #### Uploading to locally mounted shares[](#uploading-to-locally-mounted-shares "Permalink") You may also send backups to a mounted share (for example, `NFS`,`CIFS`, or `SMB`) by using the Fog [`Local`](https://github.com/fog/fog-local#usage) storage provider. The directory pointed to by the `local_root` key **must** be owned by the `git` user **安裝時** (mounting with the `uid=` of the `git` user for `CIFS` and `SMB`) or the user that you are executing the backup tasks under (for Omnibus packages, this is the `git` user). 除`local_root`密鑰外， `backup_upload_remote_directory` **必須**設置`local_root` . 這是已安裝目錄中的子目錄，備份將被復制到該子目錄，如果不存在，則會創建備份. 如果要將壓縮文件復制到的目錄是已安裝目錄的根目錄，請使用`.` 代替. **注意：**由于文件系統性能可能會影響 GitLab 的整體性能，因此我們不建議使用 EFS 進行存儲. [有關](../administration/high_availability/nfs.html#avoid-using-awss-elastic-file-system-efs)更多詳細信息，請參見[相關文檔](../administration/high_availability/nfs.html#avoid-using-awss-elastic-file-system-efs) . 對于 Omnibus GitLab 軟件包： 1. Edit `/etc/gitlab/gitlab.rb`: ``` gitlab_rails['backup_upload_connection'] = { :provider => 'Local', :local_root => '/mnt/backups' } # The directory inside the mounted folder to copy backups to # Use '.' to store them in the root directory gitlab_rails['backup_upload_remote_directory'] = 'gitlab_backups' ``` 2. [重新配置 GitLab，](../administration/restart_gitlab.html#omnibus-gitlab-reconfigure)以使更改生效. 對于源安裝： 1. Edit `home/git/gitlab/config/gitlab.yml`: ``` backup: upload: # Fog storage connection settings, see http://fog.io/storage/ . connection: provider: Local local_root: '/mnt/backups' # The directory inside the mounted folder to copy backups to # Use '.' to store them in the root directory remote_directory: 'gitlab_backups' ``` 2. [重新啟動 GitLab，](../administration/restart_gitlab.html#installations-from-source)以使更改生效. #### Backup archive permissions[](#backup-archive-permissions "Permalink") 由 GitLab 創建的備份存檔（ `1393513186_2014_02_27_gitlab_backup.tar` ）默認情況下將具有所有者/組`git` / `git`和 0600 權限. 這是為了避免其他系統用戶讀取 GitLab 的數據. 如果您需要備份存檔具有不同的權限，則可以使用" archive_permissions"設置. 對于 Omnibus GitLab 軟件包： 1. Edit `/etc/gitlab/gitlab.rb`: ``` gitlab_rails['backup_archive_permissions'] = 0644 # Makes the backup archives world-readable ``` 2. [重新配置 GitLab，](../administration/restart_gitlab.html#omnibus-gitlab-reconfigure)以使更改生效. 對于源安裝： 1. Edit `/home/git/gitlab/config/gitlab.yml`: ``` backup: archive_permissions: 0644 # Makes the backup archives world-readable ``` 2. [重新啟動 GitLab，](../administration/restart_gitlab.html#installations-from-source)以使更改生效. #### Configuring cron to make daily backups[](#configuring-cron-to-make-daily-backups "Permalink") **警告：**以下 cron 作業不會[備份您的 GitLab 配置文件](#storing-configuration-files)或[SSH 主機密鑰](https://superuser.com/questions/532040/copy-ssh-keys-from-one-server-to-another-server/532079#532079) . 您可以安排一個 cron 作業來備份您的存儲庫和 GitLab 元數據. 對于 Omnibus GitLab 軟件包： 1. 編輯`root`用戶的 crontab： ``` sudo su - crontab -e ``` 2. 在那里，添加以下行以安排每天凌晨 2 點進行備份： ``` 0 2 * * * /opt/gitlab/bin/gitlab-backup create CRON=1 ``` **注意**對于 GitLab 12.1 和更早版本，請使用`gitlab-rake gitlab:backup:create` . 對于源安裝： 1. 編輯`git`用戶的 crontab： ``` sudo -u git crontab -e ``` 2. 在底部添加以下行： ``` # Create a full backup of the GitLab repositories and SQL database every day at 2am 0 2 * * * cd /home/git/gitlab && PATH=/usr/local/bin:/usr/bin:/bin bundle exec rake gitlab:backup:create RAILS_ENV=production CRON=1 ``` **注意：**如果沒有錯誤， `CRON=1`環境設置將告訴備份腳本禁止所有進度輸出. 建議減少 Cron 垃圾郵件. ### Limit backup lifetime for local files (prune old backups)[](#limit-backup-lifetime-for-local-files-prune-old-backups "Permalink") **警告：**如果您使用[自定義文件名](#backup-filename)進行備份，則此操作將無效.**注意：**此配置選項僅管理本地文件. GitLab 不會自動修剪存儲在第三方[對象](#uploading-backups-to-a-remote-cloud-storage)存儲中的舊文件，因為用戶可能沒有列出和刪除文件的權限. 建議您為對象存儲配置適當的保留策略（例如[AWS S3](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-lifecycle.html) ）. 您可能希望為備份設置有限的生命周期，以防止使用所有磁盤空間進行常規備份. 下次運行備份任務時，將修剪早于`backup_keep_time`備份. 對于 Omnibus GitLab 軟件包： 1. Edit `/etc/gitlab/gitlab.rb`: ``` ## Limit backup lifetime to 7 days - 604800 seconds gitlab_rails['backup_keep_time'] = 604800 ``` 2. [重新配置 GitLab，](../administration/restart_gitlab.html#omnibus-gitlab-reconfigure)以使更改生效. 對于源安裝： 1. Edit `/home/git/gitlab/config/gitlab.yml`: ``` backup: ## Limit backup lifetime to 7 days - 604800 seconds keep_time: 604800 ``` 2. [重新啟動 GitLab，](../administration/restart_gitlab.html#installations-from-source)以使更改生效. ## Restore GitLab[](#restore-gitlab "Permalink") GitLab 提供了一個簡單的命令行界面來還原整個安裝過程，并且足夠靈活，可以滿足您的需求. [還原先決條件部分](#restore-prerequisites)包括關鍵信息. 在嘗試在生產環境中執行還原過程之前，請確保至少閱讀并測試整個還原過程一次. 您只能將備份還原到**與**您在其上創建備份的 GitLab **版本和類型（CE / EE）完全相同的**備份，例如 CE 9.1.0. 如果備份的版本與當前安裝的版本不同，則在還原備份之前，您需要[降級 GitLab 安裝](https://docs.gitlab.com/omnibus/update/README.html) . ### Restore prerequisites[](#restore-prerequisites "Permalink") 您需要先進行有效的 GitLab 安裝，然后才能執行還原. 這主要是因為通常不允許執行還原操作（ `git` ）的系統用戶創建或刪除將數據導入到（ `gitlabhq_production` ）所需的 SQL 數據庫. 所有現有數據將被擦除（SQL）或移動到單獨的目錄（存儲庫，上載）. 要還原備份，您還需要還原`/etc/gitlab/gitlab-secrets.json` （對于 Omnibus 軟件包）或`/home/git/gitlab/.secret` （對于從源安裝）. 該文件包含數據庫加密密鑰， [CI / CD 變量](../ci/variables/README.html#gitlab-cicd-environment-variables)以及用于[兩因素身份驗證的](../user/profile/account/two_factor_authentication.html)變量. 如果您無法通過應用程序數據備份還原此加密密鑰文件，則啟用了雙重身份驗證和 GitLab Runners 的用戶將無法訪問您的 GitLab 服務器. 您可能還想還原所有 TLS 密鑰，證書或[SSH 主機密鑰](https://superuser.com/questions/532040/copy-ssh-keys-from-one-server-to-another-server/532079#532079) . 從 GitLab 12.9 開始，如果找到了未取消備份（如使用`SKIP=tar`備份），并且未使用`BACKUP=<timestamp>`選擇任何備份，則將使用未取消備份. 根據您的情況，您可能需要使用以下一個或多個選項來運行 restore 命令： * `BACKUP=timestamp_of_backup`如果存在多個備份，則為必需. 閱讀有關[備份時間戳記的內容](#backup-timestamp) . * `force=yes` yes-不詢問是否應重新生成 authorized_keys 文件，并假設" yes"以警告將刪除數據庫表，啟用"寫入 authorized_keys 文件"設置并更新 LDAP 提供程序. 如果要還原到作為掛載點的目錄，則在嘗試還原之前，需要確保這些目錄為空. 否則，GitLab 將在恢復新數據之前嘗試移動這些目錄，這將導致錯誤. 閱讀有關[配置 NFS 掛載的](../administration/high_availability/nfs.html)更多信息 ### Restore for installation from source[](#restore-for-installation-from-source "Permalink") ``` # Stop processes that are connected to the database sudo service gitlab stop bundle exec rake gitlab:backup:restore RAILS_ENV=production ``` 輸出示例： ``` Unpacking backup... [DONE] Restoring database tables: -- create_table("events", {:force=>true}) -> 0.2231s [...] - Loading fixture events...[DONE] - Loading fixture issues...[DONE] - Loading fixture keys...[SKIPPING] - Loading fixture merge_requests...[DONE] - Loading fixture milestones...[DONE] - Loading fixture namespaces...[DONE] - Loading fixture notes...[DONE] - Loading fixture projects...[DONE] - Loading fixture protected_branches...[SKIPPING] - Loading fixture schema_migrations...[DONE] - Loading fixture services...[SKIPPING] - Loading fixture snippets...[SKIPPING] - Loading fixture taggings...[SKIPPING] - Loading fixture tags...[SKIPPING] - Loading fixture users...[DONE] - Loading fixture users_projects...[DONE] - Loading fixture web_hooks...[SKIPPING] - Loading fixture wikis...[SKIPPING] Restoring repositories: - Restoring repository abcd... [DONE] - Object pool 1 ... Deleting tmp directories...[DONE] ``` 接下來，如果需要，請如上所述恢復`/home/git/gitlab/.secret` . 重新啟動 GitLab： ``` sudo service gitlab restart ``` ### Restore for Omnibus GitLab installations[](#restore-for-omnibus-gitlab-installations "Permalink") 此過程假定： * 您已經安裝了與創建備份**完全相同**的 GitLab Omnibus **版本和類型（CE / EE）** . * 您已經至少運行過`sudo gitlab-ctl reconfigure`一次. * GitLab 正在運行. 如果沒有，請使用`sudo gitlab-ctl start`啟動它. 首先，請確保您的備份 tar 文件位于`gitlab.rb`配置`gitlab_rails['backup_path']`描述的備份目錄中. 默認值為`/var/opt/gitlab/backups` . 它必須由`git`用戶擁有. ``` sudo cp 11493107454_2018_04_25_10.6.4-ce_gitlab_backup.tar /var/opt/gitlab/backups/ sudo chown git.git /var/opt/gitlab/backups/11493107454_2018_04_25_10.6.4-ce_gitlab_backup.tar ``` 停止連接到數據庫的進程. 保持其余的 GitLab 運行： ``` sudo gitlab-ctl stop unicorn sudo gitlab-ctl stop puma sudo gitlab-ctl stop sidekiq # Verify sudo gitlab-ctl status ``` 接下來，還原備份，并指定要還原的備份的時間戳記： ``` # This command will overwrite the contents of your GitLab database! sudo gitlab-backup restore BACKUP=11493107454_2018_04_25_10.6.4-ce ``` **注意**對于 GitLab 12.1 和更早版本，請使用`gitlab-rake gitlab:backup:restore` .**警告：** `gitlab-rake gitlab:backup:restore`沒有在您的注冊表目錄上設置正確的文件系統權限. 這是一個[已知問題](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/62759) . 在 GitLab 12.2 或更高版本上，您可以使用`gitlab-backup restore`來避免此問題. 接下來，根據需要如上所述恢復`/etc/gitlab/gitlab-secrets.json` . 重新配置，重啟并檢查 GitLab： ``` sudo gitlab-ctl reconfigure sudo gitlab-ctl restart sudo gitlab-rake gitlab:check SANITIZE=true ``` 如果您的備份 tar 文件和已安裝的 GitLab 版本之間的 GitLab 版本不匹配，則 restore 命令將中止并顯示錯誤. 安裝[正確的 GitLab 版本，](https://packages.gitlab.com/gitlab/)然后重試. **注意**當前存在一個與`pgbouncer`不兼容的還原[問題](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/3470) . 為了解決該問題，Rails 節點將需要繞過`pgbouncer`并直接連接到主數據庫節點. 這可以通過設置`gitlab_rails['db_host']`和`gitlab_rails['port']`連接到主數據庫節點并[重新配置 GitLab 來完成](../administration/restart_gitlab.html#omnibus-gitlab-reconfigure) . ### Restore for Docker image and GitLab Helm chart installations[](#restore-for-docker-image-and-gitlab-helm-chart-installations "Permalink") 對于使用 Kubernetes 集群上的 Docker 映像或 GitLab Helm 圖表進行的 GitLab 安裝，還原任務期望還原目錄為空. 但是，使用 Docker 和 Kubernetes 卷掛載，可能會在卷根目錄上創建一些系統級目錄，例如 Linux 操作系統中找到的`lost+found`目錄. 這些目錄通常歸`root`擁有，因為 restore Rake 任務以`git`用戶身份運行，因此可能導致訪問權限錯誤. 因此，要還原 GitLab 安裝，用戶必須確認還原目標目錄為空. 對于這兩種安裝類型，備份 tarball 必須在備份位置（默認位置為`/var/opt/gitlab/backups` ）中`/var/opt/gitlab/backups` . 對于 Docker 安裝，可以從主機運行還原任務： ``` docker exec -it <name of container> gitlab-backup restore ``` **注意**對于 GitLab 12.1 和更早版本，請使用`gitlab-rake gitlab:backup:restore` .**警告：** `gitlab-rake gitlab:backup:restore`沒有在您的注冊表目錄上設置正確的文件系統權限. 這是一個[已知問題](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/62759) . 在 GitLab 12.2 或更高版本上，您可以使用`gitlab-backup restore`來避免此問題. GitLab Helm 圖表使用不同的過程，在[恢復 GitLab Helm 圖表安裝中](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/doc/backup-restore/restore.md)記錄了該過程. ### Restoring only one or a few project(s) or group(s) from a backup[](#restoring-only-one-or-a-few-projects-or-groups-from-a-backup "Permalink") 盡管用于還原 GitLab 實例的 Rake 任務不支持還原單個項目或組，但是您可以使用一種解決方法，將備份還原到單獨的臨時 GitLab 實例，然后從那里導出您的項目或組： 1. 以與要還原的備份實例相同的版本[安裝新的 GitLab](../install/README.html)實例. 2. [將備份還原](#restore-gitlab)到此新實例中，然后導出您的[項目](../user/project/settings/import_export.html)或[組](../user/group/settings/import_export.html) . 確保閱讀任一導出功能文檔上的**重要說明** ，以了解將導出什么內容，不導出什么內容. 3. 導出完成后，轉到舊實例并導入它. 4. 僅在完成所需的項目或組的導入后，您可以刪除新的臨時 GitLab 實例. **注意**在[問題＃17517 中](https://gitlab.com/gitlab-org/gitlab/-/issues/17517)討論了提供直接還原單個項目或組的功能請求. ## Alternative backup strategies[](#alternative-backup-strategies "Permalink") 如果您的 GitLab 服務器包含很多 Git 存儲庫數據，您可能會發現 GitLab 備份腳本太慢. 在這種情況下，您可以考慮將文件系統快照用作備份策略的一部分. 示例：Amazon EBS > A GitLab server using Omnibus GitLab hosted on Amazon AWS. An EBS drive containing an ext4 filesystem is mounted at `/var/opt/gitlab`. In this case you could make an application backup by taking an EBS snapshot. The backup includes all repositories, uploads and PostgreSQL data. 示例：LVM 快照+ rsync > 使用 Omnibus GitLab 的 GitLab 服務器，其 LVM 邏輯卷安裝在`/var/opt/gitlab` . 使用 rsync 復制`/var/opt/gitlab`目錄將不可靠，因為運行 rsync 時會更改太多文件. 而不是 rsync-ing `/var/opt/gitlab` ，我們創建一個臨時 LVM 快照，將其作為只讀文件系統安裝在`/mnt/gitlab_backup` . 現在，我們可以運行更長的 rsync 作業，它將在遠程服務器上創建一致的副本. 副本包括所有存儲庫，上載和 PostgreSQL 數據. 如果您在虛擬服務器上運行 GitLab，則還可以創建整個 GitLab 服務器的 VM 快照. 但是，VM 快照要求您關閉服務器電源的情況并不少見，因此這種方法的實際使用可能受到限制. ## Additional notes[](#additional-notes "Permalink") 本文檔適用于 GitLab 社區和企業版. 我們備份 GitLab.com 并確保您的數據安全，但是您不能使用這些方法自己從 GitLab.com 導出/備份數據. 問題存儲在數據庫中. 它們不能存儲在 Git 本身中. 要使用最新版本的 GitLab 將存儲庫從一臺服務器遷移到另一臺服務器，可以使用[import Rake 任務](import.html)來批量導入存儲庫. 請注意，如果您執行導入 Rake 任務而不是備份還原，則將擁有所有存儲庫，但沒有其他任何數據. ## Troubleshooting[](#troubleshooting "Permalink") 以下是可能的解決方案可能遇到的問題. ### Restoring database backup using Omnibus packages outputs warnings[](#restoring-database-backup-using-omnibus-packages-outputs-warnings "Permalink") 如果使用備份還原過程，則可能會遇到以下警告： ``` psql:/var/opt/gitlab/backups/db/database.sql:22: ERROR: must be owner of extension plpgsql psql:/var/opt/gitlab/backups/db/database.sql:2931: WARNING: no privileges could be revoked for "public" (two occurrences) psql:/var/opt/gitlab/backups/db/database.sql:2933: WARNING: no privileges were granted for "public" (two occurrences) ``` 請注意，盡管有這些警告，備份仍成功還原. Rake 任務以`gitlab`用戶身份運行，該用戶沒有對數據庫的超級用戶訪問權限. 啟動還原時，它還將以`gitlab`用戶身份運行，但也會嘗試更改其無權訪問的對象. 這些對象對數據庫的備份/還原沒有影響，但是它們發出此煩人的警告. 有關更多信息，請參見[此處](https://s0www0postgresql0org.icopy.site/message-id/201110220712.30886.adrian.klaver@gmail.com)和[此處](https://s0www0postgresql0org.icopy.site/message-id/2039.1177339749@sss.pgh.pa.us)有關 PostgreSQL 問題跟蹤器的類似問題以及[堆棧溢出](https://stackoverflow.com/questions/4368789/error-must-be-owner-of-language-plpgsql) . ### When the secrets file is lost[](#when-the-secrets-file-is-lost "Permalink") 如果您無法[備份 secrets 文件](#storing-configuration-files) ，則啟用 2FA 的用戶將無法登錄 GitLab. 在這種情況下，您需要[為所有人禁用 2FA](../security/two_factor_authentication.html#disabling-2fa-for-everyone) . 機密文件還負責為包含敏感信息的幾列存儲加密密鑰. 如果密鑰丟失，GitLab 將無法解密這些列. 這將破壞廣泛的功能，包括（但不限于）： * [CI/CD variables](../ci/variables/README.html) * [Kubernetes / GCP integration](../user/project/clusters/index.html) * [Custom Pages domains](../user/project/pages/custom_domains_ssl_tls_certification/index.html) * [Project error tracking](../user/project/operations/error_tracking.html) * [Runner authentication](../ci/runners/README.html) * [Project mirroring](../user/project/repository/repository_mirroring.html) * [Web hooks](../user/project/integrations/webhooks.html) 在 CI / CD 變量和 Runner 身份驗證之類的情況下，您可能會遇到一些意外行為，例如： * 卡住了工作. * 500 個錯誤. 您可以使用[Secrets Doctor Rake 任務](../administration/raketasks/doctor.html)檢查數據庫中是否具有不可解密的值. 在這種情況下，您需要重置 CI / CD 變量和運行程序身份驗證的所有令牌，下面將對此進行詳細說明. 重置令牌后，您應該能夠訪問您的項目，并且作業將重新開始運行. **警告：**使用以下命令需要您自擔風險，并確保事先進行了備份. #### Reset CI/CD variables[](#reset-cicd-variables "Permalink") 1. 輸入數據庫控制臺：對于 Omnibus GitLab 軟件包： ``` sudo gitlab-rails dbconsole ``` 對于源安裝： ``` sudo -u git -H bundle exec rails dbconsole -e production ``` 2. 檢查`ci_group_variables`和`ci_variables`表： ``` SELECT * FROM public."ci_group_variables"; SELECT * FROM public."ci_variables"; ``` 這些是您需要刪除的變量. 3. 放下桌子： ``` DELETE FROM ci_group_variables; DELETE FROM ci_variables; ``` 4. 您可能需要重新配置或重新啟動 GitLab 才能使更改生效. #### Reset Runner registration tokens[](#reset-runner-registration-tokens "Permalink") 1. 輸入數據庫控制臺：對于 Omnibus GitLab 軟件包： ``` sudo gitlab-rails dbconsole ``` 對于源安裝： ``` sudo -u git -H bundle exec rails dbconsole -e production ``` 2. 清除項目，組和整個實例的所有令牌： **Caution:** The last UPDATE operation will stop the runners being able to pick up new jobs. You must register new runners. ``` -- Clear project tokens UPDATE projects SET runners_token = null, runners_token_encrypted = null; -- Clear group tokens UPDATE namespaces SET runners_token = null, runners_token_encrypted = null; -- Clear instance tokens UPDATE application_settings SET runners_registration_token_encrypted = null; -- Clear runner tokens UPDATE ci_runners SET token = null, token_encrypted = null; ``` #### Reset pending pipeline jobs[](#reset-pending-pipeline-jobs "Permalink") 1. 輸入數據庫控制臺：對于 Omnibus GitLab 軟件包： ``` sudo gitlab-rails dbconsole ``` 對于源安裝： ``` sudo -u git -H bundle exec rails dbconsole -e production ``` 2. 清除所有待處理作業的令牌： ``` -- Clear build tokens UPDATE ci_builds SET token = null, token_encrypted = null; ``` 其余功能也可以采用類似的策略-通過刪除無法解密的數據，GitLab 可以恢復工作狀態，并且可以手動替換丟失的數據. ### Container Registry push failures after restoring from a backup[](#container-registry-push-failures-after-restoring-from-a-backup "Permalink") 如果使用[Container Registry](../user/packages/container_registry/index.html) ，則在還原注冊表數據后，在 Omnibus GitLab 實例上還原備份后，可能會推送到注冊表失敗. 這些失敗將在注冊表日志中提及權限問題，例如： ``` level=error msg="response completed with error" err.code=unknown err.detail="filesystem: mkdir /var/opt/gitlab/gitlab-rails/shared/registry/docker/registry/v2/repositories/...: permission denied" err.message="unknown error" ``` 這是由于還原以非特權用戶`git`身份運行的，該用戶在還原期間無法將正確的所有權分配給注冊表文件（ [問題 62759](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/62759 "還原后對注冊表文件系統的權限不正確") ）. 要使您的注冊表再次起作用： ``` sudo chown -R registry:registry /var/opt/gitlab/gitlab-rails/shared/registry/docker ``` **注意：**如果您更改了注冊表的默認文件系統位置，則需要對定制位置而不是`/var/opt/gitlab/gitlab-rails/shared/registry/docker`運行`chown` . ### Backup fails to complete with Gzip error[](#backup-fails-to-complete-with-gzip-error "Permalink") 運行備份時，您可能會收到 Gzip 錯誤： ``` sudo /opt/gitlab/bin/gitlab-backup create ... Dumping ... ... gzip: stdout: Input/output error Backup failed ``` 如果發生這種情況，請檢查以下內容： 1. 確認有足夠的磁盤空間用于 Gzip 操作. 2. 如果正在使用 NFS，請檢查是否設置了安裝選項`timeout` . 默認值為`600` ，并將其更改為較小的值會導致此錯誤.