ChinaUnix首页 > Linux时代 > > 正文

storeBackup 一个非传统备份工具

作者：Jing Youna、王旭 翻译 2004-10-05 18:29:40 来自：linuxfocus

目录:
 

摘要:

StoreBackup可供普通用户使用，用户并不一定要有磁带备份，但是在原来基础上还另需一个硬盘驱动器或者是一台电脑。 使用它，用户可以在专业环境下快速，方便的访问文件备份，同时还可以节省在磁带和管理上的费用。

数据除了可以备份于磁带之外，另一个选择就是将数据存储于硬盘驱动器或其他类似的设备上。 我们要在这里介绍的这个软件工作性能好，而且非常节省内存空间：

  • 目录，包括它们的树结构，可能会被拷贝到另外一个地方(例如 /home => /var/bkup/2003.12.13_02.04.26)。 文件的存取权限被完全保留着 用户可以直接访问文件的备份。
  • 比较文件和现存备份的内容，以确保每一份文件只有一个备份，也就是说拥有相同内容的文件在备份中只出现一次。
  • 相同的文件硬连接，在备份中按照原来的位置关系出现。
  • 除非被标记为’exclude‘，否则备份文件会被压缩。压缩可以被完全去掉。
  • 独立产生的一组备份 (比如来自不同计算机的备份) 可以通过硬链接来共享文件。在同样内容的文件在备份中只出现一次这样的条件下，可以在完全或部分备份中采用这种方法。

_________________ _________________ _________________

 

为什么需要新的备份工具？

在已经有成千上万的备份工具的今天，为什么还需要新的呢？原因产生于像我这样一个顾问的特殊生活方式。通常一整个星期我都在外面跑，所以一周下来根本没有时间呆在家里做数据备份。我有的只是并行端口上的一个250MB的ZIP驱动器。ZIP驱动器并没有为我的数据备份提供很大的空间，每次我都不得不忍受极低的工作性能（大概是200KB/S）。我除了需要以快速，方便的访问数据之外，我还不太喜欢通常的三种备份的选择，即完全型的，差额型的和增量型的（例如：用 tar 或 dump 备份）。我之所以不喜欢这三种选择有两个原因：其一是恢复这三类形式的备份非常麻烦，其二是你不能随心所欲的删除一个旧的备份，这样的话，就要求在做备份的时候仔细考虑。

我的目标就是在工作的时候可以快速的备份，快速的找到我需要的文件，而不要有什么麻烦。

于是，在1999年末的时候 storeBack 的第一版问世了，但是它却不适用于大的工作环境。在那种情况下，它的工作性能不是特别好，没有充分发挥，也无法处理不规则的文件名（例如：文件名中含有‘\n’）。

有了第一版的这些经验，我在之后不到一年的时间里又编写了一个新的版本，并在 GPL 下发布。同时用户也增加了－从普通家庭到医院，大学，都用它来备份ISPs上的邮件目录，或者是用于通常的归档。  

怎么样的备份工具才是理想的？

理想的备份工具应该是管理者花最少的精力，拥有最大的舒适度，就可以完成每天的整个数据系统（包括可应用的访问权）的完全拷贝。而实现这些要求的计算机和硬盘系统当然都应该在一个远程的，安全的建筑物内。有了数据系统浏览器，用户就可以访问安全数据用于检索，也可以把数据直接复制过来。备份可以直接使用，不会有什么问题。这样，处理备份就变得很‘平常’－因为基本上已经不需要管理了。

我们这里介绍的这个过程有一点不好：那就是它需要很大的硬盘驱动器空间，并且由于每次都要拷贝全部的数据从而导致速度非常慢。  

storeBackup如何工作？

StoreBackup以达到”理想的备份“为目标，并致力于解决两个问题：存储空间和性能问题。  

特点：

减少必要的硬盘驱动器空间的首要办法就是进行数据压缩－如果那样有效的话。storeBackup容许用户以外部程序的形式来使用任意的 压缩算法。默认形式是bzip2。

