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

没备份

gitlab

服务器

运维

74 条回复 • 2017-02-02 09:17:11 +08:00

1

ansheng

2017-02-01 13:01:12 +08:00

占坑，还好我没用。

2

PythonAnswer

2017-02-01 13:08:17 +08:00 via iPad

可怜。。

3

ic3z

2017-02-01 13:12:48 +08:00 via Android

8

这要换国内，肯定是正在升级系统。或者与其听信谣言，不如 xx

4

loading

2017-02-01 13:13:51 +08:00 via Android

怎么搞得数据比自己建还不靠谱……

5

d7101120120

2017-02-01 13:14:41 +08:00 via Android

3

楼上上 6666666 这种事都要黑一下国内

6

mhycy

2017-02-01 13:18:30 +08:00

................GITLAB 这种重要数据库都没备份？！

7

Technetiumer

2017-02-01 13:22:22 +08:00

成功让我下决心接受 github 和 bitbucket 那种极丑的 UI

8

czc2004211

2017-02-01 13:25:18 +08:00 via iPhone

国内公司也不会连备份都搞不定呀

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

官方公告提供的信息, 六个备份服务器五个不工作, 说明了定期灾演的重要性啊

10

lll9p

2017-02-01 13:30:01 +08:00 via Android

这是要倒闭的节奏吧。。。

11

Cavolo

2017-02-01 13:30:52 +08:00 via iPhone

@czc2004211 炉石传说刚刚归档呢

12

Gitizen

2017-02-01 13:36:23 +08:00

好像前天才登录看以前放在 GitLab 的 repo ，现在看到数据库被删这消息有点惊讶。 GitLab 还招 Community writer ，这么不稳定，恐怕很少人会给 GitLab 写文章了

13

Technetiumer

2017-02-01 13:37:59 +08:00

这说明了多个远程仓库的重要性，还好有同步到 bitbucket

14

DaCong

2017-02-01 13:38:59 +08:00 via Android

@ic3z 那家公司应该不是没备份的问题吧，不是被喝茶了吗？

15

ETiV

2017-02-01 13:39:10 +08:00 via iPhone

这回真的可以跑路了

16

czc2004211

2017-02-01 13:52:44 +08:00 via iPhone

@Cavolo 希望多坏档 25 包不过瘾

17

gamexg

2017-02-01 13:53:55 +08:00

1

5 个自动备份全挂了...
还好操作前做了次快照，不然麻烦更大。

18

davidyin

2017-02-01 14:18:50 +08:00

下了 gitlab CE 版，装在自己的电脑上用，似乎比他们更安全。

19

MinonHeart

2017-02-01 14:23:58 +08:00 via iPhone

1

@Technetiumer 觉得 GitHub 的 ui 挺好看的

20

RyuZheng

2017-02-01 14:28:52 +08:00 via Android

从删库到跑路吗

21

hundan

2017-02-01 14:37:04 +08:00 via Android

这运维要完

22

ZE3kr

2017-02-01 14:38:11 +08:00 via iPhone

https://www.v2ex.com/t/337572

23

iAcn

2017-02-01 14:44:53 +08:00 via Android

GitLab 从删库到跑路～

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 的数据，只备份了一个空白目录呢。

25

ipeony

2017-02-01 14:48:25 +08:00 via Android

保持关注，快吓得不敢用 gitlab 了(⊙o⊙)

26

nG29DOMuRYTWfcSr

2017-02-01 14:59:20 +08:00 via Android

有 github 不用，你们范抽吗？

27

sox

2017-02-01 14:59:43 +08:00 via Android

楼上一片没看原文的吗， repo 和 wiki 的数据没丢

28

smallpath

2017-02-01 15:06:05 +08:00

@sox repo 一般本地都有，但是丢掉的 issue 和 pr 本地可没得啊

29

smallpath

2017-02-01 15:09:55 +08:00

突然想起个类似的事情，同事有回删 fork 仓库删错了，删成了主仓库，鸡飞狗跳翻了好几个人的电脑最后发现我机器上面居然有最新的提交（那段时间我没这仓库的需求，好像是闲着蛋疼 fork 了一下），最后复原，然后我们一大堆人就为原仓库丢掉的 commit （主要是 pr ）心痛

30

uxstone

2017-02-01 15:10:15 +08:00

单点都是不可靠的..

31

sox

2017-02-01 15:19:30 +08:00 via Android

@smallpath 是啊

32

HLT

2017-02-01 15:51:46 +08:00

我去。。。

33

WendellSun

2017-02-01 16:04:38 +08:00 via Android

可以跑路了。

34

JoshOY

2017-02-01 16:20:29 +08:00

心疼，我司上周刚从自己搭的 gitlab 迁移到 gitlab.com [捂脸]

35

Halry

2017-02-01 17:06:02 +08:00

东西不丢就好，正想说上不去

36

ck65

2017-02-01 17:11:53 +08:00 via iPhone

@JoshOY 神了，这咋还反向迁移的。。

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).

38

JoshOY

