我最近的任务是通过基于终端的界面改进支持 150 个用户的旧服务器的备份策略。目前的问题是服务器在凌晨 2 点进行了一次备份，并且由于应用程序套件的性质和所涉及的语言（每个数据文件是离散的，数据文件之间没有强制引用完整性，但记录可以传播跨多个数据文件 - 每个数据文件都按顺序写入应用程序套件中，因此您可能会更新一个文件而另一个文件不更新，从而创建不一致的记录），在此期间需要不使用服务器。
因此，如果服务器在工作日结束时以某种方式发生故障，但在清晨进行备份之前，我们将失去大量工作。
由于服务器运行的是 AIX 5.x，我决定在需要备份的文件系统上实现 JFS2 快照，这意味着我可以将清晨备份中的“系统关闭时间”减少到实际进行 hte 备份所需的时间. 这将是我们的“保证备份”。
但是，我还希望尝试通过在白天进行两次“非保证备份”来降低全天数据丢失的风险，而无需从系统中删除用户。
这里的理由是，如果我们在服务器上遇到完全断电的情况，很大一部分数据文件将被损坏——这发生在一个月前（UPS 烧毁了受保护的电路，关闭了服务器——其中之一不应该发生的事情）。但是，拍摄快照的行为不会导致快照中的数据文件损坏，只会导致当前正在处理的损坏记录的可能性。或者，换句话说，如果每个人都知道它首先存在，则可以检查可控制、可管理的腐败水平。
所以，我需要问的问题是：
JFS2 快照处理完全断电情况的能力如何？在上个月发生的事件中，我们因损坏丢失了大约 60% 的数据，但该分区的快照将如何处理？它还会遭受腐败吗，还是会没事？
例如，我有 /mydata/，并在下午 6 点将其快照到 /mysnapshot。晚上 7 点，我们遇到了“最坏的情况”，并且 /mydata 严重损坏。快照也会损坏吗？AIX 和 JFS2 如何在后台处理这个问题？快照可以使用吗？
我赶紧补充一点，在凌晨 2 点的时间段内还会进行磁带和远程文件复制备份，因此我们不依赖快照作为实际备份，这只是改进备份的一种手段。白天的额外快照具有一定的准确性，而不是我们依赖的任何东西。
理论上，只要将快照提交到磁盘（还假设管理快照的 FS 或 LVM 部分通常不被写入），您应该没问题。
但是听起来您的应用程序使用 fsync 很差，并且可以通过明智地使用正确的 posix 文件语义来改进（尽管它会稍微慢一些）。
请参阅 Stewart Smith 在 linux.conf.au 2007 上的“吃掉我的数据”演讲： http ://www.linux.org.au/conf/2007/talk/278.html