仔细的看一下存储后的数据，我们会发现备份与备份之间，很少有文件发生改变－这也就是增量备份的产生原因。在备份中我们也会 发现很多文件有相同的内容，因为用户有可能在拷贝文件或者一个版本管理程序（如cvs）正在运行。除此之外，文件或目录结构可能被 重命名了，在增量备份中它们可能会被再次备份（没有必要的）。这个问题的解决办法是检查有相同内容的文件的备份（可能压缩）， 并且标记出来。硬连接就是参考。（解释：在Unix操作系统中数据块是通过 i-node 来管理的。在不同目录中的不同的文件名可能会指向 一个 i-node。实际文件带着它的最后一次硬连接（＝目录名）被删除了）。（在单个文件系统中，硬连接可能指向一个特定的文件。）
根据硬连接的技巧，对于已经存在的备份文件，每一个文件都将出现在每个备份中，尽管事实上它在硬盘驱动器上只存在过一次。对文件 和目录的拷贝和重命名只需要考虑硬连接占用的内存空间－这个空间小的几乎不用考虑。

在很多情况下，不仅仅是一台电脑需要做备份，而是很多台都需要这样做。在这些电脑中，有相当一部分文件是相同的，尤其是像/etc 或者是/usr等目录下的，因此有必要确保相同的文件在备份驱动器上只有一份拷贝。最简单的办法就是装载备份服务器上所有的目录，并 对处于同一个扫频的所有计算机做备份。在这种方式下，相同文件会被检测到并做硬连接。然而，这个方法有一个缺点，那就是所有要 备份的计算机在备份时间来到时都必须是准备好的。这个办法在很多情况下也是不可行的，例如，如果是笔记本电脑就应该用storeBackup 来做备份。
尤其对于笔记本电脑，我们会发现更多的文件，几乎是台式机的将近两倍左右，原因就在于用户生成了本地拷贝。在这种情况下，或者服务 器之间都是独立备份的情况下，那么可用的硬盘驱动器空间通过硬连接将会得到最佳利用，storeBackup能够以独立的备份形式硬连接文件 （备份之间互相独立，可能来自不同的机器）。

关于文件删除，storeBackup提供了一系列的可选方法。当每一个备份都是完整的备份时，删除变得尤其方便，用的是完全相同的方法。与 传统备份不同，我们在这里根本不用考虑一个增量备份是否是建立在原来的备份之上。
这些选项容许用户在某个特定的工作日来做备份删除或保存，无论哪一天都可。它能够确保尽可能的产生最少的备份。这一点对于不是在正常 情况下产生的备份尤其有用。你可以将电脑的最后一个备份保持到四周假期的最后，需要做的只是把保持的时间设定为三周。更进一步说， 你可以定义最大的备份数。还有很多选项可以帮助解决相矛盾的规则之间的冲突（通过常理）。  

性能

上面描述的方法都假定在进行文件的新备份之前，首先检测到相同文件的一个已经存在的备份。这适用于在之前已经备份的文件，也同样 适用于新创建的。当然把将要备份的文件与之前已经备份的文件做直接的比较并没有太多的意义。因此，利用哈希表，我们对之前备份的 文件和将要备份的文件的md5值做比较。程序用dbm文件来做这项工作。
计算md5值非常快，但是在涉及大量数据的情况下速度也就没那么快了。基于这个原因，storeBackup首先检测文件在最后一次备份以来是否 被修改过（路径＋文件名，ctime，mtime，和size都是相同的）。如果文件没有被修改过，那么最后一次备份的md5值就会被采用，并且设定 硬连接。如果初始检测发现有不同，就计算md5值，并再次检测是否存在与此md5值相同的另一个文件。（利用一个扩展的，但是同样有效的 过程对大量的备份系列做比较）。使用这种方法，对于一个备份我们只需做极少数的md5值计算。

我的服务器（200MHZ，IDE）可每秒钟处理20至35个文件，我的台式电脑（800MHZ，IDE）速度为每秒钟处理150至200个文件。我测过拥有高速 硬盘驱动器（2.4GHZ,1.4TB software RAID）的高速电脑处理速度可以达到每秒钟800个文件。这些结果是相对于写入本地驱动器而言。写入NFS 可能会慢一些。关键就在于硬盘驱动器的速度（所有的测试都是在Linux下进行）。  

实现

storeBackup已经在Linux，FreeBSD，Solaris和AIX下做过测试。它们应该可以在所有的Unix平台下运行。编程用的语言是Perl。  

Installation

安装非常方便。StoreBackup可以从 http://www.sf.net/projects/storebackup 处下载，选取storeBackup version.tar.bz2,解 压缩到指定的位置即可。

tar jxf storeBackup-version.tar.bz2

