Quel système de fichiers offre la meilleure protection pour sécuriser les données contre la corruption due à une panne de courant?


9

Je courais un petit uClibcet busyboxsystème embarqué basé sur un dispositif x86. J'utilise un initramfs mais je monte également un ext3répertoire personnalisé sur un périphérique compact flash en mode IDE que j'utilise pour stocker des données d'enregistrement de mesure persistantes créées par une application c ++ écrite personnalisée. J'ai choisi le ext3système de fichiers car il est recommandé pour la sécurité contre les pertes de puissance lors de l'utilisation de lecteurs CF en mode IDE dans quelques livres que j'ai lus ( Building Embedded Linux Systems par Karim Yaghmour et Embedded Linux Primer par Christopher Hallinan). Ceci est particulièrement important et les données sont essentielles.

Cependant, en raison de certains des commentaires de ma question précédente Confusion avec la façon de restaurer des fichiers ext3 corrompus en cas de panne de courant pendant l'écriture d'un fichier, il semblerait qu'en fait, ce système de fichiers n'offre pas la garantie de sécurité contre la corruption de données due à l'alimentation perte. Je voudrais donc savoir si

  1. Est-ce ext3réellement le meilleur choix pour cette configuration?
  2. La perte de puissance pendant une opération d'écriture de disque ne corrompe-t-elle que périodiquement la partie des données que j'ajoute au fichier ou peut-elle corrompre l' intégralité du fichier?
  3. Les données qui ne sont pas écrites au moment de la coupure de courant sont-elles totalement sûres? En particulier, y a-t-il un risque que mon initramfs.cpiofichier soit également corrompu?
  4. Existe-t-il une méthode que je peux utiliser dans mon code d'application pour protéger les données (c'est-à-dire créer une partition supplémentaire et écrire mes données pour refléter les images afin qu'il y ait toujours 2 copies) - la vitesse n'est pas un vrai problème pour mon application, des opérations de copie si coûteuses sont acceptables.

J'ai vu et lu les réponses à cette question connexe: les systèmes de fichiers de journalisation garantissent-ils contre la corruption après une panne de courant? , mais cela ne couvre pas tout à fait certaines des choses qui me déroutent.

Je me rends compte que je pose beaucoup de questions, mais il semble qu'en dépit de la lecture de beaucoup de documents, j'ai eu un échec fondamental à comprendre les risques pour mes données en cas de panne de courant.

Réponses:


11

Comme pour tout ce qui concerne la sécurité, il n'y a aucune garantie, mais vous devez également équilibrer le risque (et le coût) par rapport à la probabilité. Par expérience (et j'exécute des dizaines de * nix boxen depuis les âges sombres), je n'ai jamais vraiment eu de corruption de système de fichiers causée par l'alimentation.

Certaines de ces machines fonctionnaient même sur des systèmes de fichiers non journalisés (ufs et ext2 en général). Certains d'entre eux étaient intégrés, et quelques-uns étaient des téléphones portables comme le Nokia N900 - donc une bonne alimentation n'était pas du tout garantie.

Ce n'est pas que la corruption du système de fichiers ne peut pas se produire, c'est juste que la probabilité qu'elle se produise est suffisamment faible pour que cela ne vous inquiète pas. Pourtant, aucune raison de ne pas couvrir vos paris.

