另一篇肯定了 ZFS on Linux 已经足够稳定可投入生产使用的博文，供参考：

The State of ZFS on Linux · ClusterHQ : https://clusterhq.com/2014/09/11/state-zfs-on-linux/

因为 ZFS 自身的自动校验+纠错机制，没有 ECC 内存的话，最好不要用它。

半个月前看到的这篇文章讲的很好：
Will ZFS and non-ECC RAM kill your data? | JRS Systems: the blog : http://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-your-data/

@jarlyyn so,我也这么觉得 fuse 的 zfs 还不够可靠，所以当前维护的一台存储备份服务器就选的 freebsd 10.1 release 跑在 dell r520 上。

@fengxing 「优惠价」也不代表就是合法取得。

@luo362722353 与职位无关，仅仅是座位改变，当然也要征求所在座位的人的同意啊。

上个月实在无法忍受 fcitx 和其它一些“误伤大雅”但很影响体验的小毛病，重灌了 2009 年的 macbook 拿去作工作主力机，再无烦恼。

xubuntu 15.04 kernel 4.0 来工作(ThinkPad x230 6GRAM 500G 机械 HDD) 的路过...

夏天时无法忍受 xfce4 的缓慢，换成 openbox 来跑，立即轻快爽利。

硬盘故障率嘛...之前看到老外的一篇几乎每年更新的　主流硬盘品牌故障率统计表的可参考：

Hard Drive Reliability Update - Sep 2014 : https://www.backblaze.com/blog/hard-drive-reliability-update-september-2014/

@jarlyyn 「我们的美工们都习惯找我要某个时间点备份的文件了」

Adobe 在 CS3 里都自带了 SVN server 和 SVN client 呢... 意在给设计师推广使用版本控制系统。

ZFS 的成熟度，可靠性 /业内多年实际生产检验，功能丰富性，都不是目前的 Btrfs 能比较的。

zfs on linux 官网说是已经可以放心用于生产环境了。

巴特，我只有 ZFS on OpenSolaris 和 ZFS on FreeBSD 这两的小规模生产环境经验：安全可靠好用

Dell 的塔式服务器即可。

见到 Btrfs 就习惯性吐槽。。。真不怕坑了你所有文件么？

ECC 内存的话，直接上 ZFS 吧。

@l12ab 假案？小心妨碍公务罪。

vps 不差空间的话，那就分成很多小卷，再用 rsync 拖。

btsync 也可以试试。。假若可能通讯的话。

压缩了就不好用 rsync 了... rsync 适合大量小文件...

docker 就这样啊...制造镜像前，就要服务的软件都装好，镜像运行时进行的任何修改都只是在内存的虚拟文件系统里，重启 /关闭　镜像所起的容器后，所有运行时的修改都丢失。

当然，或者在运行时作完修改，像 1 楼那样， 作个 commit (和 git 一样的概念)，之后容器作的修改才会追加在初始版本之后。

dockr 的理念：所要运行的环境，最好是在镜像制作时就组建完毕，一旦生成镜像，发布出去，镜像所起的容器都不要再修改了，所有需要数据持久化的，请使用数据存储卷，或者制造下一个版本的镜像重新发布上线。

永远在左边，永远自动隐藏，追求最大化桌面空间，避免分散注意力。

右撇子，放左边最不容易误触发 dock ，仅此。

@paradoxs 开发也兼职不了运维，当然若只是使用成熟公共云解决方案，只是创建 /删除云端资源，加个监控什么，最多是个进阶用户，非常勉强可以算个“运维”，唬下外行可以。

@wuming0 dba 学习曲线陡，责任大，压力大。

10 年前 DBA 是很吃香的职业，不过最近几年国内 BAT 几乎都在作祛 IOE (IBM,Oracle,EMC )化，如今搞数据挖掘， bigData/ DT (数据技术)更吃香， IT 日渐式微。