过年期间不太平，发生了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

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