gitlab主备同步_浅谈gitlab备份机制

0x00、事件描述

信息来源：https://twitter.com/gitlabstatus

2017年1月31日，上午10点左右官方公布出现问题，2017年2月1日，上午9:57 完成恢复，大约经历了24小时。

0x01、事件原因

2017/01/31 18:00 UTC 发现spammers攻击gitlab，使得数据库不稳定。

2017/01/31 21:00 UTC 发现47 000 IPs签名使用同一个账号，造成数据库高负载。(传说中的CC？)

2017/01/31 22:00 UTC 数据库集群同步被打断。DB Replication没有及时写。

2017/01/31 23:00-ish pg_basebackup拒绝数据库文件同步工作，由于PostgreSQL数据目录存在(尽管是空的)，管理员决定删除该目录。 一两秒后，他注意到他在db1.cluster.gitlab.com上运行它，而不是db2.cluster.gitlab.com。导致生产数据被删除，灾难发生。

2017/01/31 23:27 管理员终止了删除，但是为时已晚。 在大约300 GB左右，只剩下约4.5 GB (妈蛋，这可是主库呀，还有和TMD rm -rf有JM关系，正常的维护，但是管理好像不懂postgresql集群工作原理。)

备份机制

定期备份似乎也只是每24小时一次，管理员还不知道在哪？

pg_dump失败，因为postgresql版本不是9.6而是9.2

Disk snapshots在微软Azure上只做NFS快照，没有postgresql快照

shell脚本做复制非常脆弱，而且日志记录很糟糕。

S3上的备份没有起作用。

发现，基本5种备份机制都失效了。

0x02、浅谈gitlab备份容灾机制

了解gitlab架构和工作原理

GitLab由以下服务构成：

nginx：静态Web服务器

gitlab-shell：用于处理Git命令和修改authorized keys列表

gitlab-workhorse:轻量级的反向代理服务器，GitLab Workhorse是一个敏捷的反向代理。它会处理一些大的HTTP请求，比如文件上传、文件下载、Git push/pull和Git包下载。其它请求会反向代理到GitLab Rails应用，即反向代理给后端的unicorn。

logrotate：日志文件管理工具

postgresql：数据库

redis：缓存数据库

sidekiq：用于在后台执行队列任务(异步执行)

unicorn：An HTTP server for Rack applications，GitLab Rails应用是托管在这个服务器上面的。

工作原理图：

系统自带备份恢复方法：

https://docs.gitlab.com/ce/raketasks/backup_restore.html#configure-cron-to-make-daily-backups

备份调研：

当然根据自己的实际需求调整参数。

系统名称

数据类型

数据量

RPO

RTO

备份周期

备份保存周期

Gitlab代码托管系统

应用数据

10G

1h

4h

每4小时全备(重复数据删除)

14天

postgresql数据库(快照方式)

30G

1h

4h

每4小时全备(重复数据删除)

14天

repositories(NFS方式)

60G

1day

1day

每天全备(重复数据删除)

14天

postgresql数据库(数据库同步)

30G

15min

15min

All time

~

安全方面：建议监控一下URL访问频率，快速发现恶意行为。不要因为安全问题，导致数据库同步失败或者滞后。

0x03、建议

从宏观上讲：

(1)备份系统建设一般都分为两个阶段，第一阶段是针对关键系统的备份建设，第二阶段是建立集中备份管理系统，把业务系统备份做成一个通用平台。

(2)确定需要备份的系统的RPO和RTO要求，最好有了备份才考虑容灾。

(3)容灾系统打算建立多大的？本地HA、active-active HA、同城容灾、两地三中心。

从微观上讲：

(1)互联网公司内部gitlab还是要根据官方给出的备份恢复建议去做。

(2)数据库集群同步要找个明白人运维。(postgresql，一般商业备份容灾软件都不支持)

还有本身gitlab的备份方式其实已经很完备，但是就是运维系统没有做备份或者数据库同步失败的告警，并且做出正确的应急处置。

本文转载于微信公众号: IT信息安全顾问(GSGSoft)，更多微信文章请扫描关注公众号:

Tag标签: