Linux备份策略研究

世界上没有绝对安全的系统。如果想获得绝对安全的系统，只有不连接网络，不让管理员之外的人使用，刷卡管制人员进出，使用监视器监视录像，甚至于不 要开机。但是这是完全不切实际的，我们仅能寄望尽量让系统能在承担低风险的情况下工作，因为任何操作系统都不可能毫无漏洞。那么怎样才能让系统承担最低的 风险呢？回答因该是在保障系统尽量安全的基础上，做好各个系统上的数据备份工作。一旦系统遭受到毁灭性的打击，可将平时做好的备份数据及时恢复，这样才能 使被破坏的系统迅速恢复正常，以避免不必要的损失。
下面针对Linux操作系统上的数据备份方法发表一下自己的看法。

总的来说，在Linux操作系统中将备份分为两类：系统备份，实现对操作系统和应用程序的备份；用户备份，实现对用户文件的备份。在下面我们会看到，系统备份和用户备份是不同的。

系统备份就是对操作系统和应用程序的备份，进行系统备份的原因是尽量在系统崩溃以后能快速简单完全地恢复系统的运行。进行备份的最有效方法是仅仅备份那些对于系统崩溃后恢复所必需的数据。

Linux系统中很多重要的文件位于/etc目录之下，如：

上面这些重要的配置文件都需要定期的做备份。

不 同的系统可能有很多重要配置文件，可以看到/etc目录下的配置文件非常重要。当然，某些程序使用了其他目录下的一些文件，但是Linux的基本配置文件 绝大多数都位于/etc目录下。很多人曾经花费了好长时间才正确的配置了XF86Config文件，想到如果重新再做一遍，就很费时费力。再举个例子， /etc目录下的passwd文件，如果误操作，将此文件更改，或删除了，则整个系统用户无法正常登录，如果定期或及时的对其备份，遇到上面的情况后，就 可以非常快速的恢复。

如果修改了某个程序所使用的配置文件，一般不能将其搬移到其它的地方，因为程序通常在固定的地方寻找配置文件。因此记录对系统所做的修改也非常重要，无论所做的修改如何小，当系统崩溃时才能轻松的恢复系统。

用户备份不同于系统备份，因为用户的数据变动更加频繁一些。当备份用户数据时，只是为用户提供一个虚拟的安全网络空间，合理的放置最近用户数据文件的备份，当出现任何问题，例如，误删除某些文件或者硬盘发生故障时，用户可以恢复自己的数据。

用户备份应该比系统备份更加频繁，也许每天都需要进行备份，或使用cron程序自动定期运行某个程序的方法来备份数据。

不 管系统多么可靠，总会发生一些意想不到的事情，致使系统数据丢失。因此使用备份来保护数据不丢失是一种非常重要的手段，尤其在系统数据非常重要的时候。经 常进行数据备份能够减少偶然破坏造成的损失，保证系统能够从错误中恢复正常运行。备份不应该成为一个长时间痛苦的事情，但它是作为系统管理必不可少的工 作，在着手之前进行详细的考虑和计划是应该的。

在进行备份之前，首先要选择合适的备份策略，这将决定何时需要备份，以及出现故障时进行恢复的方式。通常使用的备份方式有三种：

完全备份： 每隔一定时间就对系统进行一次全面的备份，这样在备份间隔期间出现数据丢失等问题，可以使用上一次的备份数据恢复到前次备份时数据状况。这是最基本的备份 方式，但是每次都需要备份所有的数据，并且每次备份的工作量也很大，需要大量的备份介质，因此这种备份不能进行的太频繁，只能每隔一段较长时间才进行一次 完整的备份。但是这样一旦发生数据丢失，只能恢复到上次备份的数据，这期间内更新的数据就有可能丢失。

增量备份： 首先进行一次完全备份，然后每隔一个较短时间进行一次备份，但仅仅备份在这个期间更改的内容。当经过一个较长的时间后再重新进行一次完全备份，开始前面的 循环过程。由于只有每个备份周期进行一次完全备份，其他只进行更新数据的备份，因此工作量小，可以进行频繁的备份。例如以一个月为一个周期，一个月进行一 次完全备份，每天晚上0点进行这一天改变的数据备份。这样一旦发生数据丢失，首先恢复到前一个完全备份，然后按日期一个一个恢复每天的备份，就能恢复到前 一天的情况。这种备份方法比较经济。

