如何评价 2017 年 2 月 1 日 GitLab 数据库被误删_百度知道
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。
如何评价 2017 年 2 月 1 日 GitLab 数据库被误删
我有更好的答案
然后源选择postgresql转数据库偷懒的做法就是：用一台装有sql server的机器，目标选择mysql，简单的数据库一下就能导过去，直接导，运行DTS程序（导入导出数据），但是出于需要，还是建议人工建表。。。记得装ms的两个数据库驱动程序 很多情况下
为您推荐：
其他类似问题
换一换
回答问题，赢新手礼包请输入正确的邮箱
已有帐号请点击
帐号创建成功！
我们刚刚给你发送了一封验证邮件
请在48小时内查收邮件,并按照提示验证邮箱
感谢你对微口网的信任与支持
如果你没有收到邮件，请留意垃圾箱 或 重新发送
你输入的邮箱还未注册
还没有帐号请点击
你输入的邮箱还未注册
又想起来了？
邮件发送成功！
我们刚刚给你发送了一封邮件
请在5分钟内查收邮件,并按照提示重置密码
感谢你对微口网的信任与支持
如果你没有收到邮件，请留意垃圾箱 或 重新发送
对不起，你的帐号尚未验证
如果你没有收到邮件，请留意垃圾箱 或
意见与建议
请留下您的联系方式
* 留下您正确的联系方式，以便工作人员尽快与你取得联系
转藏至我的藏点1582被浏览452425分享邀请回答/document/d/1GCK53YDcBWQveod9kfzW-VCxIABGiryG7_z_6jHdVik/pub恢复过程直播，有一些工程师的现场答疑：OSChina的中文报道：YCombinator的英文讨论：目前来看最终会丢失一小部分线上数据（6个小时的issues、comments、merge requests等，代码和wiki文档不受影响），或许不算是灾难级的事故，但教训仍然是深刻的。GitLab 去年曾经提出自建私有云服务的计划，这次事故对于他们的声誉也会是一个沉重打击。如何面对事故这次事故虽然暴露了 GitLab 内部的一些问题，但他们的应对方式和态度还是值得赞许和学习的：- Don't panic，承担责任的人才有犯错的机会，"You're not one of the team until you've brought down the server."- 信息透明，尽可能寻求帮助- 首先齐心合力解决问题，然后检讨流程，不归责于个人- 提交详尽的事故报告（postmortem），从错误中积累经验GitLab 的教训以下简单总结这次事故中 GitLab 犯的一系列错误。1、在深夜做高风险操作事件的起因是 GitLab 遭到攻击后，一位工程师加班到深夜维护线上环境。因为遇到了种种常规脚本没能解决的问题，不得不进行大量人工操作，于是在精力不济后出现致命失误，准备从 db1 同步到 db2 时错误的删除了 db1 的数据。2、部分备份脚本/设置没有定期维护GitLab 的 PostGreSQL 本地备份和 Amazon S3 备份都没有正常工作。其中 PostGreSQL 本地备份设置在数据库版本升级后失效了，但没有人注意到。其它备份脚本也处于散落各处，长期无人维护的状态。3、部分备份方案没有覆盖到所有数据类型Azure 提供了磁盘快照服务，但 GitLab 的 数据库服务器并没有使用，只在 NFS 服务器上使用了。4、部分备份方案没有保留完整数据GitLab 在 Staging 环境上有一份6小时以前的数据，但其中没有保留 Webhook（STG 环境不应产生真实的 Webhook 行为）。实际上 Staging 环境本就不应该承担备份的责任，但这是 GitLab 眼下能找到的最完整历史数据了。后来他们在其它的备份中补回了 Webhook 的数据。5、备份流程没有 Monitoring 和 Alert因为没有 Monitoring 和 Alert，以上这些安全隐患长期没有人发现和注意。6、备份频率不足GitLab 的各种备份方案都是每天运行一次，从这次事件来看，对于他们来说可能还是不够。7、备份不能正确恢复/需要太长时间GitLab 的 LVM 快照因为某些原因，没能正确恢复成功。从 Staging 环境恢复到 Production 环境的过程中，因为跨数据中心的网速以及 Staging 环境的磁盘速度等原因，备份数据在10个小时后还只传了一半，大大拖延了恢复进程。8、没有正确的设置维护 PostGreSQL事故发生后一些第三方评论指出（参见官方事故报告附录），GitLab 没有正确的配置和使用 PostGreSQL，也是这次事故升级的部分原因。如何做得更好GitLab 在事故报告之后附上了内部总结的若干 TODO 事项，对于其它流程不够完备的中小型团队来说，可以考虑同样做一遍自查。以下是我个人的一些建议：1、审核所有数据的备份方案，备份频率如何，备份数据放在哪里，保留多久。2、对于云服务自带的镜像备份等服务，确认是否正确的打开和设置3、对于自行搭建的备份方案，确认
- 是否覆盖了所有重要数据
- 是否还在正常工作，考虑设置相关 Monitoring 和 Alert
- 相关的 script 和 configuration 进入源码管理
- 最终备份文件考虑存储不止一份（本地、不同的云服务商），使用云服务时最好使用单独的文件存储服务，而非直接放置在VM镜像内4、定期做灾备演习，检验是否可以正确从备份中恢复，以及此过程需要多少时间和资源。5、将灾备流程文档化，日常服务器维护流程中的注意事项也写成 checklist（或脚本化）。6、降低 Production 环境的误操作可能
- 提倡 IAC （Infrastructure as Code）的最佳实践
- 深夜等工作时间外服务器出现状况时，优先考虑基于 CI 的 rollback 等自动化操作，高风险的人工操作尽量放在工作时间，有其它同事可以监督或者支援
- 考虑在 Production 环境的 CLI 界面中增加更多防呆提示（比如设置不同颜色，对于 rm 命令使用 alias 增加保护性检查等）7、今天数据库运维仍然是一项比想象中更困难的任务，即使对于 GitLab 这样的成熟团队也是如此。对于没有专职 DBA 的创业公司来说，直接使用云服务商提供的数据库服务可能更为安全高效。43318 条评论分享收藏感谢收起/document/d/1GCK53YDcBWQveod9kfzW-VCxIABGiryG7_z_6jHdVik/pub1.LVM snapshots are by default only taken once every 24 hours. YP happened to run one manually about 6 hours prior to the outage这是唯一能用的备份,每24小时执行一次,上一次是6小时前.2.Regular backups seem to also only be taken once per 24 hours, though YP has not yet been able to figure out where they are stored. According to JN these don’t appear to be working, producing files only a few bytes in size.这个也是24小时一次的备份,不过首先找不到它在哪.等找到了发现备份是空的3.Disk snapshots in Azure are enabled for the NFS server, but not for the DB servers.Azure 的备份没给数据库服务器用4.The synchronisation process removes webhooks once it has synchronised data to staging.同步进程在一次同步完成后就把 webhooks 删了5.The replication procedure is super fragile, prone to error, relies on a handful of random shell scripts, and is badly documented这个备份是依赖一些混乱的脚本,很容易出错,而且没文档23336.Our backups to S3 apparently don’t work either: the bucket is emptyS3 备份是空的2333看得我都要笑死了,备份从来没人管吧233.然后直播复制备份,速度只有6MiB/s.好在 gitlab 只有 310 GiB 的数据.总之现在直播给出的 ETA 还有至少 5 小时吧.欢迎围观史上第一次 YouTube 直播欢乐地恢复数据 12415 条评论分享收藏感谢收起&&&&&&&&&&&
原来一直在网站上写Wiki文档, 最近手欠误删一篇文档, 想要恢复文档时才发现原来gitlab的Wiki是用git管理的从此再也不用为误删担心了
mac系统安装gollum
brew install gollum
选择一个目录克隆wiki
在gitlab网站wiki/Git Access页面内找项目连接地址
git clone git @git.xxxxxxx.org:xxxx/name.wiki.git
cd name.wiki
git查看项目日志
回退版本, 找到相应的版本哈希复制下来
git reset --hard 哈希值
最后将修改push到服务器上就ok了.从此以后可以和代码一样在本地写wiki后再推到服务器了
阅读(...) 评论()匿名用户不能发表回复！|
每天回帖即可获得10分可用分！小技巧：
你还可以输入10000个字符
(Ctrl+Enter)
请遵守CSDN，不得违反国家法律法规。
转载文章请注明出自“CSDN（www.csdn.net）”。如是商业用途请联系原作者。}