这条指令会生成storeBackup的目录，在子目录bin下有文档和可运行程序。他们可以通过完整路径来调用。$PATH 环境变量的设置 是可选的。不包含md5sum程序的操作系统（例如FreeBSD）就需要编译md5sum。关于这个的说明可以在相关的README文件中找到。  

操作

在这里我们不会详细介绍所有的选项，这些内容可以在软件包里找到。
产生一个备份的最简单的办法是：

storeBackup.pl -s sourceDir -t targetDir

sourceDir和targetDir必须存在。StoreBackup会把文件从sourceDir拷贝到targetDir/date_time，并且在这个过程中用bzip2对文件 压缩（对.gz,.bz2,.png等等不进行压缩），同时完成与复制文件的连接。

在最新版（1.14.1）storeBackup.p1中有45个参数可以设定，本文在此不作介绍。用户可以用这条指令访问：

storeBackup.pl -h

在文件README和EXAMPLES里，用户可以找到不同应用的详尽说明。有必要指出，除了可以在命令行输入参数 之外，还有更快的方法，那就是使用配置文件。可以通过以下指令产生：

storeBackup.pl --generate --file ConfigFile

或者使用更加简短的形式：

storeBackup.pl -g -f ConfigFile

检查一下，用下面的命令局部地运行

storeBackup.pl -f ConfigFile --print

随后，storeBackup也可能用下面的指令启动：

storeBackup.pl -f ConfigFile

关于storeBackup的所有选项的全部说明可以在文件README和EXAMPLES里面找到，这两个文件是tar文件的一部分。

为了检测备份的哪个版本的文件存在哪个地方，storeBackup可以用下面指令：

storeBackupVersion.pl -f Filename

filename 对应的地方应填写文件名称，形式必须与备份中的一样，也就是说，包括它的压缩属性。最简单的办法就是找到正确位置的备 份路径，运行指令。运行选项"-h" 就可以显示所有11个参数的解释。

单个文件的恢复可以通过cp，ftp文件浏览器或者类似的机制来完成。对于部分目录树或整个备份的恢复，可以使用工具storeBackupRecover.pl 。 它可以从备份中将需要的文件和目录抽取出来。这样做会恢复原文件，也就是说，用户，组，以及权限会被重建。如果原来的的文件是未压缩的， 那么恢复文件就会解压缩。原来的硬连接也会恢复。
storeBackup的附加选项可以进行统计输出，就像对性能参数的操作一样，如覆盖行为等等。使用选项"-h"大概可以读出10个参数。

利用storeBackupDel.pl，备份的删除独立于程序storeBackupRecover.pl。这一点对于在NFS上的备份非常有用。删除位于NFS 上的目录树比本地删除要慢得多。不需要删除功能就可以在NFS上调用storeBackup，这样就可以更好的控制备份持续时间。用 storeBackupDel 来删除之前在服务器上产生的备份这种方法可以将删除与实际的备份过程隔离开来，顺便提一下，它与storeBackup 在删除方面有同样的选项。

