过年期间不太平,发生了gitlab数据库事故,这次事故导致了GitLab服务长时间中断。严重的是还永久损失了部分生产数据,无法恢复。而gitlab号称有五重数据备份,结果依旧悲剧发生了,事后大家都调侃说“运维工程师从入门到跑路”。调侃归调侃,其实通过这次事故,我们也需要反思自己,企业需要更加重视和正视“容灾”这个问题。

运维是否牛逼,服务器是否稳定,不能只单纯根据这一年是否发生过服务器灾难而断定,一切都说不准的。需要有敬畏之心,踏踏实实并且细心地测试,需要经常进行实际模拟。比如,每隔一段时间进行一次主备切换,增加数据校验机制确保备份健全等。同样增加多维度备份防护也是必不可少,这样也能保证某一个备份途径失效,尝试另外一种途径,用冗余换稳定。

只是,gitlab比较悲剧,多重保护并没有预期那样起到作用,归根结底:


运维离不开实战操作,稳定不能凭空想象。

具体新闻,可以搜索“gitlab 误删300G数据”,这里不做过多展开。

那么对于个人,特别是我这种普通用户的服务器,一旦哪天云厂商出问题了,说云服务器数据彻底丢失。和企业级比起来肯定损失不大,但是对于我个人而言,还是损失很大的,毕竟数据就都找不回来了。

以blog为例子,都有哪些备份呢?
1. 我用的是阿里云,阿里云本身每天定时镜像备份。
2. 为了防止数据丢失,特意购买付费rds进行数据存储。
3. rds也做了每天的固定备份。
4. 文件远程github备份。

前三点,阿里本身就帮助做了,第四点是我额外做的。如果阿里云真的不靠谱(很正常,gitlab的亚马逊镜像也不是想象中那么好用)的时候,至少自己的备份也能派上用场。而且个人blog啥的,也不需要第一时间恢复,要求不高,手动慢慢恢复就好了,只要数据不丢失就行,所以我选择了github存储副本。

大致思路很简单:
1. 服务器文件做git。
2. 定时跑脚本,对服务器所有改动进行git提交。
3. 将服务器文件推送到远端github。

这样,所有内容都会定时推送到github上面,作为一个特殊备份,这样也更放心一些。

具体做法很简单。

1. 建立服务器和github的ssh认证
创建SSH Key,在用户主目录下,执行ssh-keygen -t rsa命令。
会在.ssh目录中生成id_rsa和id_rsa.pub这两个文件。
登陆GitHub,在settings的SSH key中,添加id_rsa.pub文件内容。

2. 创建github空项目,初始化服务器git。
在github网站创建一个空项目,比如名字为blog_bak。
在服务器目录下
git init初始化git
vi .git/info/exclude 增加你想要忽略的文件,如wp-config.php

3. 关联服务器和github
git remote add origin git@github.com:name/blog_bak.git

4. 自动化定期提交
vi git_push.sh
cd /website/dir
git add --all && git commit -m 'add' && git push origin master

crontab -e
30 * * * * /website/github_push.sh > /dev/null 2>&1

至此,一重额外保护就生效了。