Existe-t-il un moyen de protéger le SSD contre la corruption due à une panne de courant?
Nous avons un groupe de terminaux grand public sur lesquels Linux, un serveur Web local et PostgreSQL sont installés. Nous obtenons des rapports sur le terrain des machines avec des problèmes et après enquête, il semble qu'il y ait eu une panne de courant et maintenant il y a un problème avec le disque.
J'avais supposé que le problème proviendrait simplement de la corruption de la base de données ou du brouillage des fichiers avec des modifications récentes, mais il existe d'autres rapports étranges.
- fichiers avec les mauvaises autorisations
- les fichiers qui sont devenus des répertoires (par exemple,
index.phpest maintenant un répertoire) - répertoires devenus des fichiers
- fichiers avec des données brouillées
Il y a des problèmes avec la base de données corrompue, mais c'est quelque chose à quoi je pouvais m'attendre. Ce qui me surprend le plus, ce sont les problèmes de base du système de fichiers - par exemple, les autorisations ou la modification d'un fichier dans un répertoire. Les problèmes se produisent également dans des fichiers qui n'ont pas changé récemment (par exemple, le code du logiciel et la configuration).
Est-ce "normal" pour la corruption de SSD? À l'origine, nous pensions que cela se produisait sur certains SSD bon marché, mais cela se produit sur une marque de marque (de qualité grand public.)
FWIW, nous ne faisons pas d'autofsck sur un démarrage impur (je ne sais pas pourquoi, je suis nouveau). Nous avons des onduleurs installés à certains endroits, mais parfois cela ne se fait pas correctement, etc. Cela devrait être corrigé, mais même alors, les gens peuvent éteindre le terminal de manière impure, etc. Le système de fichiers est ext4.
La question: pouvons-nous faire quelque chose pour atténuer le problème au niveau du système?
J'ai trouvé des articles faisant référence à la désactivation du cache matériel ou au montage du lecteur en mode synchronisation, mais je ne sais pas si cela pourrait aider dans ce cas (corruption de métadonnées et modifications non récentes). J'ai également lu une référence sur le montage du système de fichiers en mode lecture seule. Nous ne pouvons pas faire cela parce que nous devons écrire, mais nous pourrions faire une partition en lecture seule pour le code et la configuration si cela pouvait aider.
Voici un exemple de lecteur 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
En cas de perte soudaine de puissance, les SSD MLC/TLC/QLC ont deux modes de défaillance:
- ils perdent les écritures en vol et en DRAM uniquement;
- ils peuvent corrompre toutes les données au repos stockées dans la page inférieure de la cellule NAND en cours de programmation.
La première condition de panne est évidente: sans protection de l'alimentation, toutes les données qui ne sont pas sur un stockage stable (c'est-à-dire: NAND lui-même) mais uniquement sur un cache volatile (DRAM) seront perdues. La même chose se produit avec les disques mécaniques classiques (et cela seul peut faire des ravages sur le système de fichiers qui n'émet pas correctement fsyncs).
La deuxième condition d'échec est une affaire MLC + SSD: lors de la reprogrammation du bit de page haute pour stocker de nouvelles données, une perte de puissance inattendue peut détruire/altérer le bit inférieur (c'est-à-dire: précédent engagé données) également.
La seule vraie solution, et la plus évidente, consiste à intégrer un cache DRAM protégé contre les pertes de puissance (généralement à l'aide de batterie/supercaps), comme cela est fait depuis toujours par les contrôleurs RAID haut de gamme; cependant, cela augmente le coût/prix du lecteur. Les disques grand public n'ont généralement pas de caches protégés contre la perte de puissance; ils utilisent plutôt un éventail de solutions plus économiques comme:
- cache d'écriture partiellement protégé (par exemple: Crucial M500/M550/M600 +);
- NAND change de journal (c'est-à-dire: lecteurs Samsung, voir SMART PoR);
- des régions NAND SLC/pseudo-SLC spéciales pour absorber de nouvelles écritures sans données antérieures à risque (par exemple: Sandisk, Samsung, etc.).
Revenons à votre question: vos disques Kingstone sont ultra-bon marché, utilisant un contrôleur non spécifié et essentiellement aucune spécification publique. Cela ne m'étonne pas qu'une coupure de courant soudaine ait corrompu les données précédentes. Malheureusement, même la désactivation du cache DRAM du disque (avec l'énorme perte de performances qu'il commande) ne résoudra pas votre problème, comme les données précédentes (par exemple: data-at -rest) peut être et sera corrompu par des pertes de puissance inattendues. S'ils sont basés sur l'ancien contrôleur Sandforce, même une brique de lecteur totale peut être attendue dans les "bonnes" circonstances.
Je vous suggère fortement de revoir votre onduleur et, à moyen terme, de remplacer ces disques vieillissants.
Une dernière remarque à propos de PostgreSQL et des autres bases de données Linux: elles pas désactiveront le cache du disque et devraient pas être supposées le faire. Au lieu de cela, ils émettent des fsyncs/FUA périodiques/requis pour valider les données clés dans un stockage stable. C'est la façon dont les choses devraient être faites à moins qu'une raison impérieuse très existe (c'est-à-dire: un lecteur qui ment sur ATA FLUSHES/FUAs).
EDIT: si possible, envisagez de migrer vers un système de fichiers à somme de contrôle en tant que ZFS ou BTRFS. À tout le moins, considérons XFS, qui a une somme de contrôle de journal et, récemment, même une somme de contrôle de métadonnées. Si vous êtes obligé d'utiliser EXT4, pensez à activer l'auto-fsck au démarrage (fsck.ext4 est très bon pour réparer la corruption).
Ouais. Ne vous procurez pas de SSD super bon marché - tout ce qui se trouve en dehors du marché des consommateurs bas de gamme a des condensateurs et une protection complète contre les coupures de courant. AMD ne coûte vraiment pas beaucoup plus cher.
La première chose à faire est de définir le temps de récupération et les objectifs des points de récupération. De combien de temps disposez-vous pour récupérer l'un de ces terminaux et quel point de données dans le temps est acceptable? Peut-être que dans quelques heures, vous devez être capable de récupérer la sauvegarde de la semaine dernière.
Toutes sortes de choses étranges peuvent arriver aux fichiers si les écritures en vol sont perdues. La priorité du système de fichiers est de maintenir leur propre cohérence des métadonnées, ils peuvent ne pas fournir les mêmes garanties pour vos données. En d'autres termes, fsck n'est pas garanti pour récupérer vos données. Son travail consiste à vous procurer un système de fichiers à monter.
Alors, le pouvoir. Installez, configurez et testez que l'onduleur arrêtera le système correctement. Cela permet aux caches du système de fichiers et aux lecteurs eux-mêmes d'écrire.
Et, la durabilité des écritures sur les disques. Lire chapitre sur la fiabilité de PostgreSQL . Utilisez le diskchecker.pl script lié là pour faire un crash test et déterminer si les SSD mentent si les écritures ont atteint le stockage non volatile. En cas de perte, envisagez de les remplacer par des disques SSD connus pour être protégés contre les coupures d'alimentation.
Modifier: vous avez ajouté des détails indiquant que le cache d'écriture était activé. Vous pouvez essayer de désactiver cela: hdparm -W0 /dev/sda ou la commande appropriée pour une matrice matérielle. Référence: Guide d'administration du stockage RHEL .
Les barrières d'écriture du système de fichiers appliquent un ordre de validation de journal. Ce n'est pas une garantie que les données seront intactes, mais c'est plus sûr pour le système de fichiers avec un cache volatile. Bien qu'il s'agisse de la valeur par défaut, l'ajout de l'option de montage "barrière" documente clairement que vous accordez de la valeur à la cohérence par rapport aux performances.
Enfin, la dernière ligne de défense. Faites un test de restauration pour vous assurer que vous pouvez obtenir votre application et votre base de données au moment souhaité. Ceci est utile pour toutes sortes de pertes de données, pas seulement pour les pannes de courant.