GitLab误删生产数据库，会导致什么结果？

可以请数据恢复公司恢复数据，300G数据量不会有多大，不过这个服务器对应的客户们会造成暂时或者永久性的损失，那就是数据公司无法恢复这个服务器硬盘上的全部数据，而且以后的负面影响是深远的，这就是服务器的防火墙问题。

对于服务器的防火墙，如果是专业的客户服务对象，不能只能指望第三方商业免费杀毒软件发现，我们都知道，电脑中了那些关键病毒，杀毒软件是无能为力的，必须人工时刻注意监控网络中的异常现象才是最佳选择，然后加上第三方服务器专业软件尽可能的避免出现问题。

杀毒软件防火墙和黑客之间就是矛与盾的关系，这就是问题所在

谢谢邀请回答。

这方面有位朋友曾回答过，我分享下。

俗话说，出来混早晚要还的。俗话又说，常在河边走，早晚要湿鞋。俗话还说，好了伤疤忘了疼。

好多人喜欢追捧小公司那套：全栈、devops[1]啥的。七八年前，有个人来我们组，过了一阵子他觉得不爽，他说：他们以前在某某某地方都可以自己直接进production环境去改东西的，为什么在微软这里管的那么死？我们那时候数据库操作只有dba有权限，我们那些做开发的只有读权限。要在db里面改东西，要写好步骤或脚本、给dba开一个ticket去做的。我们当时甚至连读权限都没有的，因为要防止有人写很愚蠢的query把表给锁了。我们当时都是去读replica的。小公司没这些限制这些分工，的确很爽啊，但记住，出来混迟早是要还的。当然，一百个这样的公司里也许只有两三个会遇到删库级别的大事故，剩下九十几个几年下来都安然无恙。这叫survivor's bias。大公司为什么成本高、动作慢？就因为有这些东西拖累。你想，如果gmail或者onedrive一下丢了好多邮件而且恢复不出来了，会怎么样？整个公司也许就从此声誉扫地了。我在Azure，Azure里面在安全和灾备上花的力气海了去了。

有人说到要做备份，要有灾备方案，要演习。但这次gitlab发现备份也是坏的。怎么判断备份是不是好的，这其实是一个哲学上（或者方法论上）的困境：你刻了一张盘，不可以播放，但是要确保有朝一日需要播放的时候可以放。这有点像家里的灭火器：你要确保灭火器可以用，但是又不能用，因为一只灭火器一用，就没用了。有人说，你可以找一个测试环境，把备份恢复出来看看。我跟他们说：你可以这样做，但是你没法确保备份里面的每一条数据都是对的。你就算能验证备份里面99%的数据是好的，但是万一剩下1%里面有data corruption，也许到时候就是致命的：可能你的code没法handle那种corruption，导致你的code就崩了。搞到最后，能用的也就是做做diff、弄个hash啥的。但是还是没有根本性的解决这个方法论上的困境。

大公司里面那些做备份、disaster recovery的活其实不怎么受待见，因为做的东西说不定好多好多年才用到一次。等用到了，说不定做的人都已经走掉了。而且，到底好用不好用也不知道，再怎么演习也还是不能百分之百的确信。备份（跟容灾不一样）这事儿跟最近的Survivalist那档子事有点像，都是很奢侈的一件事情，只有财大气粗的人（公司）才搞得起。

--

[1] 别误会我的意思，现在微软里面也比以前敏捷很多，dev会干很多devops的事情，很多以前一季度上线一次的组现在都改进到每周上线甚至每天上线了。

不用我说，大家都知道会对厂家有多大的损失！数据上有生产的产量和批量发货数量，，，，，，，误删了会道致数据库的问题严重性！

GitLab 是一个用于仓库管理系统的开源项目。使用Git作为代码管理工具，并在此基础上搭建起来的web服务其特点是Web框架使用Ruby on Rails。基于MIT代码发布协议，需要gitolite协同工作。所以产生如此情况关键在于误删时间前的几小时的数掘库备份时间中进行恢复!至于是几小时?就要看备份机制了!至于导致的结果要看库的类型，如果是运动过程中的生产环境数据库是不可能被恢复的。时点机制是断片数据，不是过程数据，而整个运行运型数据进行备份工作，即宕机运行记录，想起都复杂!哇!怎幺搞?

亲.你为我做了很多.负出了你所有的心血.我想跟说.如果一个人的精力不充足..她还有什么资格去谈感情.你知道吗？一个人如果爱一个人她会想把最好的自己给对方.如果给不了对方幸福.那就选择放手.

谢谢邀请。但是很抱歉，我不了解你说的那个问题，因此给不了你有效的建议。抱歉！