BBWC：从理论上讲，这是个好主意，但是有没有人保存过您的数据？

我熟悉BBWC（电池支持的写缓存）的用途-甚至在使用优质UPS的情况下，它们也曾在我的服务器中使用过。显然存在无法提供保护的故障。我很好奇它在实践中是否真正提供了任何真正的好处。

（注意，我特别在寻找患有BBWC且发生车祸/故障以及BBWC是否有助于恢复的人的答复）

更新资料

收到反馈后，我越来越怀疑BBWC是否会带来任何价值。

为了对数据完整性有信心，文件系统必须知道何时将数据提交到非易失性存储（不一定是磁盘，这是我将要谈到的问题）。值得注意的是，将数据提交到磁盘后，会出现许多磁盘（http://brad.livejournal.com/2116715.html）。尽管可以合理地认为禁用磁盘上的缓存可能会使磁盘更老实，但仍然不能保证确实如此。

由于BBWC中的缓冲区通常过大，因此屏障可能需要将更多数据提交到磁盘，从而导致写入延迟：一般建议是在使用非易失性回写高速缓存时禁用屏障（并禁用on-磁盘缓存）。但是，这似乎破坏了写操作的完整性-仅因为非易失性存储中保留了更多数据并不意味着它会更加一致。确实，可以说在逻辑事务之间不进行划分，与其他方式相比，确保一致性的机会似乎更少。

如果BBWC在数据进入其非易失性存储（而不是提交到磁盘）的那一刻承认障碍，那么它似乎可以满足数据完整性要求而不会降低性能-意味着仍应启用障碍。但是，由于这些设备通常表现出与将数据刷新到物理设备一致的行为（带有障碍的速度明显较慢）以及禁用障碍的广泛建议，因此它们无法以此方式运行。为什么不？

如果将OS中的I / O建模为一系列流，则在某种程度上可以最大程度地减小由OS管理写缓存时的写屏障的阻塞效果-因为在此级别仅逻辑事务（单个流） ）需要承诺。另一方面，一个不知道构成事务的数据位的BBWC必须将其整个缓存提交到磁盘。内核/文件系统是否实际上在实践中实现了这一点，将比我目前打算投入的工作多得多。

磁盘组合会告诉故障发生了什么，并且突然断电无疑会导致损坏-以及日记或日志结构化的文件系统在中断后无法完全执行fsck的情况下，更不可能发现损坏的发生，更不用说试图修复它。

就故障模式而言，根据我的经验，大多数突发性停电是由于市电中断而造成的（通过UPS和管理性关机可以轻松缓解）。人们将错误的电缆从机架中拔出，意味着数据中心的卫生性很差（标签和电缆管理）。UPS不能阻止某些类型的突然断电事件-PSU或VRM中的故障，带有障碍物的BBWC在发生故障时将提供数据完整性，但是这种事件有多普遍？从这里缺乏回应来看非常罕见。

当然，将容错能力提高到更高的堆栈中比使用BBWC的成本要高得多-但是将服务器实现为群集对于性能和可用性还有很多其他好处。

减轻突然断电的影响的另一种方法是实施SAN-AoE使这成为一个可行的方案（我对iSCSI的意义不大），但同样存在更高的成本。

当然。我曾经使用电池支持的缓存（BBWC），后来使用了闪存支持的写缓存（FBWC）保护崩溃和突然断电后的飞行中数据。

在HP ProLiant服务器上，典型消息是：

POST Error: 1792-Drive Array Reports Valid Data Found in Array Accelerator

这意味着，“ 嘿，写缓存中的数据在重启/掉电后仍然存在！！我现在将其写回到磁盘上！ ”

一个有趣的例子是我对一个在龙卷风期间断电的系统的事后检验，数组序列为：

POST Error: 1793-Drive Array - Array Accelerator Battery Depleted - Data Loss
POST Error: 1779-Drive Array Controller Detects Replacement Drives
POST Error: 1792-Drive Array Reports Valid Data Found in Array Accelerator

