gitlab的備份和恢復
阿新 • • 發佈：2019-01-06
按照官方文件安裝完成後，/home/git目錄結構如下
|-- home
| |-- git
| |-- .ssh
| |-- gitlab
| |-- gitlab-satellites
| |-- gitlab-shell
| |-- repositories
/home/git/.ssh- ssh設定的目錄. gitlab-shell管理著其中的authorized_keys./home/git/gitlab- GitLab核心部分/home/git/gitlab-satellites- 可以視為臨時目錄，通過web ui的提交請求檔案以及檢出版本庫都會存放在這個位置/home/git/gitlab-shell- gitlab的核心外掛元件. 包括ssh協議克隆和其他一些功能./home/git/repositories- 原始版本庫的所有專案組織的名稱空間，也就是所有倉庫的儲存位置，所以這個目錄裡的資料非常重要，注意備份 這是專案的關鍵資料. Keep a backup
注意; gitlab-satellites 和 repositories的路徑都被定義在gitlab中的 config/gitlab.yml 和
gitlab-shell. 中的config.yml
執行備份的命令時，網上看到其他人說的命令：
gitlab-rake gitlab:backup 這個命令根本就找不到，不知道是不是版本的原因，後來在這個目錄下面找到相對應的命令：
具體的備份和恢復命令如下：
建立為所有版本庫的存檔，就是備份啦. 儲存路徑在gitlab中的 config/gitlab.yml
檔案命名 [TIMESTAMP]_gitlab_backup.tar.
1
|
bundle exec rake gitlab:backup:create RAILS_ENV=production
|
類似如下:
1
|
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] |
利用備份檔案恢復
1
|
bundle exec rake gitlab:backup:restore RAILS_ENV=production
|
選項:
1
|
BACKUP=timestamp_of_backup (required if more than one backup exists)
|
類似這樣:
1
|
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]
Deleting tmp directories...[DONE]
|
由於是第一次接觸這個gitlab的配置，所以中間遇到一些比較基礎的問題，還是困擾了很久，現在貼出來：
1.由於gitlab的正常使用涉及到很多的東西，包括：redis、mysql、ruby、nginx和gitlab本身，
gitlab的安裝本身是一個非常複雜、冗餘的過程，此處略去。 2.遇到的第一個問題是訪問IP的時候，報500錯誤。Please Contact gitlab administrator...... 這是因為redis沒有啟動導致的，service redis start 執行成功後,就能正常的訪問gitlab的web頁面了 3.通過http://192.168.1.8 訪問gitlab頁面的時候，發現專案的git地址不對，正確的應該是 [email protected]:behavior/BehavioralData.git 但是 在專案主介面看到的卻是一個莫名巧妙的IP：[email protected]:behavior/BehavioralData.git
這是因為在config/gitlab.yml檔案中的host屬性 被設定為了 192.168.0.6，將這個屬性改為 192.18.1.8即可。 4.然後，又碰到了另外的問題。 以上的問題，解決後，發現不能從gitlab拉取專案，這時發現 其實還是在gitlab-shell檔案家中config.yml檔案中還有一個屬性被設為 192.168.0.6了 這同樣需要修改為 192.168.1.8 5.最後 碰到了最重要、最常見、最基本的問題。 發現往gitlab上提交修改的時候，老是提示 Access Denied 通常只要提示 Access Denied或者Make Sure You have the rights之類的資訊時，基本上就能確定原因是： 你提交的操作過程中，客戶端跟gitlab伺服器之間驗證ssh key的時候 不一致導致的。 首先，在sourcetree中生成ssh的公鑰和私鑰，把公鑰內容複製新增到gitlab伺服器中的ssh keys中，私鑰檔案儲存在本地。 然後，就是sourcetree啟動的時候，其實還啟動了另外一個守護程序Pageant 右鍵點選，雙擊之，進入這個介面： 再將剛才生成並儲存到本地的私鑰檔案，新增到這個列表中即可。