 |
1
ansheng Feb 1, 2017
占坑，还好我没用。
|
 |
2
PythonAnswer Feb 1, 2017 via iPad
可怜。。
|
 |
3
ic3z Feb 1, 2017 via Android  8
这要换国内，肯定是正在升级系统。或者与其听信谣言，不如 xx
|
 |
4
loading Feb 1, 2017 via Android
怎么搞得数据比自己建还不靠谱……
|
 |
5
d7101120120 Feb 1, 2017 via Android 3
楼上上 6666666 这种事都要黑一下国内
|
 |
6
mhycy Feb 1, 2017
................GITLAB 这种重要数据库都没备份？！
|
 |
7
Technetiumer Feb 1, 2017
成功让我下决心接受 github 和 bitbucket 那种极丑的 UI
|
 |
8
czc2004211 Feb 1, 2017 via iPhone
国内公司也不会连备份都搞不定呀
|
 |
9
andyfan OP 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 Feb 1, 2017 via Android
这是要倒闭的节奏吧。。。
|
 |
11
Cavolo Feb 1, 2017 via iPhone
@czc2004211 炉石传说刚刚归档呢
|
 |
12
Gitizen Feb 1, 2017
好像前天才登录看以前放在 GitLab 的 repo ，现在看到数据库被删这消息有点惊讶。 GitLab 还招 Community writer ，这么不稳定，恐怕很少人会给 GitLab 写文章了
|
|
13
Technetiumer Feb 1, 2017
这说明了多个远程仓库的重要性，还好有同步到 bitbucket
|
 |
15
ETiV Feb 1, 2017 via iPhone
这回真的可以跑路了
|
|
16
czc2004211 Feb 1, 2017 via iPhone
@Cavolo 希望多坏档 25 包不过瘾
|
 |
17
gamexg Feb 1, 2017 1
5 个自动备份全挂了...
还好操作前做了次快照，不然麻烦更大。 |
 |
18
davidyin Feb 1, 2017
下了 gitlab CE 版，装在自己的电脑上用，似乎比他们更安全。
|
 |
19
MinonHeart Feb 1, 2017 via iPhone 1
@Technetiumer 觉得 GitHub 的 ui 挺好看的
|
 |
20
RyuZheng Feb 1, 2017 via Android
从删库到跑路吗
|
 |
21
hundan Feb 1, 2017 via Android
这运维要完
|
 |
22
ZE3kr Feb 1, 2017 via iPhone
|
 |
23
iAcn Feb 1, 2017 via Android
GitLab 从删库到跑路～
|
 |
24
tywtyw2002 Feb 1, 2017 1
其实这个很常见，备份永远都不会有人管，除非要用的时候。
部门和部门之前的沟通有的时候也是有问题，一拨人负责写备份，一拨人负责升级环境，这样就出现了升级了数据库，但是备份脚本用的还是老的 binary 。 所以要 DevOps 啊，要阶段性的根据当前服务扩张情况重构运维流程，包括备份仓库，自动化脚本等一些东西。在一定时期， 3 年为周期（服务器寿命），进行数据迁移是必须要。 举个简单的例子，之前接触到的一个开发环境，最开始只有单一的数据服务器在 local 存储数据，/home/tools 为开发工具链，备份就是 crontab 运行一个脚本。 后来数据爆炸，为了快速上线，用 nfs 挂载新的存储服目录在老的目录内，如 server:/port/testing /home/tools/testing 。某天当 nfs 出现了问题， testing 数据全部丢失，又因为备份脚本连续 200 天都没有报错，大家信心满满的去备份目录下面找数据，结果只看见一个空空的文件夹。 大家猜猜原因是什么，为什么整整一 nfs 的数据，只备份了一个空白目录呢。 |
 |
25
ipeony Feb 1, 2017 via Android
保持关注，快吓得不敢用 gitlab 了(⊙o⊙)
|
 |
26
nG29DOMuRYTWfcSr Feb 1, 2017 via Android
有 github 不用，你们范抽吗？
|
 |
