ระบบไฟล์ใดที่ให้การป้องกันที่ดีที่สุดสำหรับการรักษาความปลอดภัยข้อมูลจากความเสียหายเนื่องจากการสูญเสียพลังงาน?

ฉันใช้ระบบฝังตัวขนาดเล็กuClibcและbusyboxอิงกับอุปกรณ์ x86 ฉันใช้ initramfs แต่ฉันยังติดตั้งext3ไดเรกทอรีที่กำหนดเองบนอุปกรณ์แฟลชขนาดกะทัดรัดในโหมด IDE ที่ฉันใช้เพื่อเก็บข้อมูลบันทึกการวัดแบบถาวรที่สร้างขึ้นโดยแอปพลิเคชัน c ++ ที่เขียนขึ้นเอง ฉันเลือกext3ระบบไฟล์ตามที่แนะนำเพื่อความปลอดภัยต่อการสูญเสียพลังงานเมื่อใช้ CF ไดรฟ์ในโหมด IDE ในหนังสือสองเล่มที่ฉันอ่าน (การสร้างระบบ Linux ในตัวโดย Karim Yaghmour และEmbedded Linux Primerโดย Christopher Hallinan) นี่เป็นสิ่งสำคัญอย่างยิ่งและข้อมูลก็สำคัญ

อย่างไรก็ตามเนื่องจากความคิดเห็นบางส่วนในคำถามก่อนหน้าของฉันสับสนกับวิธีการคืนค่าไฟล์ ext3 เสียหายหากไฟฟ้าดับเกิดขึ้นในระหว่างการเขียนไฟล์มันจะปรากฏว่าในความเป็นจริงระบบไฟล์นี้ไม่ได้รับประกันความปลอดภัยต่อข้อมูลเสียหายเนื่องจากพลังงาน การสูญเสีย ดังนั้นฉันต้องการทราบว่า

1. เป็นext3ตัวเลือกที่ดีที่สุดสำหรับการตั้งค่านี้หรือไม่
2. การสูญเสียพลังงานในระหว่างการดำเนินการเขียนดิสก์จะทำให้เฉพาะส่วนของข้อมูลที่ฉันผนวกเข้ากับไฟล์เป็นระยะหรือทำให้ไฟล์ทั้งหมดเสียหายหรือไม่?
3. ข้อมูลที่ไม่ได้ถูกเขียน ณ จุดที่สูญเสียพลังงานปลอดภัยอย่างสมบูรณ์หรือไม่? โดยเฉพาะมีความเสี่ยงที่initramfs.cpioไฟล์ของฉันจะเสียหายด้วยหรือไม่?
4. มีวิธีใดบ้างที่ฉันสามารถใช้ในรหัสแอปพลิเคชันของฉันเพื่อปกป้องข้อมูล (เช่นการสร้างพาร์ติชันพิเศษและเขียนข้อมูลของฉันไปยังมิเรอร์รูปภาพเพื่อให้มีสำเนาเสมอ 2) - ความเร็วไม่ใช่เรื่องจริงสำหรับแอปพลิเคชันของฉัน เป็นที่ยอมรับ

ฉันได้เห็นและอ่านคำตอบสำหรับคำถามที่เกี่ยวข้องนี้แล้ว: การทำเจอร์นัลระบบไฟล์รับประกันความเสียหายหลังเกิดไฟฟ้าขัดข้องหรือไม่? แต่มันไม่ครอบคลุมสิ่งที่ทำให้ฉันสับสน

ฉันรู้ว่าฉันกำลังถามคำถามมากมาย แต่ดูเหมือนว่าแม้จะอ่านเนื้อหามากมายฉันมีความล้มเหลวขั้นพื้นฐานในการทำความเข้าใจความเสี่ยงต่อข้อมูลของฉันในกรณีที่ไฟฟ้าดับ

