IT系统备份如何执行

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