累计备份：这种备份方法与增量备份相似，首先每月进行一次完全备 份，然后每天进行一次更新数据的备份。但不同在于，增量备份是备份该天更改的数据，而累计备份是备份从上次进行完全备份后更改的全部数据文件。一旦发生数 据丢失，可以使用前一个完全备份恢复到前一个月的状态，再使用前一个累计备份恢复到前一天的情况。这样做的缺点是每次做累计备份工作的任务比增量备份的工 作量要大，但好处在于，增量备份每天都备份，因此要保存数据备份数量太多，而累计备份则不然，只需保存一个完全备份和一个累计备份就可以恢复故障以前的状 态。另外在进行恢复工作时，增量备份要顺序进行多次备份的恢复，而累计备份只需两次恢复，因此它的恢复工作相对简单。

增量备份和累计备份 都能以比较经济的方式对系统进行备份，在这些不同的策略之间进行选择不但与系统数据更新的方式相关，也依赖于管理员的习惯。通常在系统数据更新不是太频繁 的话，可以选用更新备份的方式。但是如果系统数据更新太快，使每个备份周期后的几次累计备份的数据量相当大。这时候可以考虑增量备份或混用累计备份和增量 备份的方式，或者缩短备份周期。

在Linux系统中常用的备份命令通常有下面几种：

Linux的实用程序tar最初是为了制作磁带存档而设计的（把文件和目录复制到磁带中，然后从存档中提取或恢复文件），而现在的应用中可以把它用于任何设备，它是数据备份中最常用的命令之一。

下面具体介绍tar命令的使用方法：

v： 表示回显模式（Verbose），将产生一系列备份的文件列表

f： 指定使用的备份文件，它后面的参数为输出的备份文件名

t： 显示备份文件的内容

T： 后面跟随一个文件参数，指定从这个文件中读取要备份的各个文件的路径。如果不使用T参数，那么就需要一个参数，指明进行备份文件和目录的路径

Z： 使用压缩方式创建和解开备份文件，这是GNU的新版tar的功能，需要同时安装gzip。

上 面的命令将/etc下的所有文件打包成tar存档文件backup.tar。tar的第一个参数“cvf”，是tar的命令参数，“c”告诉tar创建一 个存档文件；“v”选项迫使tar采用冗长模式，即在存档时打印每个文件名；“f”选项告诉tar下一个参数backup.tar是创建的存档文件名。

下面一行的命令将tar文件backup.tar解开并放到当前工作目录下。必须说明的是这样做是有危险的，因为在从tar文件中解开文件时，旧文件将被覆盖。

在解开tar文件之前，知道在何处打开文件是非常重要的。例如，假设存档以下文件：/etc/hosts，/etc/group和/etc/passwd。如果用下述命令：

目录/etc会被加到每个文件名前。为了将文件展开到正确位置，需要用下述命令：

这是因为文件从存档文件中抽取出路径名,如果用下述命令存档文件：

这样目录名就不存在存档文件中，因此需要在展开文件之前用“cd /etc”命令进入目录etc。由此可见，tar文件的创建方式与在何处展开有很大关系。

在解开tar文件之前显示tar文件的索引，用这种方式可以看到存档文件中与文件名有关的目录名，从而在正确位置上展开存档文件。

与MS-DOS的存档程序不同， tar在存档过程中并不压缩文件。因此，如果存储两个1MB的文件，那么tar文件大小为2MB，gzip命令用来压缩文件（被压缩的文件并不需要是tar格式）。

压缩backup.tar文件，产生的文件为backup.tar.gz，开关“-9”告诉gzip用最高的压缩比。gunzip命令用来解开一个gzip压缩的文件，用“gzip -d”也可以达到同样效果。

介绍了这些命令之后，我们来尝试组合使用这些命令。为了压缩存储一组文件，可以用下述命令：

结果是形成文件backup.tar.gz。展开该文件时，用相反的命令：

tar命令还包括“z”选择项，它会自动采用gzip压缩算法来联机压缩/解压文件。例如，下列命令：

上面一行的命令等价于：

可以用来代替下述命令：

案例：使用tar进行备份。

选定了备份方式之后，可以使用tar、cpio、dump等备份工具软件将数据备份到磁带上。对于一般的备份，使用tar就足够了。tar能够创建备份文档，能够备份到磁带上或者产生一个文件，如：

将/root目录下的所有文档备份到root.tar文件中，root.tar为指定输出的备份文件，/roo t指出要做备份的目录。如果要备份到磁带上，将输出的备份文件指定为磁带设备文件即可：

如果设置了环境变量TAPE，则可以不使用选项“f”指定输出磁带设备名字:

要进行增量备份，必须找出哪些文件在这个期间进行更新。这个任务可以由命令find来完成，例如查找过去七天更改的文件，并使用tar的“-T”参数制定进行备份的文件，命令如下：

