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