En réponse à vos questions littérales:

  1. Au moins le premier livre ext4auquel vous avez fait référence a été écrit auparavant - lorsque l'auteur suggère d'utiliser ext3, ils disent vraiment «n'utilisez pas de systèmes de fichiers instables ou non journalisés comme ext2»). Essayez ext4, il est assez mature et propose des options décentes pour les disques qui ne tournent pas, ce qui peut prolonger la durée de vie de votre périphérique flash.
  2. Il y a de fortes chances que vous perdiez le dernier bloc ou les deux derniers, pas le fichier entier. Avec un système de fichiers journalisé, ce sera à peu près la seule perte. Il existe des scénarios d'échec où je pourrais voir des données aléatoires dispersées sur le fichier, mais elles semblent à peu près aussi probables qu'une micrométéorite se brisant directement à travers votre appareil intégré.
  3. Voir 2. Rien n'est sûr à 100,00%.
  4. Si vous avez un deuxième canal IDE, collez-y une deuxième carte CF et récupérez périodiquement une sauvegarde du système de fichiers. Il y a quelques façons de le faire: rsync, cp dump, dd, même en utilisant le md(4)dispositif (RAID logiciel) (vous ajoutez le deuxième disque de temps en temps, laissez - le synchroniser, puis retirez - si les deux appareils sont sous tension tout le temps, ils courent le même risque de corruption de système de fichiers). Si vous utilisez LVM, vous pouvez même saisir des instantanés. Pour un appareil intégré de collecte de données, je n'utiliserais qu'une solution ad hoc qui monte le deuxième système de fichiers, copie sur le journal de données, le démonte immédiatement. Si vous avez peur que l'appareil ait une bonne image de démarrage, collez une deuxième copie du gestionnaire de démarrage et toutes les images de démarrage nécessaires sur le deuxième appareil et configurez l'ordinateur pour démarrer à partir de l'une ou l'autre des cartes CF.

    Je ne ferais pas confiance à une deuxième copie sur le même appareil car les périphériques de stockage échouent plus souvent que les systèmes de fichiers stables. Beaucoup plus souvent, d'après mon expérience jusqu'à présent (au travail, il y avait une demi-blague amère sur les chances étrangement élevées de défaillances de disque vendredi après-midi. C'était presque un événement hebdomadaire pendant un certain temps). Que le disque tourne ou non, il peut échouer. Conservez donc vos œufs dans deux paniers si vous le pouvez, et vous protégerez mieux vos données.

    Si les données sont particulièrement sensibles, je rendrais régulièrement visite à l'appareil, j'échangerais la sauvegarde CF pour une nouvelle et redémarrerais, en lui laissant fscktous ses systèmes de fichiers pour faire bonne mesure.


+1, mais la réplication souffre des mêmes problèmes que la copie principale - si vous commencez à synchroniser deux périphériques (que ce soit via RAID ou un utilitaire de niveau supérieur) et que l'alimentation est coupée (alors qu'il y a des ajouts constants aux données), vous aurez récupérez les ordures. Ce qui pourrait aider, c'est d'avoir RAID1, de temps en temps, de changer physiquement l'un des périphériques et de faire une sauvegarde hors ligne de celui qui a été supprimé. Vous devrez cependant geler le FS avant de le supprimer, pour vous assurer qu'il est cohérent (c'est-à-dire faire des instantanés). XFS est l'un des systèmes de fichiers qui prennent en charge cela.
peterph

En effet. Comme je l'ai écrit, il n'y a aucune garantie. Chaque fois que vous écrivez des données, vous pourriez être corrompu. Les gens de electronics.stackexchange.com ont joué avec les supercondensateurs et la détection de panne de courant où le système intégré reçoit une notification de panne de courant et obtient toujours suffisamment de jus pour abandonner les écritures. Peut être. :) Tout dépend de la probabilité que vous pensiez que le danger potentiel est, et combien d'argent / d'efforts vous voulez dépenser pour éliminer le problème à portée de main (et commencer à considérer le prochain).
Alexios

Merci pour cette réponse. Cela clarifie considérablement les choses pour moi.
mathématicien1975

4

Il me semble que ce qu'une implémentation de système de fichiers peut réaliser en cas de coupure de courant soudaine est limité - après tout, il s'agit en fait d'une interface avec le matériel, alors que se passe-t-il entre le moment où il envoie des données / instructions au matériel et le moment où il obtient une réponse est hors de son contrôle. S'il y avait un système de fichiers qui pourrait contourner ce problème, vous en auriez entendu parler.

De ce fait, une stratégie de protection des données critiques bénéficiera le plus des décisions prises au niveau matériel , par exemple en utilisant une alimentation sans coupure. Ce n'est probablement pas si faisable dans votre situation.

Vous avez dit que les performances n'étaient pas vraiment un gros problème, alors utilisez-les judicieusement fsync().

La perte de puissance pendant une opération d'écriture de disque ne corrompe-t-elle que périodiquement la partie des données que j'ajoute au fichier ou peut-elle corrompre l'intégralité du fichier?

