V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
andyfan
V2EX  ›  GitLab

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

  •  
  •   andyfan · 2017-02-01 12:57:56 +08:00 · 12703 次点击
    这是一个创建于 2612 天前的主题,其中的信息可能已经有所发展或是发生改变。
    据说运维以为自己操作的是从服务器, 300G 的数据删剩下 4G 才发现删的是主服务器.
    http://gitlab.com
    官方给出的事故详情 https://docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCxIABGiryG7_z_6jHdVik/pub
    74 条回复    2017-02-02 09:17:11 +08:00
    ansheng
        1
    ansheng  
       2017-02-01 13:01:12 +08:00
    占坑,还好我没用。
    PythonAnswer
        2
    PythonAnswer  
       2017-02-01 13:08:17 +08:00 via iPad
    可怜。。
    ic3z
        3
    ic3z  
       2017-02-01 13:12:48 +08:00 via Android   ❤️ 8
    这要换国内,肯定是正在升级系统。或者与其听信谣言,不如 xx
    loading
        4
    loading  
       2017-02-01 13:13:51 +08:00 via Android
    怎么搞得数据比自己建还不靠谱……
    d7101120120
        5
    d7101120120  
       2017-02-01 13:14:41 +08:00 via Android   ❤️ 3
    楼上上 6666666 这种事都要黑一下国内
    mhycy
        6
    mhycy  
       2017-02-01 13:18:30 +08:00
    ................GITLAB 这种重要数据库都没备份?!
    Technetiumer
        7
    Technetiumer  
       2017-02-01 13:22:22 +08:00
    成功让我下决心接受 github 和 bitbucket 那种极丑的 UI
    czc2004211
        8
    czc2004211  
       2017-02-01 13:25:18 +08:00 via iPhone
    国内公司也不会连备份都搞不定呀
    andyfan
        9
    andyfan  
    OP
       2017-02-01 13:28:53 +08:00
    Problems Encountered
    LVM snapshots are by default only taken once every 24 hours. YP happened to run one manually about 6 hours prior to the outage
    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.
    SH: It looks like pg_dump may be failing because PostgreSQL 9.2 binaries are being run instead of 9.6 binaries. This happens because omnibus only uses Pg 9.6 if data/PG_VERSION is set to 9.6, but on workers this file does not exist. As a result it defaults to 9.2, failing silently. No SQL dumps were made as a result. Fog gem may have cleaned out older backups.
    Disk snapshots in Azure are enabled for the NFS server, but not for the DB servers.
    The synchronisation process removes webhooks once it has synchronised data to staging. Unless we can pull these from a regular backup from the past 24 hours they will be lost
    The replication procedure is super fragile, prone to error, relies on a handful of random shell scripts, and is badly documented
    Our backups to S3 apparently don ’ t work either: the bucket is empty

    官方公告提供的信息, 六个备份服务器五个不工作, 说明了定期灾演的重要性啊
    lll9p
        10
    lll9p  
       2017-02-01 13:30:01 +08:00 via Android
    这是要倒闭的节奏吧。。。
    Cavolo
        11
    Cavolo  
       2017-02-01 13:30:52 +08:00 via iPhone
    @czc2004211 炉石传说刚刚归档呢
    Gitizen
        12
    Gitizen  
       2017-02-01 13:36:23 +08:00
    好像前天才登录看以前放在 GitLab 的 repo ,现在看到数据库被删这消息有点惊讶。 GitLab 还招 Community writer ,这么不稳定,恐怕很少人会给 GitLab 写文章了
    Technetiumer
        13
    Technetiumer  
       2017-02-01 13:37:59 +08:00
    这说明了多个远程仓库的重要性,还好有同步到 bitbucket
    DaCong
        14
    DaCong  
       2017-02-01 13:38:59 +08:00 via Android
    @ic3z 那家公司应该不是没备份的问题吧,不是被喝茶了吗?
    ETiV
        15
    ETiV  
       2017-02-01 13:39:10 +08:00 via iPhone
    这回真的可以跑路了
    czc2004211
        16
    czc2004211  
       2017-02-01 13:52:44 +08:00 via iPhone
    @Cavolo 希望多坏档 25 包不过瘾
    gamexg
        17
    gamexg  
       2017-02-01 13:53:55 +08:00   ❤️ 1
    5 个自动备份全挂了...
    还好操作前做了次快照,不然麻烦更大。
    davidyin
        18
    davidyin  
       2017-02-01 14:18:50 +08:00
    下了 gitlab CE 版,装在自己的电脑上用,似乎比他们更安全。
    MinonHeart
        19
    MinonHeart  
       2017-02-01 14:23:58 +08:00 via iPhone   ❤️ 1
    @Technetiumer 觉得 GitHub 的 ui 挺好看的
    RyuZheng
        20
    RyuZheng  
       2017-02-01 14:28:52 +08:00 via Android
    从删库到跑路吗
    hundan
        21
    hundan  
       2017-02-01 14:37:04 +08:00 via Android
    这运维要完
    ZE3kr
        22
    ZE3kr  
       2017-02-01 14:38:11 +08:00 via iPhone
    iAcn
        23
    iAcn  
       2017-02-01 14:44:53 +08:00 via Android
    GitLab 从删库到跑路~
    tywtyw2002
        24
    tywtyw2002  
       2017-02-01 14:47:36 +08:00   ❤️ 1
    其实这个很常见,备份永远都不会有人管,除非要用的时候。

    部门和部门之前的沟通有的时候也是有问题,一拨人负责写备份,一拨人负责升级环境,这样就出现了升级了数据库,但是备份脚本用的还是老的 binary 。

    所以要 DevOps 啊,要阶段性的根据当前服务扩张情况重构运维流程,包括备份仓库,自动化脚本等一些东西。在一定时期, 3 年为周期(服务器寿命),进行数据迁移是必须要。


    举个简单的例子,之前接触到的一个开发环境,最开始只有单一的数据服务器在 local 存储数据,/home/tools 为开发工具链,备份就是 crontab 运行一个脚本。
    后来数据爆炸,为了快速上线,用 nfs 挂载新的存储服目录在老的目录内,如 server:/port/testing /home/tools/testing 。某天当 nfs 出现了问题, testing 数据全部丢失,又因为备份脚本连续 200 天都没有报错,大家信心满满的去备份目录下面找数据,结果只看见一个空空的文件夹。

    大家猜猜原因是什么,为什么整整一 nfs 的数据,只备份了一个空白目录呢。
    ipeony
        25
    ipeony  
       2017-02-01 14:48:25 +08:00 via Android
    保持关注,快吓得不敢用 gitlab 了(⊙o⊙)
    SpaceVim
        26
    SpaceVim  
       2017-02-01 14:59:20 +08:00 via Android
    有 github 不用,你们范抽吗?
    sox
        27
    sox  
       2017-02-01 14:59:43 +08:00 via Android
    楼上一片没看原文的吗, repo 和 wiki 的数据没丢
    smallpath
        28
    smallpath  
       2017-02-01 15:06:05 +08:00
    @sox repo 一般本地都有,但是丢掉的 issue 和 pr 本地可没得啊
    smallpath
        29
    smallpath  
       2017-02-01 15:09:55 +08:00
    突然想起个类似的事情,同事有回删 fork 仓库删错了,删成了主仓库,鸡飞狗跳翻了好几个人的电脑最后发现我机器上面居然有最新的提交(那段时间我没这仓库的需求,好像是闲着蛋疼 fork 了一下),最后复原,然后我们一大堆人就为原仓库丢掉的 commit (主要是 pr )心痛
    uxstone
        30
    uxstone  
       2017-02-01 15:10:15 +08:00
    单点都是不可靠的..
    sox
        31
    sox  
       2017-02-01 15:19:30 +08:00 via Android
    @smallpath 是啊
    HLT
        32
    HLT  
       2017-02-01 15:51:46 +08:00
    我去。。。
    WendellSun
        33
    WendellSun  
       2017-02-01 16:04:38 +08:00 via Android
    可以跑路了。
    JoshOY
        34
    JoshOY  
       2017-02-01 16:20:29 +08:00
    心疼,我司上周刚从自己搭的 gitlab 迁移到 gitlab.com [捂脸]
    Halry
        35
    Halry  
       2017-02-01 17:06:02 +08:00
    东西不丢就好,正想说上不去
    ck65
        36
    ck65  
       2017-02-01 17:11:53 +08:00 via iPhone
    @JoshOY 神了,这咋还反向迁移的。。
    hitrust
        37
    hitrust  
       2017-02-01 17:33:47 +08:00
    没有那么严重。 The incident affected the database (including issues and merge requests) but not the git repo's (repositories and wikis).
    JoshOY
        38
    JoshOY  
       2017-02-01 18:16:53 +08:00
    @ck65 其实几乎没有什么损失,之前撘的 gitlab 还能用而且上周基本没有新的 issues 和 pr
    momocraft
        39
    momocraft  
       2017-02-01 18:26:23 +08:00
    丢了 issue 可能比丢了 repo 还要惨,各开发者本地也有 repo 的
    corona
        40
    corona  
       2017-02-01 18:36:34 +08:00 via iPhone
    这么多数据没了,真是要倒闭的节奏了
    Reficul
        41
    Reficul  
       2017-02-01 18:44:41 +08:00 via Android
    @tywtyw2002 备份的一直是被 mount 遮盖住的那个老文件夹?
    kamikat
        42
    kamikat  
       2017-02-01 18:46:10 +08:00
    年后不用上班了。
    jasontse
        43
    jasontse  
       2017-02-01 18:58:44 +08:00 via iPad
    备份出包这种事自己也经历过。每天运行的自动化备份,到用的时候发现最新的已经是几个月前。你猜为啥,因为用来备份的空间满了。不过损失不大,就一小博客几篇文章可以通过 Archive.org 来恢复。
    wanghanlin
        44
    wanghanlin  
       2017-02-01 19:45:32 +08:00   ❤️ 2
    gitlab 正直播呢
    misaka19000
        45
    misaka19000  
       2017-02-01 20:00:39 +08:00
    @wanghanlin 。。。这也能直播
    sorra
        46
    sorra  
       2017-02-01 20:21:36 +08:00
    GitLab ​ We've lost about 6 hours of data of issues, merge requests, comments, etc. Pushed code will still be in the repositories, but you might have to recreate your MRs.

    丢失了 6 小时的 issues, merge requests, comments, etc.
    repo 没有丢失
    sorra
        47
    sorra  
       2017-02-01 20:21:57 +08:00
    @misaka19000 吃瓜群众聊天大会
    smallpath
        48
    smallpath  
       2017-02-01 20:26:56 +08:00   ❤️ 3
    @wanghanlin 为了拯救被删库的 gitlab ,三名码农决定站出来......成为偶像!
    Rand01ph
        49
    Rand01ph  
       2017-02-01 20:35:02 +08:00 via iPhone
    @tywtyw2002 权限问题?
    ershiwo
        50
    ershiwo  
       2017-02-01 20:35:21 +08:00
    @misaka19000 闲着没事干的人聚在一起陪他们发呆。
    然后到 99% 的时候 I/O error 。
    kokutou
        51
    kokutou  
       2017-02-01 20:59:11 +08:00 via Android
    @JoshOY 然后 gitlab 带了一波节奏 233
    shijingshijing
        52
    shijingshijing  
       2017-02-01 21:26:08 +08:00
    一直不明白为什么要把代码放到别人控制之下,最理想的难道不应该是自己做 RAID1 服务器存放,然后有选择的开放,上传到网上么?当然 Open Source 的话, github 真真是极好的。
    Technetiumer
        53
    Technetiumer  
       2017-02-01 21:35:34 +08:00
    @shijingshijing 需要协作,但没钱自建 gitlab 或懒得自建 gitlab
    shijingshijing
        54
    shijingshijing  
       2017-02-01 21:43:12 +08:00
    @Technetiumer 现在电脑配件价格都这么便宜,自己攒一台也花不了多少钱啊。可能苦逼学生党受制约比较多吧,宿舍不能放个 24 小时开机的服务器什么的。其实电脑里面最容易挂的是硬盘,好在硬盘价格也不贵了。
    20150517
        55
    20150517  
       2017-02-01 21:53:27 +08:00 via iPhone
    有啥关系,应该大家本地都有 git
    重新建 remote. push 上去就是了,代码丢不了
    66450146
        56
    66450146  
       2017-02-01 22:04:05 +08:00
    @shijingshijing 码农很贵的,折腾一星期就值好几千块
    Technetiumer
        57
    Technetiumer  
       2017-02-01 22:28:08 +08:00
    @shijingshijing 自己搞台服务器岂不是比租云服务器更折腾?而且硬盘易挂

    为什么要付费托管到 GitHub 呢?
    为了仓库挂了有人背锅 #滑稽
    woyaojizhu8
        58
    woyaojizhu8  
       2017-02-01 23:35:00 +08:00
    @shijingshijing 多数人家里都放不了 24 小时开机的服务器吧,噪音影响睡眠
    codingadog
        59
    codingadog  
       2017-02-01 23:38:22 +08:00 via iPhone
    很多人因为各种原因并没有个人服务器的条件和需求啊……

    何不食肉糜?讲的就是这个
    RqPS6rhmP3Nyn3Tm
        60
    RqPS6rhmP3Nyn3Tm  
       2017-02-01 23:39:48 +08:00 via iPhone   ❤️ 1
    @ic3z 折要换国内,你又要说你看只有国内会搞这种幺蛾子,国外 gitlab 这种大厂肯定没问题
    alonezero
        61
    alonezero  
       2017-02-02 00:25:01 +08:00
    备份和上次炉石事故一样,也全抽风了( GitLab 好像剩了一个)。对了,恢复过程正在在线直播, Youtube 看不了的~可以去 B 站看转播。
    msg7086
        62
    msg7086  
       2017-02-02 00:59:56 +08:00   ❤️ 2
    @shijingshijing 说得好像 gitlab 上没有 RAID 一样。
    你要说自己公司里有专门一个运维团队的,搞本地 Gitlab 我还能接受。
    一个学生党你自己有闲心有技术做运维?我觉得#滑稽。
    ryan93
        63
    ryan93  
       2017-02-02 01:35:18 +08:00
    RAID 应该防止不了人为 rm 删除操作吧?不过如果 rm 了一个文件,若没有写入新数据,原有的文件应该可以恢复吧?
    shijingshijing
        64
    shijingshijing  
       2017-02-02 01:36:54 +08:00
    @msg7086 所以说学生党你当我没说啊,我看 v2 上大把顶配 MacBook Pro ,自己弄个 NAS 和家庭服务器也没啥问题吧,反正我自己有个 24 小时开机的低电压 Xeon 当爬虫顺便 Gitlab
    msg7086
        65
    msg7086  
       2017-02-02 01:41:07 +08:00
    @shijingshijing 买硬件的钱通常不是问题。问题在于维护团队。
    你会像 Gitlab 团队那样花六七个小时去做灾难恢复么。
    你会做数据库全球 replication 么(而且不能学 gitlab ,要经常做灾备演练等等
    反正对于我们小公司来说,用第三方托管然后出问题让别人背锅,总比自己配一套挂了以后自己背锅要好。
    shijingshijing
        66
    shijingshijing  
       2017-02-02 02:36:29 +08:00
    @msg7086 关键是国内算是比较好的 aliyun 也一样有不靠谱的时候啊,反正我觉得这个事情,如果我是老板,自己的东西肯定是要本地做个数据仓库的,即使是 HP 和 Dell 的小型塔式服务器,也不贵,反正这个钱是不该省的。不过一般员工的话,必然是多一事不如少一事,出了问题能甩锅就行。
    likuku
        67
    likuku  
       2017-02-02 02:56:03 +08:00
    没有定期有效还原演练检验的备份都是耍流氓,再多的无效 /未经恢复演练检验的备份那是没卵用。
    likuku
        68
    likuku  
       2017-02-02 02:58:39 +08:00
    所以全托管的 RDS 啊,某些先进云商的 RDS 服务,有自动化快照备份,可以“一个指令恢复到五分钟前的状态”
    Showfom
        69
    Showfom  
       2017-02-02 03:34:42 +08:00 via iPhone
    我们一般一年迁移一次整体环境
    msg7086
        70
    msg7086  
       2017-02-02 04:11:26 +08:00
    @shijingshijing 我说了啊,硬件的钱又不贵。塔式也好机架式也好,一台机器区区几千刀。
    关键是维护成本。
    而且,有多少老板敢说自己的员工比大公司的专业团队更靠谱的……
    cxbig
        71
    cxbig  
       2017-02-02 05:37:32 +08:00
    又不是 SVN 。。。
    用 Git 有啥好怕的,任何一个人保留最新版本,随时都可以恢复工作。
    tywtyw2002
        72
    tywtyw2002  
       2017-02-02 05:43:40 +08:00 via iPhone
    @Reficul
    @Rand01ph

    脚本只会备分本地的数据,忽略任何的软链和远程 mount 。
    从 git comment 来看,有人特意修改的成这样,据说之前的脚本出现了备份 loop 。
    kitalphaj
        73
    kitalphaj  
       2017-02-02 07:54:39 +08:00
    仅仅是 issue 和 merge requests 被删掉了吧。 gitlab 最值得表扬的是在这件事情上的透明度,人家第一时间就发推特说因为误删了 production 的数据,而且后面也用 google docs 还有 youtube 直播这件事情。至少诚意在。。。虽然没有测试 backup 也是犯了大错
    incompatible
        74
    incompatible  
       2017-02-02 09:17:11 +08:00 via iPhone
    @shijingshijing 你这完全就是野路子。想要保证 HA 至少要在 2 个异地数据中心有 3 个副本。就算使用 AWS 或者 Aliyun ,最佳的实践也是在不同的 Available Zone 购买 instance 组建集群。
    大多数人在自家搭单机 server 24 小时跑不出问题不代表你也不会出问题,因为任何事情第一次发生前,它都是史无前例的。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   1198 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 30ms · UTC 18:13 · PVG 02:13 · LAX 11:13 · JFK 14:13
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.