2017-02-01 18:16:53 +08:00

@ck65 其实几乎没有什么损失，之前撘的 gitlab 还能用而且上周基本没有新的 issues 和 pr

39

momocraft

2017-02-01 18:26:23 +08:00

丢了 issue 可能比丢了 repo 还要惨，各开发者本地也有 repo 的

40

corona

2017-02-01 18:36:34 +08:00 via iPhone

这么多数据没了，真是要倒闭的节奏了

41

Reficul

2017-02-01 18:44:41 +08:00 via Android

@tywtyw2002 备份的一直是被 mount 遮盖住的那个老文件夹？

42

kamikat

2017-02-01 18:46:10 +08:00

年后不用上班了。

43

jasontse

2017-02-01 18:58:44 +08:00 via iPad

备份出包这种事自己也经历过。每天运行的自动化备份，到用的时候发现最新的已经是几个月前。你猜为啥，因为用来备份的空间满了。不过损失不大，就一小博客几篇文章可以通过 Archive.org 来恢复。

44

wanghanlin

2017-02-01 19:45:32 +08:00

2

gitlab 正直播呢

45

misaka19000

2017-02-01 20:00:39 +08:00

@wanghanlin 。。。这也能直播

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 没有丢失

47

sorra

2017-02-01 20:21:57 +08:00

@misaka19000 吃瓜群众聊天大会

48

smallpath

2017-02-01 20:26:56 +08:00

3

@wanghanlin 为了拯救被删库的 gitlab ，三名码农决定站出来......成为偶像！

49

Rand01ph

2017-02-01 20:35:02 +08:00 via iPhone

@tywtyw2002 权限问题？

50

ershiwo

2017-02-01 20:35:21 +08:00

@misaka19000 闲着没事干的人聚在一起陪他们发呆。
然后到 99% 的时候 I/O error 。

51

kokutou

2017-02-01 20:59:11 +08:00 via Android

@JoshOY 然后 gitlab 带了一波节奏 233

52

shijingshijing

2017-02-01 21:26:08 +08:00

一直不明白为什么要把代码放到别人控制之下，最理想的难道不应该是自己做 RAID1 服务器存放，然后有选择的开放，上传到网上么？当然 Open Source 的话， github 真真是极好的。

53

Technetiumer

2017-02-01 21:35:34 +08:00

@shijingshijing 需要协作，但没钱自建 gitlab 或懒得自建 gitlab

54

shijingshijing

2017-02-01 21:43:12 +08:00

@Technetiumer 现在电脑配件价格都这么便宜，自己攒一台也花不了多少钱啊。可能苦逼学生党受制约比较多吧，宿舍不能放个 24 小时开机的服务器什么的。其实电脑里面最容易挂的是硬盘，好在硬盘价格也不贵了。

55

20150517

2017-02-01 21:53:27 +08:00 via iPhone

有啥关系，应该大家本地都有 git
重新建 remote. push 上去就是了，代码丢不了

56

66450146

2017-02-01 22:04:05 +08:00

@shijingshijing 码农很贵的，折腾一星期就值好几千块

57

Technetiumer

2017-02-01 22:28:08 +08:00

@shijingshijing 自己搞台服务器岂不是比租云服务器更折腾？而且硬盘易挂

为什么要付费托管到 GitHub 呢？
为了仓库挂了有人背锅 #滑稽

58

woyaojizhu8

2017-02-01 23:35:00 +08:00

@shijingshijing 多数人家里都放不了 24 小时开机的服务器吧，噪音影响睡眠

59

codingadog

2017-02-01 23:38:22 +08:00 via iPhone

很多人因为各种原因并没有个人服务器的条件和需求啊……

何不食肉糜？讲的就是这个

60

RqPS6rhmP3Nyn3Tm

2017-02-01 23:39:48 +08:00 via iPhone

1

@ic3z 折要换国内，你又要说你看只有国内会搞这种幺蛾子，国外 gitlab 这种大厂肯定没问题

61

alonezero

2017-02-02 00:25:01 +08:00

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

62

msg7086

2017-02-02 00:59:56 +08:00

2

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

63

ryan93

2017-02-02 01:35:18 +08:00

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

64

shijingshijing

2017-02-02 01:36:54 +08:00

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

65

msg7086

2017-02-02 01:41:07 +08:00

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

66

shijingshijing

2017-02-02 02:36:29 +08:00

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

67

likuku

2017-02-02 02:56:03 +08:00

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

68

likuku

2017-02-02 02:58:39 +08:00

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

69

Showfom

2017-02-02 03:34:42 +08:00 via iPhone

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

70

msg7086

2017-02-02 04:11:26 +08:00

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

71

cxbig

2017-02-02 05:37:32 +08:00

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

72

tywtyw2002

2017-02-02 05:43:40 +08:00 via iPhone

@Reficul
@Rand01ph

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

73

kitalphaj

2017-02-02 07:54:39 +08:00

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

74

incompatible

2017-02-02 09:17:11 +08:00 via iPhone

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