已有的备份是以目录的形式来组织的。显示可用storeBackupls.pl （比‘ls’更加一致）。 简单列表如下： 
hjc@schlappix:~/backup ) storeBackupls.pl /media/zip/stbu/
  1  Fri May 23 2003   2003.05.23_12.37.53   -156
  2  Fri Jun 06 2003   2003.06.06_14.31.47   -142
  3  Fri Jun 13 2003   2003.06.13_14.17.18   -135
  4  Fri Jun 20 2003   2003.06.20_14.02.35   -128
  5  Fri Jun 27 2003   2003.06.27_14.23.55   -121
  6  Mon Jun 30 2003   2003.06.30_17.34.37   -118
  7  Fri Jul 04 2003   2003.07.04_13.10.06   -114
  8  Fri Jul 11 2003   2003.07.11_13.13.14   -107
  9  Fri Jul 18 2003   2003.07.18_14.03.49   -100
 10  Fri Jul 25 2003   2003.07.25_14.19.19   -93
 11  Thu Jul 31 2003   2003.07.31_17.07.55   -87
 12  Fri Aug 01 2003   2003.08.01_12.16.58   -86
 13  Fri Aug 15 2003   2003.08.15_15.10.19   -72
 14  Sat Aug 23 2003   2003.08.23_06.25.35   -64
 15  Wed Aug 27 2003   2003.08.27_18.21.09   -60
 16  Thu Aug 28 2003   2003.08.28_14.16.39   -59
 17  Fri Aug 29 2003   2003.08.29_14.35.10   -58
 18  Mon Sep 01 2003   2003.09.01_17.19.56   -55
 19  Tue Sep 02 2003   2003.09.02_18.18.46   -54
 20  Wed Sep 03 2003   2003.09.03_16.22.41   -53
 21  Thu Sep 04 2003   2003.09.04_16.59.19   -52
 22  Fri Sep 05 2003   2003.09.05_14.35.20   -51
 23  Mon Sep 08 2003   2003.09.08_20.08.52   -48
 24  Tue Sep 09 2003   2003.09.09_18.45.48   -47
 25  Wed Sep 10 2003   2003.09.10_18.30.48   -46
 26  Thu Sep 11 2003   2003.09.11_17.26.46   -45
 27  Fri Sep 12 2003   2003.09.12_15.23.03   -44
 28  Mon Sep 15 2003   2003.09.15_18.05.19   -41
 29  Tue Sep 16 2003   2003.09.16_18.04.16   -40
 30  Wed Sep 17 2003   2003.09.17_19.03.02   -39
 31  Thu Sep 18 2003   2003.09.18_18.21.09   -38
 32  Fri Sep 19 2003   2003.09.19_14.48.05   -37  not finished
 33  Mon Sep 22 2003   2003.09.22_18.58.55   -34
 34  Tue Sep 23 2003   2003.09.23_18.48.40   -33
 35  Wed Sep 24 2003   2003.09.24_19.32.24   -32
 36  Thu Sep 25 2003   2003.09.25_18.05.38   -31
 37  Fri Sep 26 2003   2003.09.26_14.59.59   -30
 38  Mon Sep 29 2003   2003.09.29_18.42.59   -27
 39  Tue Sep 30 2003   2003.09.30_18.02.03   -26
 40  Wed Oct 01 2003   2003.10.01_17.09.43   -25
 41  Thu Oct 02 2003   2003.10.02_15.26.33   -24
 42  Mon Oct 06 2003   2003.10.06_20.08.45   -20
 43  Tue Oct 07 2003   2003.10.07_19.46.54   -19
 44  Wed Oct 08 2003   2003.10.08_16.03.23   -18
 45  Thu Oct 09 2003   2003.10.09_16.58.28   -17
 46  Fri Oct 10 2003   2003.10.10_14.21.06   -16
 47  Mon Oct 13 2003   2003.10.13_18.58.24   -13
 48  Tue Oct 14 2003   2003.10.14_16.02.44   -12
 49  Wed Oct 15 2003   2003.10.15_19.04.12   -11
 50  Thu Oct 16 2003   2003.10.16_15.47.51   -10
 51  Mon Oct 20 2003   2003.10.20_09.34.52   -6
 52  Mon Oct 20 2003   2003.10.20_12.16.40   -6
 53  Tue Oct 21 2003   2003.10.21_09.43.40   -5
 54  Tue Oct 21 2003   2003.10.21_11.22.36   -5
 55  Tue Oct 21 2003   2003.10.21_16.01.15   -5
 56  Tue Oct 21 2003   2003.10.21_18.08.07   -5
 57  Wed Oct 22 2003   2003.10.22_10.02.51   -4
 58  Wed Oct 22 2003   2003.10.22_16.09.42   -4
 59  Wed Oct 22 2003   2003.10.22_18.03.05   -4
 60  Thu Oct 23 2003   2003.10.23_08.18.15   -3
 61  Thu Oct 23 2003   2003.10.23_14.16.24   -3
 62  Thu Oct 23 2003   2003.10.23_17.00.36   -3
 63  Fri Oct 24 2003   2003.10.24_13.29.30   -2
 64  Sun Oct 26 2003   2003.10.26_09.08.55   0
