gitlab的备份和恢复

按照官方文档安装完成后，/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:create

这个命令根本就找不到，不知道是不是版本的原因，后来在这个目录下面找到相对应的命令：

具体的备份和恢复命令如下：

创建为所有版本库的存档，就是备份啦. 存储路径在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地址不对，正确的应该是

git@192.168.1.8:behavior/BehavioralData.git   但是 在项目主界面看到的却是一个莫名巧妙的IP：

git@192.168.0.6: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

右键点击，双击之，进入这个界面：

再将刚才生成并保存到本地的私钥文件，添加到这个列表中即可。