rsync 提供三种使用模式，本地、ssh、rsync daemon
rsync [OPTION...] SRC... [DEST]拉：
rsync [OPTION...] [USER@]HOST::SRC... [DEST]推：
rsync [OPTION...] SRC... [USER@]HOST:DEST推：
rsync [OPTION...] [USER@]HOST::SRC... [DEST]
rsync [OPTION...] rsync://[USER@]HOST[:PORT]/SRC... [DEST]拉：
rsync [OPTION...] SRC... [USER@]HOST::DEST
rsync [OPTION...] SRC... rsync://[USER@]HOST[:PORT]/DEST仅使用一个SRC参数且没有DEST参数的用法时，将列出源文件而不是复制。
Rsync（remote synchronize）是一个远程数据同步工具，它可以将一个目录的文件快速地同步到另一个目录，还可以通过网络快速同步多台主机间的文件。rsync 使用所谓的“rsync算法”来使本地和远程两个主机之间的文件达到同步，这个算法只传送两个文件的不同部分，而不是每次都整份传送，因此速度相当快。
一般而言，rsync 是 C/S 模型的一个软件，它既是客户端程序也是服务端程序。也就是说 rsync 需要启动一个守护进程（daemon）来接收客户端的请求，默认监听在 TCP 873 端口。
rsync 也支持独立使用以及配合 SSH 通道来传输数据，下面会有几种用法的详细说明。
rsync 在同步文件时需要非常频繁的计算文件的校验码，因此 rsync 会占用一定的 CPU 资源。
如果不希望 Rsync 进行增量文件传输，则使用 --whole-file 参数显式指定为全量传输。
rsync 不适合对数据库文件进行实时同步
像数据库文件这样的大文件，且是频繁访问的文件，如果使用rsync实时同步，发送端要计算、比较的数据块校验码非常多，cpu会长期居高不下，从而影响数据库提供服务的性能。另一方面，接收端每次都要从巨大的basis file(一般提供服务的数据库文件至少都几十G)中复制大部分相同的数据块重组新文件，这几乎相当于直接 cp了一个文件，它一定无法扛住巨大的io压力，再好的机器也扛不住。
所以，对频繁改变的单个大文件只适合用rsync偶尔同步一次，也就是备份的功能，它不适合实时同步。像数据库文件，要实时同步应该使用数据库自带的replication功能。
由于rsync 是增量同步，所以对于接收端已经存在的和发送端相同的文件，发送端是不会发送的，这样就使得发送端和接收端都只需要处理少量的文件，由于文件小，所以无论是发送端的 CPU 还是接收端的 IO 都不是问题。
但是，rsync 的实时同步功能是借助工具来实现的，如 inotify+rsync，sersync，所以这些工具要设置合理，否则实时同步一样效率低下，不过这不是 rsync 导致的效率低，而是这些工具配置的问题。
Keepalived 是由 c 语言编写的一个路径选择软件，是 IPVS 的一个扩展性项目，为 IPVS 提供高可用性（故障转移）特性，它的高可用性是通过 VRRP 协议实现的，并实现了对负载均衡服务器池中的 real server 进行健康状态检测，当 real server 不可用时，自身实现了故障的隔离，这弥补了 IPVS 不能对 real server 服务器进行健康检测的不足，这也是 keepalived 运用最广泛的场景，当然 keepalived 不只限于实现 IPVS 的高可用。
Keepalived 是一个模块化设计的软件，其有多个组件共同组成，每个组件各司其职共同完成 Keepalived 的各项功能。
Checkers：对后端服务器节点（RS）进行健康状态监测和故障隔离，我们知道，LVS 本身是没有健康状态监测功能，keepalived 起初就是为 LVS 生成 IPVS 规则和增加健康状态检测功能而设计的。
VRRP Stack：这是 keepalived 实现 VRRP 功能的模块，VRRP 功能可以实现对前端调度器集群的故障切换(failover)。
SMTP：Checkers 和 VRRP Stack 都是对节点进行状态监测，不同的是监测前端调度器和监测后端RS，但是这两个模块都可以通过SMTP通知管理员故障信息的邮件。
System Call：Checkers 和 VRRP Stack 同样都可以调用系统内核功能完成故障隔离和故障切换。
IPVS wrapper：Checkers 通过监测后端 RS 的工作状态得出信息，IPVS wrapper 通过这些信息添加 IPVS 规则，内核中的 IPVS 则通过这些规则进行工作。
Netlink Reflector：在调度器发生故障切换的时候，该模块充当调用内核 NETLINK 的接口，完成虚拟 IP 的设置和切换。
Watch Dog：keepalived 的核心模块就是 Checkers 和 VRRP Stack，当这两个模块发生故障的时候怎么办呢，这时候 Watch Dog 就发生了作用，它是一个检测工具，周期性的去检测 Checkers 和 VRRP Stack 的运行状态，一旦 Checkers 和 VRRP Stack 发生故障，Watch Dog 就能够检测到并采取恢复措施（重启）。
之前在介绍 Linux 文件系统的文章中，有提过 ZFS、Btrfs文件系统中，有内置快照的功能，也有提到过其快照的由 CoW 机制实现的。那么这篇文章将带领大家了解快照的原理。
常见快照的类别有两类：
拷贝快照是通过镜像技术来实现的，即其同时会写两个磁盘，我们可以理解为磁盘整列技术中的 RAID1。
下面通过一张原理图来介绍全拷贝快照的实现原理。
文件系统似乎是内核中比较稳定的部分，多年来，人们一直使用 ext2/3，ext 文件系统以其卓越的稳定性成为了事实上的 Linux 标准文件系统。近年来 ext2/3 暴露出了一些扩展性问题，于是便催生了 ext4 。在 2008 年发布的 Linux2.6.19 内核中集成了 ext4 的 dev 版本。 2.6.28 内核发布时，ext4 结束了开发版，开始接受用户的使用。似乎 ext 就将成为 Linux 文件系统的代名词。然而当您阅读很多有关 ext4 的文章时，会发现都不约而同地提到了 btrfs，并认为 ext4 将是一个过渡的文件系统。 ext4 的作者 Theodore Tso 也盛赞 btrfs 并认为 btrfs 将成为下一代 Linux 标准文件系统。 Oracle，IBM， Intel 等厂商也对 btrfs 表现出了极大的关注，投入了资金和人力。为什么 btrfs 如此受人瞩目呢。这便是本文首先想探讨的问题。
Kevin Bowling[1] 有一篇介绍各种文件系统的文章，在他看来，ext2/3 等文件系统属于“古典时期”。文件系统的新时代是 2005 年由 Sun 公司的 ZFS 开创的。 ZFS 代表” last word in file system ”，意思是此后再也不需要开发其他的文件系统了。 ZFS 的确带来了很多崭新的观念，对文件系统来讲是一个划时代的作品。
如果您比较 btrfs 的特性，将会发现 btrfs 和 ZFS 非常类似。也许我们可以认为 btrfs 就是 Linux 社区对 ZFS 所作出的回应。从此往后在 Linux 中也终于有了一个可以和 ZFS 相媲美的文件系统。