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
備份調研：
當然根據自己的實際需求調整參數。
系統名稱數據類型數據量RPORTO備份周期備份保存周期Gitlab代碼託管系統應用數據10G1h4h每4小時全備（重複數據刪除）14天安全方面：建議監控一下URL訪問頻率，快速發現惡意行為。不要因為安全問題，導致資料庫同步失敗或者滯後。
0x03、建議
從宏觀上講：
（1）備份系統建設一般都分為兩個階段，第一階段是針對關鍵系統的備份建設，第二階段是建立集中備份管理系統，把業務系統備份做成一個通用平臺。
（2）確定需要備份的系統的RPO和RTO要求，最好有了備份才考慮容災。
（3）容災系統打算建立多大的？本地HA、active-active HA、同城容災、兩地三中心。
從微觀上講：
（1）網際網路公司內部gitlab還是要根據官方給出的備份恢復建議去做。
（2）資料庫集群同步要找個明白人運維。（postgresql，一般商業備份容災軟體都不支持）
還有本身gitlab的備份方式其實已經很完備，但是就是運維系統沒有做備份或者資料庫同步失敗的告警，並且做出正確的應急處置。