gitlab 数据库被清, 又一个没备份的

[andyfan]

据说运维以为自己操作的是从服务器, 300G 的数据删剩下 4G 才发现删的是主服务器.
http://gitlab.com
官方给出的事故详情 https://docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCxIABGiryG7_z_6jHdVik/pub

[alonezero]

备份和上次炉石事故一样，也全抽风了（ GitLab 好像剩了一个）。对了，恢复过程正在在线直播， Youtube 看不了的~可以去 B 站看转播。

[msg7086]

@shijingshijing 说得好像 gitlab 上没有 RAID 一样。
你要说自己公司里有专门一个运维团队的，搞本地 Gitlab 我还能接受。
一个学生党你自己有闲心有技术做运维？我觉得#滑稽。

[ryan93]

RAID 应该防止不了人为 rm 删除操作吧？不过如果 rm 了一个文件，若没有写入新数据，原有的文件应该可以恢复吧？

[shijingshijing]

@msg7086 所以说学生党你当我没说啊，我看 v2 上大把顶配 MacBook Pro ，自己弄个 NAS 和家庭服务器也没啥问题吧，反正我自己有个 24 小时开机的低电压 Xeon 当爬虫顺便 Gitlab

[msg7086]

@shijingshijing 买硬件的钱通常不是问题。问题在于维护团队。
你会像 Gitlab 团队那样花六七个小时去做灾难恢复么。
你会做数据库全球 replication 么（而且不能学 gitlab ，要经常做灾备演练等等
反正对于我们小公司来说，用第三方托管然后出问题让别人背锅，总比自己配一套挂了以后自己背锅要好。

[shijingshijing]

@msg7086 关键是国内算是比较好的 aliyun 也一样有不靠谱的时候啊，反正我觉得这个事情，如果我是老板，自己的东西肯定是要本地做个数据仓库的，即使是 HP 和 Dell 的小型塔式服务器，也不贵，反正这个钱是不该省的。不过一般员工的话，必然是多一事不如少一事，出了问题能甩锅就行。

[likuku]

没有定期有效还原演练检验的备份都是耍流氓，再多的无效 /未经恢复演练检验的备份那是没卵用。

[likuku]

所以全托管的 RDS 啊，某些先进云商的 RDS 服务，有自动化快照备份，可以“一个指令恢复到五分钟前的状态”

[Showfom]

我们一般一年迁移一次整体环境

[msg7086]

@shijingshijing 我说了啊，硬件的钱又不贵。塔式也好机架式也好，一台机器区区几千刀。
关键是维护成本。
而且，有多少老板敢说自己的员工比大公司的专业团队更靠谱的……

[cxbig]

又不是 SVN 。。。
用 Git 有啥好怕的，任何一个人保留最新版本，随时都可以恢复工作。

[tywtyw2002]

@Reficul
@Rand01ph

脚本只会备分本地的数据，忽略任何的软链和远程 mount 。
从 git comment 来看，有人特意修改的成这样，据说之前的脚本出现了备份 loop 。

[kitalphaj]

仅仅是 issue 和 merge requests 被删掉了吧。 gitlab 最值得表扬的是在这件事情上的透明度，人家第一时间就发推特说因为误删了 production 的数据，而且后面也用 google docs 还有 youtube 直播这件事情。至少诚意在。。。虽然没有测试 backup 也是犯了大错

[incompatible]

@shijingshijing 你这完全就是野路子。想要保证 HA 至少要在 2 个异地数据中心有 3 个副本。就算使用 AWS 或者 Aliyun ，最佳的实践也是在不同的 Available Zone 购买 instance 组建集群。
大多数人在自家搭单机 server 24 小时跑不出问题不代表你也不会出问题，因为任何事情第一次发生前，它都是史无前例的。