J'utilise des systèmes de fichiers extN personnellement et sur des serveurs Internet à faible trafic depuis des années, et comme Alexios, je n'ai pas vu beaucoup de corruption due à une panne de courant (bien que pour être juste, les serveurs ont UPS et je ne me souviens pas l'un d'eux descend en fait de cette façon). Un problème beaucoup plus grave est la corruption due à une défaillance matérielle, qui différents systèmes de fichiers peuvent (encore) être de plus en moins capables de traiter le problème, mais (encore une fois) cela est fondamentalement indépendant de leur volonté et ils ne peuvent pas l'empêcher.

J'ai parfois vu des fichiers perdus ou tronqués à zéro. Je présume qu'il y a de fortes chances que ceux-ci soient récupérables d'une manière ou d'une autre; ce n'était pas nécessaire pour moi car ils étaient sauvegardés. La plupart du temps, s'il y a quelque chose qui ne va pas, cela fscksemble régler le problème.

Les données qui ne sont pas écrites au moment de la coupure de courant sont-elles totalement sûres? En particulier, y a-t-il un risque que mon fichier initramfs.cpio soit également corrompu?

Je pense que le risque est vraiment très faible à cause d'une simple panne de courant, sauf que le type de stockage flash de corruption peut être sujet à cause de la surtension qui peut accompagner les pannes de courant - avec lesquelles je n'ai aucune expérience, mais j'espère que vous y avez pensé et fait des recherches sur cela.

Existe-t-il une méthode que je peux utiliser dans mon code d'application pour protéger les données?

Il vaut la peine de répéter le point sur fsync () . Les objets C ++ / iostream n'ont pas de méthode pour cela (:: flush et :: sync ne sont pas fsync), mais tout ce dont vous avez besoin est un descripteur de fichier.


Merci pour cette réponse, elle est également très utile. Je monte la partition qui est écrite via l' syncoption dans le /etc/fstabfichier car je comprends que cela force l'écriture à se produire de manière synchrone. Je suppose que cela signifie que lorsque mon code d'écriture de fichier revient, les données ont été physiquement écrites sur le disque. J'ai compris que le montage avec fait syncessentiellement la même chose que d'appeler fsync(my_filedescriptor)après une écriture. Ma compréhension de cela est-elle correcte?
mathématicien1975

@ mathématicien1975 Je suppose que ce n'est pas quelque chose que j'ai recherché. OMI, tant que cela n'est pas gênant, le fait de lancer fsync()à des points que vous jugez appropriés ne nuira pas de toute façon et rend le système plus robuste (par exemple, si l'appareil est monté de manière décontractée sans jeu de synchronisation, etc.).
goldilocks

1

ZFS est définitivement un système de fichiers protégé contre la corruption par sa conception et peut-être le seul. Cependant, je ne suis pas sûr de la disponibilité des implémentations ZFS (basées sur des fusibles ou natives) pour les plates-formes basées sur uClinux.


0

Il existe au moins un système de fichiers commercial qui fait un travail formidable en s'assurant que le système de fichiers ne peut presque pas être corrompu en raison de pannes de courant et que les seules données que vous risquez de perdre sont des données qui ont été ajoutées lors de la coupure de courant.

L'inconvénient est qu'il est très cher, ils offrent un excellent soutien. En raison des dépenses, ce n'est vraiment qu'une option pour les produits à enjeux élevés et / ou à volume élevé. Tout comme les équipements embarqués critiques dans la production de pétrole et de gaz, par exemple, qui doivent garantir l'intégrité du système dans des conditions de fonctionnement "incertaines" (par exemple, coupures de courant fréquentes, etc.).

Découvrez DataLight (société) et / ou le produit " Reliance NITRO ". (Reliance est leur solution héritée et sûre mais pas très efficace, remplacée par Reliance NITRO ). Même si vous n'avez pas d'argent pour utiliser ce système, ils ont de très bons articles expliquant comment leur système fonctionne, pourquoi il est plus fiable que par exemple ext3 et ext4.

Je m'excuse si cela se lit comme une annonce, je voulais simplement souligner les options.


Bonjour et bienvenue sur le site. Si vous souhaitez proposer des produits, veuillez i) fournir un lien vers le produit en question; ii) expliquer pourquoi elle est meilleure que les alternatives (vous prétendez simplement qu'elle fait un travail formidable mais n'expliquez pas pourquoi elle est meilleure qu'autre chose); iii) si vous êtes affilié à la société qui fait cela, vous devez le faire explicitement ou être accusé de spam (ne pas dire que vous êtes, juste un avertissement).
terdon
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.