เช่นเดียวกับทุกสิ่งที่เกี่ยวข้องกับความปลอดภัยไม่มีการรับประกันใด ๆ แต่คุณยังต้องสร้างสมดุลระหว่างความเสี่ยง (และต้นทุน) เทียบกับความน่าจะเป็น จากประสบการณ์ (และฉันใช้กล่อง * nix หลายสิบกล่องตั้งแต่ยุคมืด) ฉันไม่เคยมีความเสียหายกับระบบไฟล์ที่เกิดจากพลังงาน

เครื่องเหล่านี้บางเครื่องยังทำงานบนระบบไฟล์ที่ไม่ใช่ journalled (โดยปกติคือ ufs และ ext2) บางส่วนฝังอยู่และบางรุ่นเป็นโทรศัพท์มือถือเช่น Nokia N900 ดังนั้นแหล่งจ่ายไฟที่ดีไม่ได้รับประกันเลย

ไม่ใช่ว่าความเสียหายของระบบไฟล์ไม่สามารถเกิดขึ้นได้ แต่ความน่าจะเป็นที่จะเกิดขึ้นนั้นต่ำพอที่จะไม่ทำให้คุณกังวล ยังไม่มีเหตุผลที่จะไม่ป้องกันการเดิมพันของคุณ

ในการตอบคำถามตามตัวอักษรของคุณ:

1. อย่างน้อยหนังสือเล่มแรกที่คุณอ้างถึงเขียนขึ้นก่อนext4- เมื่อผู้เขียนแนะนำให้ใช้ext3พวกเขากำลังพูดว่า 'อย่าใช้ระบบไฟล์ที่ไม่เสถียรหรือไม่ใช่ journalled เช่นext2') ลองใช้ext4มันค่อนข้างเป็นผู้ใหญ่และมีตัวเลือกที่เหมาะสมสำหรับดิสก์ที่ไม่หมุนซึ่งอาจยืดอายุการใช้งานของอุปกรณ์แฟลชของคุณ
2. โอกาสที่มันจะทำให้คุณสูญเสียบล็อกหรือสองไฟล์สุดท้ายไม่ใช่ไฟล์ทั้งหมด ด้วยระบบไฟล์ที่ถูกเจอร์นัลสิ่งนี้จะเกี่ยวกับการสูญเสียเท่านั้น มีสถานการณ์ความล้มเหลวที่ฉันสามารถดูข้อมูลแบบสุ่มที่ฉีดข้ามไฟล์ได้ แต่พวกเขาดูเหมือนจะมีความเป็นไปได้ที่การตีอย่างแรงระดับไมโครเมตรผ่านอุปกรณ์ฝังตัวของคุณ
3. ดู 2. ไม่มีอะไรปลอดภัย 100.00%

