数据备份惊魂之tar篇

    上周记录的一篇提到了Synology的NAS系统。这次的故事就是其后续。

    首先购买的是只支持一块硬盘的DS111j系统。到手后我突然意识到这种单硬盘的系统完全没有扩展性可言。在点击购买DS111j之前我也曾做过一番考虑,当时大约是碍于价格因素没有选择双硬盘的DS211j。可是成品到手之后,这两个型号间的50欧元差价突然就变得微不足道了。(从八月至今,新的电视、Micro Music系统、NAS系统+2TB硬盘,几乎每个月都有额外的消费,月入不敷出)

    更换型号的过程略过。上周六DS211j送到,大规模数据转移开始。目前的存储配置是:WD SATA II 2TB、WD IDE 500GB、Seagate IDE 160GB、HITACHI 320GB,前三个都是3.5寸,最后的是移动硬盘。不用说大量的数据要直接转移到新的1号硬盘,2号硬盘用来存放文档、音乐档、漫画档,3号放些杂七杂八的东西和一些备份数据,4号也堆放一些杂物。简化数据转移流程是:原2号->1号、原3号->2号、原部分4号+各主机内杂物->3号、其余->4号。实际操作时由于原2号数据太多所以第一步进行的同时用tar打包原3号的档案于4号,接着进行第三步。理论上第三步差不多结束的时候第一步也就完成了,可以节省点时间。遗憾的是实践上出问题了。

    原4号档因为之前需要重新格式化用以备份PS3,所以早就tar过了。第三步提取了这个tar里的一部分内容,觉得去掉这些内容对于之后第四步是有帮助的,于是用图形界面删除tar包的一部分内容。没想到的是睡了一觉起来居然还没删除完成。一怒之下强行终止,之后就完全无法打开这个包了。用tar列出的文件列表也只有1/5,然后就报错“a lone zero at block XXXX”。当初为了提高效率tar包没有压缩,而且删除操作没有完成,文件大小没有改变,大概包里只是留下了一些不完全的垃圾数据。我不了解tar的具体结构,不过想来恢复应该有望,而且剩下的数据也不是特别重要。因此虽然没有找到解决方法,也不太着急。

    那么就接着进行第二步的后半段,解开原3号的tar包到2号。由于这批tar包是暂存在FAT32格式的4号上,所以打包的时候就进行了分割。我想当然的认为解压头文件结束会自然地按编号继续,不料报错EOF。这让我非常的恐惧——几天之内,三个tar包全部报废!如果说原4号tar包的损毁是我鲁莽所致的话,原3号的tar包可是新鲜出炉,没受到任何改动啊。这都出错,tar这个破程序不是在害人吗?!
听网上一些人的忽悠尝试了star、cpio这类包程序,也全都失败。我不甘心,翻回头去读tar的说明档,这才发现自己犯了多么低级的错误,并顺便解决了原4号tar包的损毁问题。

    简单说来tar本身没有分割文件的功能,实际应用中是将tar的结果通过pipe(|)传递给split来进行原始数据分割。因此除了头文件以外其他编号的档案都是bin格式的。这一点我看在眼里却没放在心上,打包时分割的命令也是从Ubuntu的文档里黏贴下来的。知道了tar没有分割功能,EOF的错误就非常自然了。解包用cat把所有编号集合起来扔给tar就解决了。而那个损毁了的4号tar包只要在解压时加上忽略0结尾的参数就能跳过损毁区把后面的文件找出来。

    这次的麻烦基本上都是由于没有仔细读tar的说明档所致:读了说明档就知道如何跳过特定文件,就不用删除tar包里的部分内容,也就不会因为强行终止损毁数据;读了说明档就知道文件的分割和集合都不是tar负责,就不用瞎忙活了。我是不会把linux常用的几十条命令的说明档都去读一遍的,但是以后出了问题还是先读说明档。很多论坛言论只会把问题弄得更复杂。

以此纪念。

Advertisements
  1. 留下评论

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s

%d 博主赞过: