MFS分布式存储三：备份与恢复

1.冗余goal设置目标（goal），是指文件被拷贝的份数，设定了拷贝的份数后是可以通过mfsgetgoal 命令来证实的，也可以通过mfsrsetgoal 来改变设定。/usr/local/mfs/bin/mfssetgoal 3 /mnt/mfs/test1 设置文件/mnt/mfs/test1有三个副本/usr/local/mfs/bin/mfsgetgoal /mnt/mfs/test1 /mnt/mfs/test1: 3用mfsgetgoal –r 和mfssetgoal –r 同样的操作可以对整个树形目录递归操作，其等效于mfsrsetgoal命令。实际的拷贝份数可以通过mfscheckfile 和mfsfile info 命令来查看。注： 一个不包含数据的零长度的文件,尽管没有设置为非零的目标（the non-zero "goal"）,但用mfscheckfile 命令查询将返回一个空的结果；将文件填充内容后，其会根据设置的goal创建副本；这时再将文件清空，其副本依然作为空文件存在。 假如改变一个已经存在的文件的拷贝个数，那么文件的拷贝份数将会被扩大或者被删除，这个过程会有延时。可以通过mfscheckfile 命令来证实。 对一个目录设定“目标”，此目录下的新创建文件和子目录均会继承此目录的设定，但不会改变已经存在的文件及目录的拷贝份数。可以通过mfsdirinfo来查看整个目录树的信息摘要。2.垃圾回收站一个删除文件能够存放在一个“ 垃圾箱”的时间就是一个隔离时间， 这个时间可以用mfsgettrashtime 命令来验证，也可以用mfssettrashtime 命令来设置：/usr/local/mfs/bin/mfssettrashtime 64800 /mnt/mfs/test1/usr/local/mfs/bin/mfsgettrashtime /mnt/mfs/test1 /mnt/mfs/test1: 64800 时间的单位是秒。就像文件被存储的份数一样, 为一个目录设定存放时间是要被新创建的文件和目录所继承的。数字0 意味着一个文件被删除后, 将立即被彻底删除，在想回收是不可能的。删除文件可以通过一个单独安装MFSMETA 文件系统。特别是它包含目录/ trash (包含任然可以被还原的被删除文件的信息)和/ trash/undel (用于获取文件)。只有管理员有权限访问MFSMETA(用户的uid 0，通常是root)。/usr/local/mfs/bin/mfsmount -m /mnt/mfsmeta -H 192.168.0.1被删文件的文件名在“垃圾箱”目录里还可见,文件名由一个八位十六进制的数i-node 和被删文件的文件名组成，在文件名和i-node 之间不是用“/”,而是用了“|”替代。如果一个文件名的长度超过操作系统的限制（通常是255 个字符），那么部分将被删除。通过从挂载点起全路径的文件名被删除的文件仍然可以被读写。移动这个文件到trash/undel 子目录下，将会使原始的文件恢复到正确的MooseFS 文件系统上路径下（如果路径没有改变）。如果在同一路径下有个新的同名文件，那么恢复不会成功。从“垃圾箱”中删除文件结果是释放之前被它站用的空间(删除有延迟,数据被异步删除)。在MFSMETA中还有另一个目录reserved，该目录内的是被删除但依然打开的文件。在用户关闭了这些被打开的文件后，reserved 目录中的文件将被删除，文件的数据也将被立即删除。在reserved 目录中文件的命名方法同trash 目录中的一样，但是不能有其他功能的操作。3. 快照snapshotMooseFS 系统的另一个特征是利用mfsmakesnapshot 工具给文件或者是目录树做快照。
/usr/local/mfs/bin/mfsmakesnapshot source ... destinationMfsmakesnapshot 是在一次执行中整合了一个或是一组文件的拷贝，而且任何修改这些文件的源文件都不会影响到源文件的快照， 就是说任何对源文件的操作,例如写入源文件，将不会修改副本(或反之亦然)。也可以使用mfsappendchunks：/usr/local/mfs/bin/mfsappendchunks destination-file source-file ...当有多个源文件时，它们的快照被加入到同一个目标文件中（每个chunk 的最大量是chunk）。4. MFS chunkservers 的维护若每个文件的goal（目标）都不小于2，并且没有under-goal 文件（这些可以用mfsgetgoal –r和mfsdirinfo 命令来检查），那么一个单一的chunkserver 在任何时刻都可能做停止或者是重新启动。以后每当需要做停止或者是重新启动另一个chunkserver 的时候，要确定之前的chunkserver 被连接，而且要没有under-goal chunks。5.MFS元数据备份与恢复通常元数据有两部分的数据： 主要元数据文件metadata.mfs，当mfsmaster 运行的时候会被命名为metadata.mfs.back 元数据改变日志changelog.*.mfs，存储了过去的N 小时的文件改变（N 的数值是由BACK_LOGS参数设置的，参数的设置在mfschunkserver.cfg 配置文件中）。主要的元数据文件需要定期备份，备份的频率取决于取决于多少小时changelogs 储存。元数据changelogs 实时的自动复制。1.6版本中这个工作都由metalogger完成。5.1 MFS Master的恢复一旦mfsmaster 崩溃（例如因为主机或电源失败），需要最后一个元数据日志changelog 并入主要的metadata 中。这个操作时通过mfsmetarestore 工具做的，最简单的方法是：/usr/local/mfs/bin/mfsmetarestore -a如果master 数据被存储在MooseFS 编译指定地点外的路径，则要利用-d 参数指定使用：/usr/local/mfs/bin/mfsmetarestore -a -d /opt/mfsmaster5.2 从MetaLogger中恢复Master 找回metadata.mfs.back 文件，可以从备份中找，也可以中metalogger 主机中找（如果启动了metalogger 服务），然后把metadata.mfs.back 放入data 目录，一般为{prefix}/var/mfs 从在master 宕掉之前的任何运行metalogger 服务的服务器上拷贝最后metadata 文件，然后放入mfsmaster 的数据目录。 利用mfsmetarestore 命令合并元数据changelogs，可以用自动恢复模式mfsmetarestore –a，也可以利用非自动化恢复模式： mfsmetarestore -m metadata.mfs.back -o metadata.mfs changelog_ml.*.mfs或者强制使用metadata.mfs.back创建metadata.mfs，可以启动master，但丢失的数据暂无法确定。