最近我的任务是通过一个基于terminal的界面来改进支持150个用户的传统服务器的备份策略。 目前的问题是，服务器在凌晨2点有一个单一的备份，由于应用程序套件和涉及的语言的性质（每个数据文件是离散的，数据文件之间没有强制的参照完整性，但logging可以传播跨越多个数据文件 – 每个数据文件都是按顺序写入应用程序套件的，因此您有可能更新一个文件而另一个文件不更新，从而创build不一致的logging），则在此期间服务器需要未使用。
因此，如果服务器在工作日结束时以某种方式失败，但在清晨进行备份之前，我们将损失大量工作。
由于服务器运行的是AIX 5.x，因此我决定在需要备份的文件系统上实现JFS2快照，这意味着我可以将早上备份中的“暂停系统”减less到实际进行备份所需的时间。 这将是我们的“有保证的备份”。
不过，我也希望通过在白天进行两次“无保证的备份”来减less整天数据丢失的风险，而不会将用户从系统中移除。
这里的理由是，如果我们在服务器上遇到完全断电的情况，那么大部分的数据文件将被损坏 – 这是在一个月前发生的（UPS将受保护的电路断开，断开服务器 – 其中一个那些永远不会发生的事情）。 但是，采取快照的行为不会导致快照内的数据文件损坏，只是目前正在处理损坏的logging的可能性。 或者换句话说，如果每个人都明白它存在的话，那么可以控制的，可pipe理的腐败水平是可以检查的。
所以，我需要问的是：
JFS2快照如何处理完整的powerloss情况？ 在上个月发生的事件中，我们通过腐败损失了大约60％的数据，但该分区的快照怎么样？ 还会遭受腐败吗，还是会没事呢？
例如，我有/ mydata /，并在下午6点将它快照到/ mysnapshot。 晚上7点，我们遇到了“最坏的情况”，/ mydata被严重腐败。 快照也会损坏吗？ AIX和JFS2如何在后台处理这个问题？ 快照是否可用？
我赶紧补充一点，在凌晨2点窗口中还有磁带和远程文件拷贝备份，所以我们不依赖快照作为实际的备份，只是一种改进备份的手段。 在白天的额外快照是一个很好的，而不是我们将依赖的任何东西。
从理论上讲 ，只要将快照提交到磁盘（同时假设pipe理快照的FS或LVM的一部分通常不会被正常写入），您应该没问题。
但是这听起来像你的应用程序使用fsync很差，可以改进（虽然会稍微慢一些），明智地使用适当的posix文件语义。
在linux.conf.au 2007上查看Stewart Smith的“吃我的数据”讲座： http : //www.linux.org.au/conf/2007/talk/278.html