有没有办法保护 SSD 免于因断电而损坏？

Question

我们有一组安装了 Linux、本地 Web 服务器和 PostgreSQL 的消费者终端。我们正在收到有关机器出现问题的现场报告，经过调查，似乎停电了，现在磁盘有问题。

我原以为问题只是数据库损坏，或者最近更改的文件被打乱了，但还有其他奇怪的报告。

• 权限错误的文件
• 已成为目录的文件（例如，index.php现在是目录）
• 已成为文件的目录
• 带有加密数据的文件

数据库损坏存在问题，但这是我可以预料的。我更惊讶的是更基本的文件系统问题——例如，权限或将文件更改为目录。这些问题也发生在最近没有更改的文件中（例如，软件代码和配置）。

这是 SSD 损坏的“正常”吗？最初我们认为它发生在一些便宜的 SSD 上，但我们在名牌（消费级）上发生了这种情况。

FWIW，我们不会在不干净的启动上执行 autofsck（不知道为什么 - 我是新手）。我们在某些地方安装了 UPS，但有时它没有正确完成等。这应该是固定的，但即便如此，人们仍然可以不干净地关闭终端等 - 所以它不是万无一失的。文件系统是ext4。

问题是：我们可以做些什么来缓解系统级别的问题？

我发现一些文章提到关闭硬件缓存或以同步模式安装驱动器，但我不确定这在这种情况下是否有帮助（元数据损坏和非最近更改）。我还阅读了有关以只读模式挂载文件系统的参考资料。我们不能这样做，因为我们需要编写，但如果有帮助，我们可以为代码和配置创建一个只读分区。

这是一个驱动器的例子sudo hdparm -i /dev/sda1：

Model=KINGSTON RBU-SMS151S364GG, FwRev=S9FM02.5, SerialNo=<deleted>
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=unknown, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=125045424
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes:  pio0 pio3 pio4
DMA modes:  mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
AdvancedPM=yes: disabled (255) WriteCache=enabled
Drive conforms to: Unspecified:  ATA/ATAPI-3,4,5,6,7

Answer 1

当突然断电时，MLC/TLC/QLC SSD有两种故障模式：

• 它们丢失了进行中和仅在 DRAM 中的写入；
• 它们可以破坏存储在正在编程的 NAND 单元较低页面中的任何静态数据。

第一个故障条件很明显：如果没有电源保护，任何不在稳定存储（即：NAND 本身）上而是仅在易失性缓存（DRAM）上的数据都将丢失。经典机械磁盘也会发生同样的情况（仅此一项就会对无法正确发出 fsync 的文件系统造成严重破坏）。

第二个故障条件是 MLC+ SSD 问题：当重新编程高页位以存储新数据时，意外断电也可能破坏/更改低位（即：先前提交的数据）。

唯一正确且最明显的解决方案是集成一个断电保护的 DRAM 缓存（通常使用电池/超级电容），就像高端 RAID 控制器一直以来所做的那样；然而，这会增加驱动器成本/价格。消费类驱动器通常没有断电保护缓存；相反，他们使用了一系列更经济的解决方案：

• 部分受保护的写缓存（即：Crucial M500/M550/M600+）；
• NAND 更改日志（即：三星驱动器，参见 SMART PoR 属性）；
• 特殊的 SLC/伪 SLC NAND 区域来吸收新的写入，而之前的数据没有风险（即：Sandisk、三星等）。

回到你的问题：你的金石驱动器是超便宜的，使用未指定的控制器，基本上没有公共规格。突然断电破坏了以前的数据并不令我感到惊讶。不幸的是，即使禁用磁盘的DRAM高速缓存（与它的命令大量的性能损失）将不会解决你的问题，因为以前的数据（即：数据静止）就可以了，会，被unexptected功率损耗损坏。如果它们基于旧的 Sandforce 控制器，则在“正确”的情况下甚至可以预期整个驱动块。

我强烈建议检查您的 UPS，并在中期更换这些老化的驱动器。

关于 PostgreSQL 和其他 Linux 数据库的最后一个注意事项：它们不会禁用磁盘的缓存，也不应该这样做。相反，他们会定期/必需的 fsyncs/FUA 将关键数据提交到稳定存储。除非存在非常令人信服的原因（即：存在与 ATA FLUSHES/FUA 相关的驱动器），否则应该这样做。

编辑：如果可能，请考虑迁移到校验和文件系统作为 ZFS 或 BTRFS。至少考虑 XFS，它有日志校验和，最近甚至元数据校验和。如果您被迫使用 EXT4，请考虑在启动时启用 auto-fsck（fsck.ext4 非常擅长修复损坏）。

Answer 2

是的。不要买超便宜的 SSD——低端消费市场以外的任何东西都有电容器和全面的断电保护。Amd 真的不会花那么多钱。

Answer 3

首先要做的是定义恢复时间和恢复点目标。您需要多长时间才能恢复这些终端之一，什么时间点的数据是可以接受的？也许在几个小时内您需要能够恢复到上周的备份。

如果在飞行中写入丢失，文件可能会发生各种奇怪的事情。文件系统的首要任务是维护自己的元数据一致性，它们可能无法为您的数据提供相同的保证。换句话说，fsck不能保证恢复您的数据。它的工作是为您提供一个可以挂载的文件系统。

所以，权力。安装、配置和测试 UPS 将正常关闭系统。这允许文件系统缓存和驱动器本身进行写入。

并且，写入磁盘的持久性。阅读PostgreSQL 的可靠性章节。使用diskchecker.pl链接到那里的脚本进行崩溃测试，并确定 SSD 是否在说谎是否写入到非易失性存储。如果有丢失，请考虑更换已知具有断电保护功能的 SSD。

编辑：您添加了启用写入缓存的详细信息。您可以尝试禁用该：hdparm -W0 /dev/sda或硬件阵列的适当命令。参考： RHEL 存储管理指南。

文件系统写屏障强制执行日志提交的顺序。它不能保证数据完好无损，但对于具有易失性缓存的文件系统来说更安全。尽管这是默认设置，但添加“屏障”挂载选项清楚地表明您重视一致性而不是性能。

最后，最后一道防线。进行恢复测试以确保您可以将应用程序和数据库及时恢复到所需的时间点。这对于各种数据丢失都很有用，而不仅仅是电源故障。