27
sox Feb 1, 2017 via Android
楼上一片没看原文的吗， repo 和 wiki 的数据没丢
|
 |
29
smallpath Feb 1, 2017
突然想起个类似的事情，同事有回删 fork 仓库删错了，删成了主仓库，鸡飞狗跳翻了好几个人的电脑最后发现我机器上面居然有最新的提交（那段时间我没这仓库的需求，好像是闲着蛋疼 fork 了一下），最后复原，然后我们一大堆人就为原仓库丢掉的 commit （主要是 pr ）心痛
|
 |
30
uxstone Feb 1, 2017
单点都是不可靠的..
|
 |
32
HLT Feb 1, 2017
我去。。。
|
 |
33
WendellSun Feb 1, 2017 via Android
可以跑路了。
|
 |
34
JoshOY Feb 1, 2017
心疼，我司上周刚从自己搭的 gitlab 迁移到 gitlab.com [捂脸]
|
 |
35
Halry Feb 1, 2017
东西不丢就好，正想说上不去
|
 |
37
hitrust Feb 1, 2017
没有那么严重。 The incident affected the database (including issues and merge requests) but not the git repo's (repositories and wikis).
|
 |
39
momocraft Feb 1, 2017
丢了 issue 可能比丢了 repo 还要惨，各开发者本地也有 repo 的
|
 |
40
corona Feb 1, 2017 via iPhone
这么多数据没了，真是要倒闭的节奏了
|
 |
41
Reficul Feb 1, 2017 via Android
@tywtyw2002 备份的一直是被 mount 遮盖住的那个老文件夹？
|
 |
42
kamikat Feb 1, 2017
年后不用上班了。
|
 |
43
jasontse Feb 1, 2017 via iPad
备份出包这种事自己也经历过。每天运行的自动化备份，到用的时候发现最新的已经是几个月前。你猜为啥，因为用来备份的空间满了。不过损失不大，就一小博客几篇文章可以通过 Archive.org 来恢复。
|
 |
44
wanghanlin Feb 1, 2017 2
gitlab 正直播呢
|
 |
45
misaka19000 Feb 1, 2017
@wanghanlin 。。。这也能直播
|
 |
46
sorra Feb 1, 2017
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 Feb 1, 2017
@misaka19000 吃瓜群众聊天大会
|
|
48
smallpath Feb 1, 2017 3
@wanghanlin 为了拯救被删库的 gitlab ，三名码农决定站出来......成为偶像！
|
 |
49
Rand01ph Feb 1, 2017 via iPhone
@tywtyw2002 权限问题？
|
 |
50
ershiwo Feb 1, 2017
@misaka19000 闲着没事干的人聚在一起陪他们发呆。
然后到 99% 的时候 I/O error 。 |
 |
52
shijingshijing Feb 1, 2017
一直不明白为什么要把代码放到别人控制之下，最理想的难道不应该是自己做 RAID1 服务器存放，然后有选择的开放，上传到网上么？当然 Open Source 的话， github 真真是极好的。
|
|
53
Technetiumer Feb 1, 2017
@shijingshijing 需要协作，但没钱自建 gitlab 或懒得自建 gitlab
|
|
54
shijingshijing Feb 1, 2017
@Technetiumer 现在电脑配件价格都这么便宜，自己攒一台也花不了多少钱啊。可能苦逼学生党受制约比较多吧，宿舍不能放个 24 小时开机的服务器什么的。其实电脑里面最容易挂的是硬盘，好在硬盘价格也不贵了。
|
 |
55
20150517 Feb 1, 2017 via iPhone
有啥关系，应该大家本地都有 git
重新建 remote. push 上去就是了，代码丢不了 |
 |
56
66450146 Feb 1, 2017
@shijingshijing 码农很贵的，折腾一星期就值好几千块
|
|
57
Technetiumer Feb 1, 2017
|
 |
58
woyaojizhu8 Feb 1, 2017
@shijingshijing 多数人家里都放不了 24 小时开机的服务器吧，噪音影响睡眠
|
 |