‘not finished’表示备份被放弃了。
或者配置文件带有在删除情况下的信息，如下： 
hjc@schlappix:~/backup ) storeBackupls.pl -f stbu.conf /media/zip/stbu/
analyse of old Backups in </media/zip/stbu/>:
 Fri 2003.05.23_12.37.53 (156): keepLastOfMonth(400d)
 Fri 2003.06.06_14.31.47 (142): keepLastOfWeek(150d)
 Fri 2003.06.13_14.17.18 (135): keepLastOfWeek(150d)
 Fri 2003.06.20_14.02.35 (128): keepLastOfWeek(150d)
 Fri 2003.06.27_14.23.55 (121): keepLastOfWeek(150d)
 Mon 2003.06.30_17.34.37 (118): keepLastOfMonth(400d)
 Fri 2003.07.04_13.10.06 (114): keepLastOfWeek(150d), keepMinNumber50
 Fri 2003.07.11_13.13.14 (107): keepLastOfWeek(150d), keepMinNumber49
 Fri 2003.07.18_14.03.49 (100): keepLastOfWeek(150d), keepMinNumber48
 Fri 2003.07.25_14.19.19 (93): keepLastOfWeek(150d), keepMinNumber47
 Thu 2003.07.31_17.07.55 (87): keepLastOfMonth(400d), keepMinNumber46
 Fri 2003.08.01_12.16.58 (86): keepLastOfWeek(150d), keepMinNumber45
 Fri 2003.08.15_15.10.19 (72): keepLastOfWeek(150d), keepMinNumber44
 Sat 2003.08.23_06.25.35 (64): keepLastOfWeek(150d), keepMinNumber43
 Wed 2003.08.27_18.21.09 (60): keepMinNumber42, keepWeekDays(60d)
 Thu 2003.08.28_14.16.39 (59): keepMinNumber41, keepWeekDays(60d)
 Fri 2003.08.29_14.35.10 (58): keepLastOfMonth(400d), keepLastOfWeek(150d),
                               keepMinNumber40, keepWeekDays(60d)
 Mon 2003.09.01_17.19.56 (55): keepMinNumber39, keepWeekDays(60d)
 Tue 2003.09.02_18.18.46 (54): keepMinNumber38, keepWeekDays(60d)
 Wed 2003.09.03_16.22.41 (53): keepMinNumber37, keepWeekDays(60d)
 Thu 2003.09.04_16.59.19 (52): keepMinNumber36, keepWeekDays(60d)
 Fri 2003.09.05_14.35.20 (51): keepLastOfWeek(150d), keepMinNumber35, keepWeekDays(60d)
 Mon 2003.09.08_20.08.52 (48): keepMinNumber34, keepWeekDays(60d)
 Tue 2003.09.09_18.45.48 (47): keepMinNumber33, keepWeekDays(60d)
 Wed 2003.09.10_18.30.48 (46): keepMinNumber32, keepWeekDays(60d)
 Thu 2003.09.11_17.26.46 (45): keepMinNumber31, keepWeekDays(60d)
 Fri 2003.09.12_15.23.03 (44): keepLastOfWeek(150d), keepMinNumber30, keepWeekDays(60d)
 Mon 2003.09.15_18.05.19 (41): keepMinNumber29, keepWeekDays(60d)
 Tue 2003.09.16_18.04.16 (40): keepMinNumber28, keepWeekDays(60d)
 Wed 2003.09.17_19.03.02 (39): keepMinNumber27, keepWeekDays(60d)
 Thu 2003.09.18_18.21.09 (38): keepMinNumber26, keepWeekDays(60d)
 Fri 2003.09.19_14.48.05 (37): keepLastOfWeek(150d), keepMinNumber25, keepWeekDays(60d)
 Mon 2003.09.22_18.58.55 (34): keepMinNumber24, keepWeekDays(60d)
 Tue 2003.09.23_18.48.40 (33): keepMinNumber23, keepWeekDays(60d)
 Wed 2003.09.24_19.32.24 (32): keepMinNumber22, keepWeekDays(60d)
 Thu 2003.09.25_18.05.38 (31): keepMinNumber21, keepWeekDays(60d)
 Fri 2003.09.26_14.59.59 (30): keepLastOfWeek(150d), keepMinNumber20, keepWeekDays(60d)
 Mon 2003.09.29_18.42.59 (27): keepMinNumber19, keepWeekDays(60d)
 Tue 2003.09.30_18.02.03 (26): keepLastOfMonth(400d), keepMinNumber18, keepWeekDays(60d)
 Wed 2003.10.01_17.09.43 (25): keepMinNumber17, keepWeekDays(60d)
 Thu 2003.10.02_15.26.33 (24): keepLastOfWeek(150d), keepMinNumber16, keepWeekDays(60d)
 Mon 2003.10.06_20.08.45 (20): keepMinNumber15, keepWeekDays(60d)
 Tue 2003.10.07_19.46.54 (19): keepMinNumber14, keepWeekDays(60d)
 Wed 2003.10.08_16.03.23 (18): keepMinNumber13, keepWeekDays(60d)
 Thu 2003.10.09_16.58.28 (17): keepMinNumber12, keepWeekDays(60d)
 Fri 2003.10.10_14.21.06 (16): keepLastOfWeek(150d), keepMinNumber11, keepWeekDays(60d)
 Mon 2003.10.13_18.58.24 (13): keepMinNumber10, keepWeekDays(60d)
 Tue 2003.10.14_16.02.44 (12): keepMinNumber9, keepWeekDays(60d)
 Wed 2003.10.15_19.04.12 (11): keepMinNumber8, keepWeekDays(60d)
 Thu 2003.10.16_15.47.51 (10): keepLastOfWeek(150d), keepMinNumber7, keepWeekDays(60d)
 Mon 2003.10.20_09.34.52 (6): keepDuplicate(7d)
 Mon 2003.10.20_12.16.40 (6): keepMinNumber6, keepWeekDays(60d)
 Tue 2003.10.21_09.43.40 (5): keepDuplicate(7d)
 Tue 2003.10.21_11.22.36 (5): keepDuplicate(7d)
 Tue 2003.10.21_16.01.15 (5): keepDuplicate(7d)
 Tue 2003.10.21_18.08.07 (5): keepMinNumber5, keepWeekDays(60d)
 Wed 2003.10.22_10.02.51 (4): keepDuplicate(7d)
 Wed 2003.10.22_16.09.42 (4): keepDuplicate(7d)
 Wed 2003.10.22_18.03.05 (4): keepMinNumber4, keepWeekDays(60d)
 Thu 2003.10.23_08.18.15 (3): keepDuplicate(7d)
 Thu 2003.10.23_14.16.24 (3): keepDuplicate(7d)
 Thu 2003.10.23_17.00.36 (3): keepMinNumber3, keepWeekDays(60d)
 Fri 2003.10.24_13.29.30 (2): keepLastOfWeek(150d), keepMinNumber2, keepWeekDays(60d)
 Sun 2003.10.26_09.08.55 (0): keepLastOfMonth(400d), keepLastOfWeek(150d),
                              keepMinNumber1, keepWeekDays(60d)


