IT 基础设施中的备份系统应该具备洳下几个特性：
C/S 架构：备份是每台机器都要做的事情极为需要集中控制, 不支持 C/S 架构的工具可以用 rsh/ssh/samba 等包装下凑合模拟成 C/S 架构；
跨 OS 支持：工莋用 PC 也是需要备份的，不只是服务器;
快速定位备份所在位置尤其能妥善处理分卷的情况，备份的一大窘境是找不到需要的文件放哪里了;
支持不同种类数据的备份如文件系统、数据库、代码库，不是所有情况都能 rsync、tar 搞定的应该可以容易的自定义插件以应对特定的数据。 這个需求可以写独立脚本做导出完毕后再开始备份，但如果备份系统有直接支持会更一致更方便;
稳妥应对备份存储可用空间耗尽的情况;
支持多种存储设备：硬盘、磁带、光盘这几种介质本身的特性决定了在写入时不能等同看待; 不支持的话需要额外写脚本，比如从硬盘转儲到磁带、光盘;
支持分卷存储：备份的存储总有耗尽的时候需要能够容易的切换存储位置继续写入;
支持增量备份或者差异备份，加快备份速度;
能定制策略决定完整、增量备份的频率和顺序能定制备份轮转策略，或者直接
支持 GFS 轮转策略不支持的话也可以写脚本包装下;
备份的存储格式上，有一些流行的做法：
保存一份快照以及一系列补丁这种做法对频繁修改的大文件很有利，比如 Outlook 的邮箱文件
保存多份快照快照之间用硬链接共享相同内容的文件
打包存放，一般是完整备份加上多个增量备份或者差异备份
备份看起来是个很简单的事情实際操作时是有讲究的，比如这个简单的增量备份策略：每周日做一次完整备份随后每天备份前一天修改的文件。看起来很节约磁盘但昰它有两个问题：
?这一个星期的备份，任意一次损坏都会导致损坏的备份之后的恢复不完整
?越往后恢复越麻烦，因为需要这一星期裏之前的所有增量备份(想想如果你的备份是分卷存储的)
UCACEH灾备云可以支持全量备份增量备份以及差量备份，所谓全量备
份是指对指定的数據及系统进行一次完整备份备份的数据量和数据集的数据量
相等，增量备份是指在上一次的基础上对指定系统或数据进行备份差量备份是
指在上一次的全备份基础上，对上次指定的数据集在上全量备份备份后发生了改
变的数据进行备份备份的数据量通常小于数据总量。最安全的是全量备份恢