gitlab备份的重要性不言而喻
下面首先是备份gitlab备份的常用操作
1)Gitlab的备份目录路径设置
1
2
3
4
5
6
7
8
9
10
11
12
|
[root@code-server ~] # vim /etc/gitlab/gitlab.rb gitlab_rails[ 'manage_backup_path' ] = true gitlab_rails[ 'backup_path' ] = "/data/gitlab/backups" //gitlab 备份目录 gitlab_rails[ 'backup_archive_permissions' ] = 0644 // 生成的备份文件权限 gitlab_rails[ 'backup_keep_time' ] = 7776000 // 备份保留天数为3个月(即90天,这里是7776000秒) [root@code-server ~] # mkdir -p /data/gitlab/backups [root@code-server ~] # chown -R git.git /data/gitlab/backups [root@code-server ~] # chmod -R 777 /data/gitlab/backups 如上设置了gitlab备份目录路径为 /data/gitlab/backups ,最后使用下面命令重载gitlab配置文件,是上述修改生效! root@code-server ~] # gitlab-ctl reconfigure |
2)GItlab备份操作(使用备份命令"gitlab-rake gitlab:backup:create")
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
|
手动备份gitlab [root@code-server backups] # gitlab-rake gitlab:backup:create Dumping database ... Dumping PostgreSQL database gitlabhq_production ... [DONE] done Dumping repositories ... * treesign /treesign ... [DONE] * gateway /gateway ... [DONE] * treesign /treesign-doc ... [SKIPPED] * qwsign /qwsign ... [DONE] * qwsign /qwsign-doc ... [DONE] * test /test ... [DONE] done Dumping uploads ... done Dumping builds ... done Dumping artifacts ... done Dumping pages ... done Dumping lfs objects ... done Dumping container registry images ... [DISABLED] Creating backup archive: 1510471890_2017_11_12_9.4.5_gitlab_backup. tar ... done Uploading backup archive to remote storage ... skipped Deleting tmp directories ... done done done done done done done done Deleting old backups ... done . (0 removed) 然后查看下备份文件(文件权限是设定好的644) [root@code-server backups] # ll total 244 -rw-r--r-- 1 git git 245760 Nov 12 15:33 1510472027_2017_11_12_9.4.5_gitlab_backup. tar 编写备份脚本,结合 crontab 实施自动定时备份,比如每天0点、6点、12点、18点各备份一次 [root@code-server backups] # pwd /data/gitlab/backups [root@code-server backups] # vim gitlab_backup.sh #!/bin/bash /usr/bin/gitlab-rake gitlab:backup:create CRON=1 注意:环境变量CRON=1的作用是如果没有任何错误发生时, 抑制备份脚本的所有进度输出 [root@code-server backups] # crontab -l 0 0,6,12,18 * * * /bin/bash -x /data/gitlab/backups/gitlab_backup .sh > /dev/null 2>&1 |
3)Gitlab恢复操作
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
|
GItlab只能还原到与备份文件相同的gitlab版本。 假设在上面gitlab备份之前创建了 test 项目,然后不小心误删了 test 项目,现在就进行gitlab恢复操作: 1)停止相关数据连接服务 [root@code-server backups] # gitlab-ctl stop unicorn ok: down: unicorn: 0s, normally up [root@code-server backups] # gitlab-ctl stop sidekiq ok: down: sidekiq: 1s, normally up [root@code-server backups] # gitlab-ctl status run: gitaly: (pid 98087) 1883s; run: log: (pid 194202) 163003s run: gitlab-monitor: (pid 98101) 1883s; run: log: (pid 194363) 163002s run: gitlab-workhorse: (pid 98104) 1882s; run: log: (pid 194362) 163002s run: logrotate: (pid 98117) 1882s; run: log: (pid 5793) 160832s run: nginx: (pid 98123) 1881s; run: log: (pid 194359) 163002s run: node-exporter: (pid 98167) 1881s; run: log: (pid 194360) 163002s run: postgres-exporter: (pid 98173) 1881s; run: log: (pid 194204) 163003s run: postgresql: (pid 98179) 1880s; run: log: (pid 194365) 163002s run: prometheus: (pid 98187) 1880s; run: log: (pid 194364) 163002s run: redis: (pid 98230) 1879s; run: log: (pid 194358) 163002s run: redis-exporter: (pid 98234) 1879s; run: log: (pid 194208) 163003s down: sidekiq: 8s, normally up; run: log: (pid 194437) 163001s down: unicorn: 21s, normally up; run: log: (pid 194443) 163001s 2)现在通过之前的备份文件进行恢复(必须要备份文件放到备份路径下,这里备份路径我自定义的 /data/gitlab/backups ,默认的是 /var/opt/gitlab/backups ) [root@code-server backups] # pwd /data/gitlab/backups [root@code-server backups] # ll total 244 -rw-r--r-- 1 git git 245760 Nov 12 15:33 1510472027_2017_11_12_9.4.5_gitlab_backup. tar Gitlab的恢复操作会先将当前所有的数据清空,然后再根据备份数据进行恢复 [root@code-server backups] # gitlab-rake gitlab:backup:restore BACKUP=1510472027_2017_11_12_9.4.5 Unpacking backup ... done Before restoring the database we recommend removing all existing tables to avoid future upgrade problems. Be aware that if you have custom tables in the GitLab database these tables and all data will be removed. Do you want to continue ( yes /no )? ........ ALTER TABLE ALTER TABLE ALTER TABLE ALTER TABLE WARNING: no privileges were granted for "public" GRANT [DONE] done Restoring repositories ... * treesign /treesign ... [DONE] * gateway /gateway ... [DONE] * treesign /treesign-doc ... [DONE] * qwsign /qwsign ... [DONE] * qwsign /qwsign-doc ... [DONE] * test /test ... [DONE] Put GitLab hooks in repositories dirs [DONE] done Restoring uploads ... done Restoring builds ... done Restoring artifacts ... done Restoring pages ... done Restoring lfs objects ... done This will rebuild an authorized_keys file . You will lose any data stored in authorized_keys file . Do you want to continue ( yes /no )? yes Deleting tmp directories ... done done done done done done done done [root@code-server backups] # 最后再次启动Gitlab [root@code-server backups] # gitlab-ctl start ok: run: gitaly: (pid 98087) 2138s ok: run: gitlab-monitor: (pid 98101) 2138s ok: run: gitlab-workhorse: (pid 98104) 2137s ok: run: logrotate: (pid 98117) 2137s ok: run: nginx: (pid 98123) 2136s ok: run: node-exporter: (pid 98167) 2136s ok: run: postgres-exporter: (pid 98173) 2136s ok: run: postgresql: (pid 98179) 2135s ok: run: prometheus: (pid 98187) 2135s ok: run: redis: (pid 98230) 2134s ok: run: redis-exporter: (pid 98234) 2134s ok: run: sidekiq: (pid 104494) 0s ok: run: unicorn: (pid 104497) 1s [root@code-server backups] # gitlab-ctl status run: gitaly: (pid 98087) 2142s; run: log: (pid 194202) 163262s run: gitlab-monitor: (pid 98101) 2142s; run: log: (pid 194363) 163261s run: gitlab-workhorse: (pid 98104) 2141s; run: log: (pid 194362) 163261s run: logrotate: (pid 98117) 2141s; run: log: (pid 5793) 161091s run: nginx: (pid 98123) 2140s; run: log: (pid 194359) 163261s run: node-exporter: (pid 98167) 2140s; run: log: (pid 194360) 163261s run: postgres-exporter: (pid 98173) 2140s; run: log: (pid 194204) 163262s run: postgresql: (pid 98179) 2139s; run: log: (pid 194365) 163261s run: prometheus: (pid 98187) 2139s; run: log: (pid 194364) 163261s run: redis: (pid 98230) 2138s; run: log: (pid 194358) 163261s run: redis-exporter: (pid 98234) 2138s; run: log: (pid 194208) 163262s run: sidekiq: (pid 104494) 4s; run: log: (pid 194437) 163260s run: unicorn: (pid 104497) 4s; run: log: (pid 194443) 163260s 恢复命令完成后,可以check检查一下恢复情况 [root@code-server backups] # gitlab-rake gitlab:check SANITIZE=true Checking GitLab Shell ... GitLab Shell version >= 5.3.1 ? ... OK (5.3.1) Repo base directory exists? default... yes Repo storage directories are symlinks? default... no Repo paths owned by git:root, or git:git? default... yes Repo paths access is drwxrws---? default... yes hooks directories in repos are links: ... 5 /1 ... ok 6 /2 ... ok 5 /3 ... repository is empty 12 /4 ... ok 12 /5 ... ok Running /opt/gitlab/embedded/service/gitlab-shell/bin/check Check GitLab API access: OK Access to /var/opt/gitlab/ . ssh /authorized_keys : OK Send ping to redis server: OK gitlab-shell self-check successful Checking GitLab Shell ... Finished Checking Sidekiq ... Running? ... yes Number of Sidekiq processes ... 1 Checking Sidekiq ... Finished Checking Reply by email ... Reply by email is disabled in config /gitlab .yml Checking Reply by email ... Finished Checking LDAP ... LDAP is disabled in config /gitlab .yml Checking LDAP ... Finished Checking GitLab ... Git configured correctly? ... yes Database config exists? ... yes All migrations up? ... yes Database contains orphaned GroupMembers? ... no GitLab config exists? ... yes GitLab config up to date ? ... yes Log directory writable? ... yes Tmp directory writable? ... yes Uploads directory exists? ... yes Uploads directory has correct permissions? ... yes Uploads directory tmp has correct permissions? ... yes Init script exists? ... skipped (omnibus-gitlab has no init script) Init script up-to- date ? ... skipped (omnibus-gitlab has no init script) Projects have namespace: ... 5 /1 ... yes 6 /2 ... yes 5 /3 ... yes 12 /4 ... yes 12 /5 ... yes Redis version >= 2.8.0? ... yes Ruby version >= 2.3.3 ? ... yes (2.3.3) Git version >= 2.7.3 ? ... yes (2.13.4) Active users : ... 11 Checking GitLab ... Finished 然后稍等一会(如果启动gitlab后,访问出现500,这是因为redis等程序还没完全启动,等一会儿访问就ok了),再次登录Gitlab,就会发现之前误删除的 test 项目已经恢复了! 另外:Gitlab迁移与恢复一样,但是要求两个GitLab版本号一致 |
转自:https://www.cnblogs.com/kevingrace/p/7821529.html
4)gitlab备份脚本
这里需要两个脚本,gitlab备份和文件传输脚本
备份文件位置:/data/backups/gitlab
脚本位置:/data/backups/script
gitlab备份脚本如下
脚本说明:
1.脚本除了备份gitlab代码,同时也备份配置文件gitlab.rb和gitlab-secrets.json
2.备份完自动调用文件传输脚本
3.我这里git配置的参数为 gitlab_rails['backup_keep_time'] = 604800,考虑到容量问题,这里保留一周的备份文件
#!/bin/bash /usr/bin/gitlab-rake gitlab:backup:create #CRON=1 cp -f /etc/gitlab/gitlab.rb /data/backups/gitlab cp -f /etc/gitlab/gitlab-secrets.json /data/backups/gitlab sh /data/backups/script/rsync.sh /data/backups/gitlab/cron.log
文件同步脚本如下
脚本说明:
1.rsync 带有 --delete参数,传输时,会自动删除被传输机器上比源文件机器多的文件,达到自动清理文件的目的
#!/bin/bash datetime=`date +%Y%m%d-%H-%M-%S` logfile=$1 echo "$datetime Rsync backup mysql start " >> $logfile rsync -e "ssh -p22" -avpgolr --delete /data/backups bigtree@10.30.30.6:/data/backup_data/bigtree/gitlab_bak/10.30.30.12/ >> $logfile 2>&1 ret=`tail -n 1 $logfile |grep "total size"|wc -l` if [ "$ret" = 1 ] ; then echo "$datetime Rsync backup gitlab finish " >> $logfile else echo "$datetime Rsync backup failure ,pls sendmail" >> $logfile fi
crontab定时任务如下
这里设定的是每天中午1点和晚上8点各备份一次
0 13,20 * * * /bin/bash -x /data/backups/script/gitlab_backup.sh > /data/backups/gitlab/cron.log 2>&1