4. หากคุณมีช่องสัญญาณ IDE ตัวที่สองให้ใส่การ์ด CF ตัวที่สองลงไปแล้วทำการสำรองระบบไฟล์เป็นระยะ มีไม่กี่วิธีที่จะทำนี้: rsync, cp dump, dd, แม้จะใช้md(4)(ซอฟต์แวร์ RAID) อุปกรณ์ (คุณเพิ่มไดรฟ์ที่สองเป็นครั้งคราวให้มันซิงค์แล้วเอามัน - ถ้าอุปกรณ์ทั้งสองมีชีวิตอยู่ตลอดเวลาที่พวกเขาใช้ความเสี่ยงเหมือนกัน ของความเสียหายของระบบไฟล์) หากคุณใช้ LVM คุณสามารถคว้าสแนปชอตได้ สำหรับอุปกรณ์ที่ฝังตัวในการเก็บรวบรวมข้อมูลฉันจะใช้วิธีแก้ปัญหาแบบเฉพาะกิจซึ่งเมานต์ระบบไฟล์ที่สองคัดลอกไปยังบันทึกข้อมูลและยกเลิกการต่อเชื่อมทันที หากคุณกังวลเกี่ยวกับอุปกรณ์ที่มีอิมเมจสำหรับบูตที่ดีให้ติดสำเนาตัวจัดการการบูตตัวที่สองและอิมเมจสำหรับการบูตที่จำเป็นทั้งหมดบนอุปกรณ์ตัวที่สองและกำหนดค่าคอมพิวเตอร์ให้บู๊ตจาก CF การ์ดตัวใดตัวหนึ่ง

   ฉันจะไม่เชื่อถือสำเนาที่สองบนอุปกรณ์เดียวกันเพราะอุปกรณ์เก็บข้อมูลล้มเหลวบ่อยกว่าระบบไฟล์ที่เสถียร จากประสบการณ์ของฉันบ่อยครั้งมากขึ้น (ที่ทำงานมีเรื่องตลกครึ่งขมเกี่ยวกับโอกาสที่สูงอย่างไม่น่าเชื่อของความล้มเหลวของดิสก์ในบ่ายวันศุกร์มันเกือบจะเป็นเหตุการณ์รายสัปดาห์อยู่พักหนึ่ง) ไม่ว่าดิสก์จะหมุนหรือไม่ก็อาจล้มเหลวได้ ดังนั้นเก็บไข่ไว้ในตะกร้าสองใบถ้าทำได้และคุณจะปกป้องข้อมูลของคุณได้ดีขึ้น

   หากข้อมูลมีความละเอียดอ่อนโดยเฉพาะฉันจะจ่ายการเข้าชมอุปกรณ์เป็นประจำแลกเปลี่ยน CF สำรองเพื่อรับข้อมูลใหม่และรีบูตเครื่องเพื่อให้fsckระบบไฟล์ทั้งหมดของมันมีขนาดที่ดี

สำหรับฉันแล้วดูเหมือนว่าการใช้งานระบบไฟล์ในกรณีที่ไฟฟ้าดับอย่างกะทันหันมีข้อ จำกัด - หลังจากทั้งหมดมันเชื่อมต่อกับฮาร์ดแวร์ดังนั้นสิ่งที่เกิดขึ้นระหว่างเวลาที่ส่งข้อมูล / คำแนะนำไปยังฮาร์ดแวร์และเมื่อมัน ได้รับการตอบสนองอยู่นอกเหนือการควบคุม หากมีระบบไฟล์ที่สามารถหลีกเลี่ยงปัญหานี้คุณจะเคยได้ยินมัน

ด้วยเหตุนี้กลยุทธ์ในการปกป้องข้อมูลที่สำคัญจะได้รับประโยชน์สูงสุดจากการตัดสินใจในระดับฮาร์ดแวร์เช่นโดยการใช้แหล่งจ่ายไฟสำรอง อาจเป็นไปไม่ได้ในสถานการณ์ของคุณ

fsync()ท่านได้กล่าวว่าผลการดำเนินงานไม่ได้จริงๆปัญหาใหญ่เพื่อให้ใช้ฉลาดของ

การสูญเสียพลังงานในระหว่างการดำเนินการเขียนดิสก์จะทำให้เฉพาะส่วนของข้อมูลที่ฉันผนวกเข้ากับไฟล์เป็นระยะหรือทำให้ไฟล์ทั้งหมดเสียหายหรือไม่?

ฉันใช้ระบบไฟล์ extN เป็นการส่วนตัวและบนเซิร์ฟเวอร์อินเทอร์เน็ตที่มีปริมาณการใช้งานปานกลางมานานหลายปีและเช่นเดียวกับ Alexios ฉันไม่เคยเห็นความเสียหายมากมายเนื่องจากไฟฟ้าขัดข้อง (แม้ว่าจะยุติธรรม แต่เซิร์ฟเวอร์มี UPS และฉันจำไม่ได้ หนึ่งในนั้นกำลังจะลงมาทางนั้น) ปัญหาที่ร้ายแรงกว่านั้นคือความเสียหายจากความล้มเหลวของฮาร์ดแวร์ซึ่งระบบไฟล์ที่แตกต่างกันอาจมีความสามารถมากขึ้นในการจัดการกับปัญหา แต่อีกครั้งนี่เป็นสิ่งที่อยู่นอกเหนือการควบคุมและไม่สามารถป้องกันได้