由 于要使用find来找出需要备份的文件列表，那么就需要利用文件的修改时间进行查询，需要使用“-mtime” 参数。另一个更有用的参数是“-newer”，可以查找出所有比某个文件更新的文件，由于备份是周期进行的，因此可以在完全备份之后生成一个标记文件，那 么所有比这个文件新的文件都需要进行更新备份。

进 行数据备份需要定期执行，不能完全依赖于管理员手工进行备份。备份也应该选择在系统比较空闲时进行，以免影响系统的正常处理任务。通常可以选择半夜 0:00点之后进行备份，这样更不能将这个任务由管理员手工完成了。但Linux提供了定时服务cron程序，能够在确定的时间中执行一系列任务，因此数 据备份必须和cron合作来完成，或者使用/etc下的daily，weekly，monthly文件做定时备份的操作。

设计模式是对软件设计普遍存在的问题，所提出的解决方案。与项目本身没有关系，不管是电商，ERP，OA 等，都可以利用设计模式来解决相关问题。当然如果这个软件就只有一小部分人用，并且功能非常简单，在未来可预期的时间内，不会做任何大的修改和添加，即可以不使用设计模式。但是这种的太少了，所以设计模式还是非常重要的。

见名知意，我们设计的类尽量负责一项功能，如A类只负责功能A，B类只负责功能B，不要让A类既负责功能A，又负责功能B，这样会导致代码混乱，容易产生bug。

假设某个类 P 负责两个不同的职责，职责 P1 和 职责 P2，那么当职责 P1 需求发生改变而需要修改类 P，有可能会导致原来运行正常的职责 P2 功能发生故障。

有一个动物类，它会呼吸空气，用一个类描述动物呼吸这个场景：

肯定有不少人跟我刚看到这项原则的时候一样，对这个原则的名字充满疑惑。其实原因就是这项原则最早是在1988年，由麻省理工学院的一位姓里的女士（Barbara Liskov）提出来的。

定义1：如果对每一个类型为 T1的对象 o1，都有类型为 T2 的对象o2，使得以 T1定义的所有程序 P 在所有的对象 o1 都代换成 o2 时，程序 P 的行为没有发生变化，那么类型 T2 是类型 T1 的子类型。

定义2：所有引用基类的地方必须能透明地使用其子类的对象。

问题由来：有一功能P1，由类A完成。现需要将功能P1进行扩展，扩展后的功能为P，其中P由原有功能P1与新功能P2组成。新功能P由类A的子类B来完成，则子类B在完成新功能P2的同时，有可能会导致原有功能P1发生故障。

解决方案：当使用继承时，遵循里氏替换原则。类B继承类A时，除添加新的方法完成新增功能P2外，尽量不要重写父类A的方法，也尽量不要重载父类A的方法。

继承包含这样一层含义：父类中凡是已经实现好的方法（相对于抽象方法而言），实际上是在设定一系列的规范和契约，虽然它不强制要求所有的子类必须遵从这些契约，但是如果子类对这些非抽象方法任意修改，就会对整个继承体系造成破坏。而里氏替换原则就是表达了这一层含义。

继承作为面向对象三大特性之一，在给程序设计带来巨大便利的同时，也带来了弊端。比如使用继承会给程序带来侵入性，程序的可移植性降低，增加了对象间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能会产生故障。

举例说明继承的风险，我们需要完成一个两数相减的功能，由类A来负责。

后来，我们需要增加一个新的功能：完成两数相加，然后再与100求和，由类B来负责。即类B需要完成两个功能：

两数相加，然后再加100。
由于类A已经实现了第一个功能，所以类B继承类A后，只需要再完成第二个功能就可以了，代码如下：

我们发现原本运行正常的相减功能发生了错误。原因就是类B在给方法起名时无意中重写了父类的方法，造成所有运行相减功能的代码全部调用了类B重写后的方法，造成原本运行正常的功能出现了错误。在本例中，引用基类A完成的功能，换成子类B之后，发生了异常。在实际编程中，我们常常会通过重写父类的方法来完成新的功能，这样写起来虽然简单，但是整个继承体系的可复用性会比较差，特别是运用多态比较频繁时，程序运行出错的几率非常大。如果非要重写父类的方法，比较通用的做法是：原来的父类和子类都继承一个更通俗的基类，原有的继承关系去掉，采用依赖、聚合，组合等关系代替。

里氏替换原则通俗的来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能。它包含以下4层含义：

子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。
子类中可以增加自己特有的方法。
当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。
当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。
看上去很不可思议，因为我们会发现在自己编程中常常会违反里氏替换原则，程序照样跑的好好的。所以大家都会产生这样的疑问，假如我非要不遵循里氏替换原则会有什么后果？

后果就是：你写的代码出问题的几率将会大大增加。