有没有一种方法可以保护SSD避免由于断电而损坏？

我们有一组消费者终端，这些终端装有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

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

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

第一个故障情况很明显：没有电源保护，所有不在稳定存储（即NAND本身）上但仅在易失性缓存（DRAM）上的数据都将丢失。传统的机械磁盘也会发生相同的情况（而且仅此一项会严重破坏无法正确发出fsync的文件系统）。

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

唯一真正，最明显的解决方案是集成功耗保护的DRAM缓存（通常使用电池/超级电容），就像高端RAID控制器永远所做的那样。但是，这增加了驱动器成本/价格。消费类驱动器通常没有功耗保护的缓存；相反，他们使用一系列更经济的解决方案，例如：

• 部分受保护的写缓存（例如：Crucial M500 / M550 / M600 +）；
• NAND更改日志（即：Samsung驱动器，请参阅SMART PoR属性）；
• 特殊的SLC /伪SLC NAND区域可以吸收新的写入，而不会丢失以前的数据（例如Sandisk，Samsung等）。

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

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

关于PostgreSQL和其他Linux数据库的最后说明：它们不会禁用磁盘的缓存，因此不应被期望这样做。而是，它们发出定期/必需的fsyncs / FUA，以将关键数据提交到稳定的存储中。除非存在非常令人信服的原因（例如，有关ATA FLUSHES / FUA的驱动器），否则这是应该执行的方法。

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

是的 不要获得超级便宜的SSD-低端消费市场之外的任何东西都具有电容器和全面的功率损耗保护。Amd确实不花那么多钱。

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

如果在飞行中丢失写操作，文件可能会发生各种奇怪的事情。文件系统优先级是保持其自身的元数据一致性，它们可能无法为您的数据提供相同的保证。换句话说，fsck不能保证恢复您的数据。它的工作是让您挂载一个文件系统。

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

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

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

文件系统写障碍强制执行日记提交的顺序。它不能保证数据会完整无缺，但是对于具有易失性缓存的文件系统来说，它更安全。尽管这是默认设置，但添加“屏障”安装选项显然可以证明您重视一致性而不是性能。

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