สแน็ปช็อต + RAID นับเป็นโซลูชันการสำรองข้อมูลที่ดีหรือไม่

เหตุผลหลักสองประการที่ฉันคิดว่าสำหรับการสำรองข้อมูลดูเหมือนว่าจะได้รับการดูแลเมื่อฉันใช้ทั้ง snapshot และ RAID ร่วมกับ btrfs (โดย RAID ที่นี่ฉันหมายถึง RAID1 หรือ 10)

• การลบข้อมูลโดยไม่ตั้งใจ: ภาพรวมครอบคลุมกรณีนี้
• ความล้มเหลวของไดรฟ์และบิตเน่า
  • ความล้มเหลวโดยสมบูรณ์: RAID ครอบคลุมกรณีนี้
  • ไดรฟ์ส่งคืนข้อมูลที่ไม่ถูกต้อง: คุณลักษณะการแก้ไขข้อผิดพลาดของ RAID + btrfs ครอบคลุมกรณีนี้

ดังนั้นในฐานะโซลูชันสำรองในสถานที่ดูเหมือนว่าจะทำงานได้ดีและไม่จำเป็นต้องมีอุปกรณ์เก็บข้อมูลแยกต่างหากด้วยซ้ำ!

อย่างไรก็ตามฉันได้ยินมาว่าทั้ง RAID และสแน็ปช็อตไม่ถือว่าเป็นการสำรองข้อมูลที่เหมาะสมดังนั้นฉันจึงสงสัยว่าจะพลาดอะไรไปหรือเปล่า

นอกเหนือจาก btrfs ที่ไม่ได้เป็นเทคโนโลยีที่เป็นผู้ใหญ่แล้วคุณสามารถคิดถึงสิ่งที่ฉันพลาดไปได้หรือไม่? หรือความคิดของฉันถูกต้องและเป็นวิธีการสำรองข้อมูลในสถานที่ที่ถูกต้อง?

ไม่มันไม่ใช่.

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

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

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

และทดสอบเป็นประจำว่า 'สแนปชอตที่ส่งมา' ของคุณสามารถกู้คืนได้หรือไม่

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

ของหลักสูตรการสำรองข้อมูลที่ดีที่สุดคือเสมอนอกสถานที่ ดังนั้นหลังจาก 'จัดส่ง' สแน็ปช็อตไปยังระบบที่แยกต่างหากให้ทำ 'สแน็ปช็อตเทป' ของสแน็ปช็อตเป็นประจำ

ดังนั้นในระบบของฉันเซิร์ฟเวอร์ที่ได้รับสแนปชอตของสแน็ปช็อตจะดัมพ์พูล ZFS ทั้งหมด (รวมถึงสแน็ปช็อตก่อนหน้า) ทั้งหมดเป็นเทป

และแน่นอนทดสอบเทปของคุณเพื่อให้สามารถกู้คืนได้

หมายเหตุ: คุณจะต้องการให้สแน็ปช็อตเกิดขึ้นในระหว่างการทำกิจกรรมดิสก์ที่หยุดทำงานและควรประสานงานกับฐานข้อมูล (ถ้ามี) เพื่อให้แน่ใจว่ามีความสอดคล้อง มิฉะนั้นการรักษาอาจเลวร้ายยิ่งกว่าความเจ็บป่วย นั่นเป็นเหตุผลที่คุณสมบัติ 'Net Snapshot' ของ NetApp & EMC นั้นมีประโยชน์มาก: พวกเขาจะเลื่อนสแน็ปช็อตของ LUN ไปจนกระทั่งฐานข้อมูลที่ใช้ LUN ระบุว่าปลอดภัยที่จะทำสแน็ปช็อต

สิ่งที่ HopelessN00b พูด เลขที่

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

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

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

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

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

2) สแนปช็อต "เคี้ยวห่าง" พื้นที่ว่าง มันสมเหตุสมผลที่จะใช้ที่เก็บข้อมูลราคาแพงและรวดเร็วสำหรับข้อมูลที่มีอยู่ในปัจจุบันและสแน็ปช็อตโหลดและการสำรองข้อมูลซึ่งเป็นข้อมูลที่เป็นน้ำแข็ง ใช้งานได้ดีกับ 1) BTW

3) ภาพรวมมักจะทำให้กระบวนการทั้งหมดช้าลง ระบบส่วนใหญ่ใช้ Copy-on-Write และวิธีการนี้จะสร้างการกระจายตัว การเปลี่ยนเส้นทางเมื่อเขียนเร็วขึ้น แต่กินพื้นที่เยอะ มีผู้ค้าน้อยรายที่นำสแน็ปช็อตมาใช้อย่างเหมาะสม NetApp ที่มี WAFL และ Nimble Storage พร้อม CASL (ฉันไม่ได้เป็นส่วนหนึ่งของพวกเขา) ค่อนข้างทุกคนอื่นมีปัญหา ตัวอย่างเช่นทริกเกอร์ Dell Equallogic ทริกเกอร์การอัปเดตหน้า 15 MB (และของเสีย) ในทุก ๆ ไบต์เปลี่ยนไป นั่นคือราคาแพง

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