บางครั้งฉันเห็นไฟล์สูญหายหรือถูกตัดให้เหลือขนาดศูนย์ ฉันคิดว่ามีโอกาสที่ดีที่สิ่งเหล่านี้จะสามารถกู้คืนได้อย่างใด นี่ไม่จำเป็นสำหรับฉันเมื่อพวกเขาสำรอง ส่วนใหญ่ถ้ามีอะไรผิดปกติfsckดูเหมือนว่าจะจัดการกับมัน

ข้อมูลที่ไม่ได้ถูกเขียน ณ จุดที่สูญเสียพลังงานปลอดภัยอย่างสมบูรณ์หรือไม่? โดยเฉพาะมีความเสี่ยงใด ๆ ที่ไฟล์ initramfs.cpio ของฉันจะเสียหายหรือไม่

ฉันคิดว่าความเสี่ยงนั้นต่ำมากจริง ๆ จากความล้มเหลวของพลังงานยกเว้นการจัดเก็บข้อมูลแฟลชแบบคอร์รัปชั่นอาจมีสาเหตุมาจากไฟกระชากที่สามารถติดตามความล้มเหลวของพลังงาน - ซึ่งฉันไม่มีประสบการณ์ด้วย แต่หวังว่าคุณจะคิดถึง และค้นคว้าสิ่งนี้

มีวิธีใดบ้างที่ฉันสามารถใช้ในรหัสแอปพลิเคชันของฉันเพื่อปกป้องข้อมูล

คุ้มค่าการทำซ้ำจุดเกี่ยวกับfsync () วัตถุ C ++ / iostream ไม่มีวิธีการนี้ (:: flush และ :: sync ไม่ใช่ fsync) แต่สิ่งที่คุณต้องมีก็คือ file descriptor

ZFS เป็นระบบไฟล์ที่ป้องกันการทุจริตโดยการออกแบบและอาจเป็นระบบเดียวเท่านั้น อย่างไรก็ตามฉันไม่แน่ใจเกี่ยวกับความพร้อมใช้งานของการใช้ ZFS (ทั้งแบบฟิวส์หรือแบบดั้งเดิม) สำหรับแพลตฟอร์มที่ใช้ uClinux

มีระบบไฟล์เชิงพาณิชย์อย่างน้อยหนึ่งระบบที่ทำงานได้อย่างยอดเยี่ยมเพื่อให้แน่ใจว่าระบบไฟล์เกือบจะไม่สามารถเสียหายได้เนื่องจากความล้มเหลวด้านพลังงานและข้อมูลที่คุณเสี่ยงต่อการสูญเสียคือข้อมูลที่ถูกเพิ่มเข้ามาขณะที่กำลังดับ

ข้อเสียคือราคาแพงมากส่วนด้านบนนั้นให้การสนับสนุนที่ดี เนื่องจากค่าใช้จ่ายเป็นเพียงตัวเลือกสำหรับเดิมพันสูงและ / หรือผลิตภัณฑ์ที่มีปริมาณมากเท่านั้น เช่นเดียวกับอุปกรณ์ฝังตัวที่สำคัญเช่นการผลิตน้ำมันและก๊าซที่ต้องการความมั่นใจในความสมบูรณ์ของระบบภายใต้สภาพการทำงาน "ไม่แน่นอน" (เช่นไฟฟ้าดับบ่อย ฯลฯ )

ตรวจสอบDataLight (บริษัท )และ / หรือผลิตภัณฑ์ " Reliance NITRO " (Reliance เป็นโซลูชันที่ปลอดภัยและมีประสิทธิภาพ แต่ไม่ได้ผลมากโดยReliance NITRO ) แม้ว่าคุณจะไม่มีเงินที่จะใช้ระบบนี้พวกเขามีบทความที่ดีเกี่ยวกับการทำงานของระบบทำไมมันจึงเชื่อถือได้มากกว่าเช่น ext3 และ ext4

ฉันขอโทษถ้าสิ่งนี้อ่านเหมือนโฆษณาอยากจะชี้ให้เห็นตัวเลือก