除了上面描述的备份程序，还有程序11t和multitail。11t可以显示文件创建，修改和访问的时间。 multitail可以跟踪很多文件，就像使用”tail-f“一样，但是multitail比‘tail-f’提供了更多的选项，并且更加健壮。  

未来展望

对于storeBackup的下一个版本，我们决定体现如下的特征：
  • 一个备份的最大的时间消耗为硬连接（除了第一个备份，其中每一个内容都要压缩/拷贝）。产生一个硬连接非常快， 但是问题在于它们的巨大数目－相比于其他操作和对于压缩的并行操作－这是主要的时间需求。
    storeBackup的下一个版本会提供备份目录结构的选项，并在第一步就修改文件。这是从要备份的数据的角度来总结备份的。 第二步，丢失的硬连接会被创建。这两个步骤相互之间完全无关－意思是它们可以在不同的机器上运行，并且在产生新的硬连接 之前可以做一些备份。
    初步测试表明这个选项在本地写入的运行情况下，可以获得性能增益－相比于”普通“完全备份－大概是5－10倍（”普通“情况下 的1/5或1/10）。如果你在远程机器上启动过程用于本地硬连接，那么NFS上的备份速度就会提高。
  • 下一个版本的计划是扩展搜索能力（利用随后的再次备份）。可能会用用户定义的规则来搜索备份，规则内容可以包括文件 名称（形式），文件大小，文件初始生成时间，文件初次修改时间，用户ID，文件访问权限，以及一个简单的grep。这个规则 会包括‘and’，‘or’，‘not’以及其他的可选项。
  • 随后的未来计划中设想能够进行选项扩展（以类似于tar的形式），并且希望可以支持新的数据类型，例如，设备。
 

版本和许可

在写这篇文章的时候，storeBackup的版本为1.14.1,可以到 http://www.sf.net/projects/storebackup处下载。
StoreBackup受GPL保护。
(编辑:admin)


【Linux论坛】【评论】【关闭】

Linux文档搜索
关键词