เพียงเพื่อยืนยัน - ก่อนที่ฉันจะให้คำแนะนำเพิ่มเติม ... คุณทำงานให้กับคู่แข่งของฉันใช่ไหม? คุณทำจริงเหรอ? ไม่มี? โอ้

ขออภัย NUTS ไม่เลย. ขอโทษนะเพื่อน

ปัญหาคือคุณเปิดรับข้อผิดพลาดใด ๆ ที่เกิดขึ้นใน (a) ระบบและ (b) ระดับระบบปฏิบัติการ โดยทั่วไปคุณจะป้องกันการลบข้อมูลบางอย่างเท่านั้น ดี นั่นเป็นข้อผิดพลาดที่เกิดขึ้นบ่อยครั้ง

สิ่งที่คุณไม่ได้ป้องกันคือ:

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

และรายการอื่น ๆ อีกมากมาย

นี่คือ - ยกเว้นคุณทำงานให้คู่แข่งของฉัน - คุณสำรองข้อมูลไว้เสมอ:

• บนคอมพิวเตอร์เครื่องอื่น
• ว่าคุณแยกออกจาก spikes พลังงานอย่างน้อย (แม้ว่าคุณจะเป็น USV)

นี่คือเหตุผลที่เทปหิน - พวกเขาไม่ได้เชื่อมต่อและอะไรไฟโอเอสั้น ๆ หรือน้ำท่วมจะไม่ทำร้ายพวกเขา Power spike - มีตัวอ่านเทปและอาจเป็นหุ่นยนต์ แต่เทปที่ไม่ได้อยู่ในเครื่องอ่านจะไม่ได้รับผลกระทบ

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

ตอนนี้คุณอาจคิดว่า "โอ้น้ำท่วมไม่เคยเกิดขึ้น" ตรวจสอบให้แน่ใจว่าคุณแน่ใจ ดูนี่คือวิดีโอของ 09.09.09 น้ำท่วมจากดาต้าโฟนดาต้าเซ็นเตอร์ ฉันแน่ใจว่าคุณจะเข้าใจว่าปัญหานี้เกิดจากการสำรองข้อมูล insite / ในคอมพิวเตอร์:

http://www.youtube.com/watch?v=ttcQy3bCiiU

บทเรียนที่เรียนรู้จากไดรฟ์ RAID-1 สองตัวที่ล้มเหลวภายในครึ่งชั่วโมงของกันและกัน: RAID ไม่ใช่กลไกการสำรองข้อมูลไม่ว่าในรูปแบบหรือรูปแบบใด

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

ผู้ดูแลระบบที่มีประสบการณ์หลายคนไปกับสิ่งที่เรียกว่ากฎการสำรองข้อมูล 3-2-1:

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

• คุณควรใช้วิธีสำรองข้อมูลอย่างน้อยสองวิธี

• คุณควรมีข้อมูลของคุณอย่างน้อยหนึ่งสำเนา

ภาพรวมละเมิดทั้งสามส่วน:

• คุณใช้เครื่องทางกายภาพเพียงเครื่องเดียวเท่านั้น อะไรก็ตามที่ส่งผลกระทบต่อทั้งเครื่องเช่นความล้มเหลวของ PSU สามารถนำข้อมูลทั้งหมดของคุณไปใช้ได้

• คุณใช้วิธีเดียวในการสำรองข้อมูล หากมีสิ่งใดผิดปกติคุณจะพบเมื่อกู้คืนข้อมูลสำรองในสถานการณ์วิกฤตเท่านั้น

• คุณไม่มีการสำรองข้อมูลนอกสถานที่ น้ำท่วมและไฟไหม้เกิดขึ้นเฉพาะกับคนอื่น ๆ จนกว่าพวกเขาจะเกิดขึ้นกับคุณ ...

ดังนั้น:

• คุณต้องมีข้อมูลสำรองอย่างน้อยหนึ่งรายการในเครื่องแยกต่างหากใน LAN ของคุณ

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

• คุณจำเป็นต้องมีการสำรองข้อมูลอย่างน้อยหนึ่งระยะไกลเท่าที่จะทำได้จากที่ตั้งปัจจุบันของคุณและแน่นอนไม่ได้อยู่ในอาคารเดียวกัน

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

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

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

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

แน่นอนว่ามันสามารถเป็นส่วนที่มีค่ามากของโซลูชันการสำรองข้อมูลที่มีความพร้อมใช้งานมากขึ้น:

• RAID plus snapshows บนฮาร์ดแวร์เดียวกัน
• การทำสำเนาในสถานที่บนฮาร์ดแวร์อื่น ๆ (โปรดจำไว้ว่า: มีโหมดความล้มเหลวที่จะนำกล่องทั้งตัวควบคุมไดรฟ์และทั้งหมดไปในครั้งเดียว)
• สำเนาระยะไกลกึ่งถอด
• และแน่นอนออฟไลน์ + ออฟไลน์ที่เหมาะสมสำหรับภัยพิบัติที่แท้จริง

ด้วย: ตรวจสอบให้แน่ใจว่าคุณทดสอบการสำรองข้อมูลเป็นประจำ เวลาที่เลวร้ายที่สุดในการค้นหาข้อมูลสำรองของคุณไม่ทำงานคือเมื่อคุณต้องการดึงข้อมูลบางอย่างจากพวกเขา ...