首页 ›存档› 技术 › 查看内容

浅谈gitlab备份机制

2018-3-30 13:00 |来自: 互联网 843 0

摘要: 0x00、事件描述信息来源：https://twitter.com/gitlabstatus 2017年1月31日，上午10点左右官方公布出现问题，2017年2月1日，上午9:57 完成恢复，大约经历了24小时。 0x01、事件原因 2017/01/31 18:00 UTC 发现spam ...

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	~