59
Duolingo Feb 1, 2017 via iPhone
很多人因为各种原因并没有个人服务器的条件和需求啊……
何不食肉糜？讲的就是这个 |
 |
60
RqPS6rhmP3Nyn3Tm Feb 1, 2017 via iPhone 1
@ic3z 折要换国内，你又要说你看只有国内会搞这种幺蛾子，国外 gitlab 这种大厂肯定没问题
|
 |
61
alonezero Feb 2, 2017
备份和上次炉石事故一样，也全抽风了（ GitLab 好像剩了一个）。对了，恢复过程正在在线直播， Youtube 看不了的~可以去 B 站看转播。
|
 |
62
msg7086 Feb 2, 2017 2
@shijingshijing 说得好像 gitlab 上没有 RAID 一样。
你要说自己公司里有专门一个运维团队的，搞本地 Gitlab 我还能接受。 一个学生党你自己有闲心有技术做运维？我觉得#滑稽。 |
 |
63
ryan93 Feb 2, 2017
RAID 应该防止不了人为 rm 删除操作吧？不过如果 rm 了一个文件，若没有写入新数据，原有的文件应该可以恢复吧？
|
|
64
shijingshijing Feb 2, 2017
@msg7086 所以说学生党你当我没说啊，我看 v2 上大把顶配 MacBook Pro ，自己弄个 NAS 和家庭服务器也没啥问题吧，反正我自己有个 24 小时开机的低电压 Xeon 当爬虫顺便 Gitlab
|
|
65
msg7086 Feb 2, 2017
@shijingshijing 买硬件的钱通常不是问题。问题在于维护团队。
你会像 Gitlab 团队那样花六七个小时去做灾难恢复么。 你会做数据库全球 replication 么（而且不能学 gitlab ，要经常做灾备演练等等 反正对于我们小公司来说，用第三方托管然后出问题让别人背锅，总比自己配一套挂了以后自己背锅要好。 |
|
66
shijingshijing Feb 2, 2017
@msg7086 关键是国内算是比较好的 aliyun 也一样有不靠谱的时候啊，反正我觉得这个事情，如果我是老板，自己的东西肯定是要本地做个数据仓库的，即使是 HP 和 Dell 的小型塔式服务器，也不贵，反正这个钱是不该省的。不过一般员工的话，必然是多一事不如少一事，出了问题能甩锅就行。
|
 |
67
likuku Feb 2, 2017
没有定期有效还原演练检验的备份都是耍流氓，再多的无效 /未经恢复演练检验的备份那是没卵用。
|
|
68
likuku Feb 2, 2017
所以全托管的 RDS 啊，某些先进云商的 RDS 服务，有自动化快照备份，可以“一个指令恢复到五分钟前的状态”
|
 |
69
Showfom PRO 我们一般一年迁移一次整体环境
|
|
70
msg7086 Feb 2, 2017
|
 |
71
cxbig Feb 2, 2017
又不是 SVN 。。。
用 Git 有啥好怕的，任何一个人保留最新版本，随时都可以恢复工作。 |
|
72
tywtyw2002 Feb 2, 2017 via iPhone
|
 |
73
kitalphaj Feb 2, 2017
仅仅是 issue 和 merge requests 被删掉了吧。 gitlab 最值得表扬的是在这件事情上的透明度，人家第一时间就发推特说因为误删了 production 的数据，而且后面也用 google docs 还有 youtube 直播这件事情。至少诚意在。。。虽然没有测试 backup 也是犯了大错
|
 |
74
incompatible Feb 2, 2017 via iPhone
@shijingshijing 你这完全就是野路子。想要保证 HA 至少要在 2 个异地数据中心有 3 个副本。就算使用 AWS 或者 Aliyun ，最佳的实践也是在不同的 Available Zone 购买 instance 组建集群。
大多数人在自家搭单机 server 24 小时跑不出问题不代表你也不会出问题，因为任何事情第一次发生前，它都是史无前例的。 |
Select Language