1793 POST错误是唯一的。-在使用系统时，数据在Array Accelerator内存中时电源中断。但是，由于这是龙卷风，四天之内无法恢复供电，因此阵列电池已耗尽，其中的数据丢失。该服务器有两个RAID控制器。另一个控制器有一个FBWC单元，其使用寿命比电池长得多。该驱动器已正确恢复。空电池支持的阵列上出现了一些数据损坏。

尽管该工厂的电池运行时间充裕，但是四天没有电且没有危险条件，这使任何人都无法安全关闭服务器。

是的，有这种情况。

数据中心中的服务器“不带UPS”（数据中心具有UPS）。PDU故障-系统严重崩溃。没有数据丢失。

基本上就是这样。BBWC的优点在于它在机器中。拥有UPS-相信我，有时有人做一些愚蠢的事情（例如拉错电缆）。UPS是外部的。哦，那条电缆;）

我有2种情况，硬件RAID控制器中的电池后备缓存完全失败（在2个独立的公司中）。

英国广播公司依靠电池工作的毫不奇怪的想法。问题在于，控制器中的电池有时会发生故障，而令人震惊的是，在许多硬件团队控制器中，它会无声地发生故障。我们以为我们有一个防止断电的缓存，但是我们没有。

断电时，RAID阵列数据丢失的范围非常广泛，以致所有磁盘内容都无法恢复。一切都丢失了。其中一个案例涉及一台完全专用于测试的机器，但仍然如此。

之后，我说“不再”，切换到基于Linux +基于日志的fs的基于软件的磁盘镜像（mdadm），该磁盘对断电（ext4）具有良好的恢复能力，并且从不回头。当然，我已经在IO使用率不高的服务器上使用了它。

这似乎需要对该问题进行第二次回答。

我刚有一个独立的VMware ESXi主机丢失了RAID 5阵列中的驱动器。降级的阵列影响了VM和应用程序级别的性能。

Smart Array P410i in Slot 0 (Embedded)    (sn: 5001438011138950)

   array A (SAS, Unused Space: 0  MB)

      logicaldrive 1 (1.6 TB, RAID 5, Recovering, 42% complete)

      physicaldrive 1I:1:1 (port 1I:box 1:bay 1, SAS, 300 GB, OK)
      physicaldrive 1I:1:2 (port 1I:box 1:bay 2, SAS, 300 GB, Rebuilding)
      physicaldrive 1I:1:3 (port 1I:box 1:bay 3, SAS, 300 GB, OK)
      physicaldrive 1I:1:4 (port 1I:box 1:bay 4, SAS, 300 GB, OK)
      physicaldrive 2I:1:5 (port 2I:box 1:bay 5, SAS, 300 GB, OK)
      physicaldrive 2I:1:6 (port 2I:box 1:bay 6, SAS, 300 GB, OK)
      physicaldrive 2I:1:7 (port 2I:box 1:bay 7, SAS, 300 GB, OK)
      physicaldrive 2I:1:8 (port 2I:box 1:bay 8, SAS, 300 GB, OK, spare)

该公司的IT人员不知道驱动器发生故障并硬重置了服务器（以使其变得更好吗？）。

对运行繁忙的虚拟机的受损阵列执行此操作的有趣效果是：

缓存状态详细信息：当前阵列控制器上次重置或加电时，其电池/电容器支持的写缓存中存储了有效数据。这表明系统可能尚未正常关闭。阵列控制器已自动将此数据写入或尝试将数据写入驱动器。该消息将继续显示，直到阵列控制器的下一次重置或关机后再打开。

因此，即使系统突然停止运行，飞行中的数据也受到BBWC的保护。虚拟机均已正确恢复，系统现在处于良好状态。

除了“保存数据”之外，它们还可以用于其他方面。它们还擅长缓存（在高速缓存中）写入，从而通过保持磁盘写入队列较低来提高IO子系统的性能。对于交互式性能至关重要的服务器，例如Citrix XenApp或Windows Terminal Services，这尤其重要。

这对于Web服务器或文件服务器而言不太重要。您可能没有注意到，甚至习惯于有些滞后。但是，当您单击Office应用程序中的图标时，您会期望响应速度。您的首席执行官也是如此。