GitLab 称有 707 位用户超 5000 个项目丢失数据

凝小紫
 凝小紫
发布于 2017年02月04日
收藏 4

GitLab 的一位系统管理员——官方博客称他是Team-member-1——本周早些时候删错了服务器上的 PostgreSQL数据库目录(他本想删除 db2.cluster.gitlab.com服务器上的目录,结果在db1.cluster.gitlab.com上执行了删除命令),导致了数百GB的产品数据被误删。GitLab随后从备份数据库恢复数据,但丢失了6小时的数据。这起事故主要影响问题和合并请求数据库,没有影响git仓库。

根据GitLab从日志里得出的结论,有707位用户丢失数据,5,037项目丢失——如果项目是在事故发生前创建的,那么GitLab能重新恢复项目,但无法完全恢复这些项目的问题和合并请求。它表示受事故影响的用户基数不到1%。

相关阅读:

稿源:solidot

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 开源中国社区 [http://www.oschina.net]
本文标题:GitLab 称有 707 位用户超 5000 个项目丢失数据
加载中

精彩评论

老腊肉
老腊肉
依然没有看到码云的回复。。。
玄聪
玄聪

引用来自“红薯”的评论

从备份里恢复,本来就是一件万不得已的事情,丢数据在所难免
来来来,你来讲讲,码云的备份机制是怎样的,遇到生产数据丢失有什么应对方案?
TGVvbmFyZA
TGVvbmFyZA
总结是 不要相信备份100%靠谱 不要相信人靠谱 人肉运维是傻逼行为 自动化运维99.99%可靠
开源中国刘德华
开源中国刘德华
本来和github争天下的,现在好了一下回到解放前

最新评论(15

爱宝贝丶
爱宝贝丶

引用来自“红薯”的评论

从备份里恢复,本来就是一件万不得已的事情,丢数据在所难免

引用来自“萝卜Robert”的评论

嗯,我准备写个运维注意事项手册或规范传码云上,避免运维常见的一些运维故障和安全故障!

引用来自“爱宝贝丶”的评论

嗯,写完了之后发出来

引用来自“萝卜Robert”的评论

大概写了下,再逐渐完善 http://git.oschina.net/aqztcom/sso
感谢分享~
厦门萝卜
厦门萝卜

引用来自“红薯”的评论

从备份里恢复,本来就是一件万不得已的事情,丢数据在所难免

引用来自“萝卜Robert”的评论

嗯,我准备写个运维注意事项手册或规范传码云上,避免运维常见的一些运维故障和安全故障!

引用来自“爱宝贝丶”的评论

嗯,写完了之后发出来
大概写了下,再逐渐完善 http://git.oschina.net/aqztcom/sso
老腊肉
老腊肉
依然没有看到码云的回复。。。
玄聪
玄聪

引用来自“红薯”的评论

从备份里恢复,本来就是一件万不得已的事情,丢数据在所难免
来来来,你来讲讲,码云的备份机制是怎样的,遇到生产数据丢失有什么应对方案?
开不了囧
开不了囧
还好我们是私服
TGVvbmFyZA
TGVvbmFyZA
总结是 不要相信备份100%靠谱 不要相信人靠谱 人肉运维是傻逼行为 自动化运维99.99%可靠
厦门萝卜
厦门萝卜

引用来自“红薯”的评论

从备份里恢复,本来就是一件万不得已的事情,丢数据在所难免

引用来自“萝卜Robert”的评论

嗯,我准备写个运维注意事项手册或规范传码云上,避免运维常见的一些运维故障和安全故障!

引用来自“爱宝贝丶”的评论

嗯,写完了之后发出来
嗯,必须的!
开源中国刘德华
开源中国刘德华
本来和github争天下的,现在好了一下回到解放前
爱宝贝丶
爱宝贝丶

引用来自“红薯”的评论

从备份里恢复,本来就是一件万不得已的事情,丢数据在所难免

引用来自“萝卜Robert”的评论

嗯,我准备写个运维注意事项手册或规范传码云上,避免运维常见的一些运维故障和安全故障!
嗯,写完了之后发出来
ihuotui
ihuotui
要结对运维才行啊,一个人容易犯错。
返回顶部
顶部