NetApp Snapshots สามารถใช้เป็นข้อมูลสำรองได้หรือไม่

ร้านค้าของเราพึ่งพา NetApp Volume Snapshots เป็นอย่างมากสำหรับการสำรองข้อมูล เราใช้การสำรองข้อมูลเทปแบบเอเจนต์แบบดั้งเดิมสำหรับข้อมูลบางส่วนของเรา แต่มีขนาดใหญ่และเราต้องพึ่งพา Snapshots สำหรับระบบส่วนใหญ่ของเรา นอกจากนี้เราไม่มีนโยบายการควบคุมการเปลี่ยนแปลงที่เข้มงวดหรือการจัดการการกำหนดค่าส่วนกลางดังนั้นทั้งหมดของเซิร์ฟเวอร์ของเราไม่ว่าจะสำรองข้อมูลที่ให้บริการไว้หรือไม่ก็ตามจะต้องทำการสร้างขึ้นมาใหม่จากโลหะเปลือย (และไม่มีเอกสารจริง) โดยธรรมชาติแล้วสิ่งนี้ทำให้ภาพรวมเป็นข้อเสนอที่น่าสนใจมากสำหรับการจัดการเพราะเราสามารถกู้คืนเซิร์ฟเวอร์ทั้งหมดข้อมูลผู้ใช้และการกำหนดค่าที่รวมอยู่ เราใช้คอนโซลการจัดเก็บข้อมูลเสมือนจริงของเน็ตแอพเพื่อสร้างสแนปชอตของดาต้าแวร์ VMware ที่ใช้ NFS ของเราและ SnapDrive ของเน็ตแอพสำหรับอุปกรณ์ดิบที่แมป (ฟิสิคัล) LUNs ที่นำเสนอโดยตรงกับแขก เรา SnapMirror ภาพรวมที่สำคัญนอกสถานที่ไปที่ Filer อื่น โดยปกติเราจะทดสอบกระบวนการกู้คืนเป็นประจำ

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

• การสำรองข้อมูลจะต้องเป็นแบบอะตอม กล่าวคือการสำรองข้อมูลไม่สามารถพึ่งพาสิ่งอื่นสำหรับการกู้คืน
• การสำรองข้อมูลจะต้องแยกออกจากระบบเป็นการสำรอง (นอกแบนด์)
• การสำรองข้อมูลจะต้องคัดลอกหรือขนส่งไปยังไซต์ระยะไกล (นอกไซต์)

ฉันเข้าใจว่า NetApp Snapshots ทำงานภายใต้วิธีการ Redirect-On-Write (RoW) WAFLรูปแบบไฟล์ที่ใช้ชุดของตัวชี้ (เมตาดาต้า?) ที่จริงอ้างอิงบล็อกของการจัดเก็บแต่ละที่เคยมันอาจจะ ในการสร้างสแน็ปช็อตระบบจะใช้สำเนาข้อมูลเมตาของโวลุ่มและเก็บไว้ในพื้นที่สงวนของโวลุ่มนั้น การเขียนใด ๆ (การสร้าง / การเปลี่ยนแปลง / การลบ) จะถูกเปลี่ยนเส้นทางไปยังบล็อกใหม่ นี่น่าจะเป็นซอสพิเศษที่ทำให้ WAFL ของเน็ตแอพดีเยี่ยมเพราะคุณไม่ได้อ่านและเขียนข้อมูลเก่าไปยังพื้นที่ที่สงวนไว้แล้วเขียนข้อมูลใหม่ของคุณบนสแน็ปช็อต Copy-On-Write

ฉันยอมรับอย่างเต็มที่ว่าฉันอาจไม่เข้าใจอย่างชัดเจนว่า NetApp Volume Snapshots ทำงานอย่างไร แต่หากความเข้าใจของฉันนั้นถูกต้องมากขึ้นหรือน้อยลง NetApp Snapshots ไม่เป็นไปตามเกณฑ์การสำรองข้อมูลของฉัน

• พวกมันไม่ใช่อะตอม "ภาพรวม" เป็นเพียงชุดตัวชี้ไปยังข้อมูลดั้งเดิม หากข้อมูลต้นฉบับไม่มีอยู่อีกต่อไปข้อมูลเมตาจะไม่มีประโยชน์
• ภาพรวมไม่ได้แยกออกจากระบบ หากมีคนลบโวลุ่มผิดฉันจะเสียสแนปชอต หาก NetApp Filer ระเบิดเป็นลูกแมวตัวจิ๋วตัวเล็กฉันจะเสียการสำรองข้อมูล ฉันสามารถใช้ SnapMirror เพื่อย้ายสแน็ปช็อตของฉันไปยังตัวกรองอื่น แต่อีกครั้งมันเป็นเพียงการย้ายเมทาดาทาไม่ใช่บล็อกจริง หากฉันทำโวลุ่มดั้งเดิมหายไปฉันจะไม่เห็นว่าสแนปช็อตที่คัดลอกไปยังตัวกรองอื่นจะช่วยอย่างไร

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

การสำรองข้อมูลทำหน้าที่สองฟังก์ชั่น

• ก่อนอื่นพวกเขาอยู่ที่นั่นเพื่อให้คุณสามารถกู้คืนข้อมูลของคุณหากไม่สามารถใช้งานได้ ในแง่นี้สแน็ปช็อตไม่ใช่การสำรองข้อมูล หากคุณสูญเสียข้อมูลในตัวกรอง (การลบโวลุ่มการจัดเก็บข้อมูลที่ผิดพลาดข้อผิดพลาดของเฟิร์มแวร์ ฯลฯ ) ภาพรวมทั้งหมดของข้อมูลนั้นก็จะหายไปเช่นกัน
• ประการที่สองและมากกว่าปกติจะใช้การสำรองข้อมูลเพื่อแก้ไขสิ่งต่าง ๆ เช่นการลบโดยไม่ตั้งใจ ในกรณีที่ใช้งานนี้สแน็ปช็อตคือการสำรองข้อมูล พวกเขาเป็นหนึ่งในวิธีที่ดีที่สุดในการกู้คืนข้อมูลประเภทนี้เนื่องจากพวกเขาทำให้ผู้ใช้หรือระบบปฏิบัติการรุ่นก่อนหน้าของพวกเขาเป็นไดเรกทอรีที่ซ่อนอยู่ใน. snapshot ที่พวกเขาสามารถอ่านไฟล์ได้โดยตรง

ไม่มีนโยบายการเก็บรักษา

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

ในปริมาณ Netapp ด้วยสแน็ปช็อตข้อมูลที่ถูกลบที่มีอยู่ในสแน็ปช็อตจะใช้พื้นที่ "snap Reserve" หากปริมาณไม่เต็มและคุณได้กำหนดค่าด้วยวิธีนี้คุณสามารถผลักดันการสำรองสแน็ปช็อตนั้นและมีสแนปชอตที่ครอบครองพื้นที่ข้อมูลที่ไม่ได้ใช้งานบางส่วน หากปริมาณการเติมเต็มภาพรวมทั้งหมด แต่คนที่ได้รับการสนับสนุนจากข้อมูลในพื้นที่ที่สงวนไว้จะถูกลบ การลบภาพรวมจะถูกกำหนดเท่านั้นโดยภาพรวมพื้นที่ที่มีอยู่และถ้ามันต้องการที่จะลบภาพรวมที่จำเป็นสำหรับนโยบายการเก็บรักษาของคุณก็จะ

พิจารณาสถานการณ์นี้:

• ปริมาณเต็มรูปแบบที่มีภาพรวมปกติและข้อกำหนดการเก็บรักษา 2 สัปดาห์
• สมมติครึ่งหนึ่งของปริมาณสำรองที่ใช้สำหรับสแน็ปช็อตตามอัตราการเปลี่ยนแปลงปกติ
• มีคนลบข้อมูลจำนวนมาก (มากกว่าสแน็ปช็อตสำรอง) เพิ่มอัตราการเปลี่ยนแปลงอย่างมากชั่วคราว

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

สรุป

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

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

พวกเขาคือการสำรองข้อมูลใช่ ฉันใช้มันเป็นการส่วนตัวแทนการเพิ่มทุกวันก่อน แต่เรายังคงทำเทปให้เต็มทุกสัปดาห์

พวกเขาปกป้องค่อนข้างดีจากข้อผิดพลาดหรือปัญหาของผู้ใช้ที่ไม่ใช่ netapp (ระบบการเข้าถึงปริมาณ) หรือผู้ดูแลระบบ

พวกเขาไม่ได้ป้องกันความล้มเหลวของฮาร์ดแวร์หายนะของเน็ตแอพเอง ความเข้าใจของฉันคือ SnapMirror จะคัดลอกข้อมูลทั้งหมด (ในภาพรวม) ไปยังไฟล์อื่น [1] ดังนั้น SnapMirroring ไปยังไฟล์อื่นควรปกป้องชุดข้อมูลนั้นจากความล้มเหลวของหายนะของฟิลเตอร์เดียว

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

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

คุณจะได้รับการสำรองข้อมูลที่ดีขึ้นของ VMs และฐานข้อมูลใด ๆ (หรือสิ่งที่คล้ายฐานข้อมูล) ถ้าคุณใช้เอเจนต์ SnapManager ที่เหมาะสมซึ่งจะประสานการระงับข้อมูลในเวลาสั้น ๆ เมื่อถ่ายภาพสแนปชอต หาก VM และข้อมูลที่ระบุมีอยู่ทั้งหมดภายในโวลุ่ม NetApp เดียวสแน็ปช็อตของ VM นั้นควรสอดคล้องกับความผิดพลาด นั่นคือมันควรจะดีเหมือนกับว่าคุณดึงปลั๊กบนเซิร์ฟเวอร์และถ่ายภาพไดรฟ์ซึ่งโดยทั่วไปจะหมายถึงการตรวจสอบระบบไฟล์และฐานข้อมูลเทียบเท่า หากข้อมูลของฐานข้อมูลถูกแบ่งระหว่าง LUN ดูเหมือนว่ามีความเสี่ยงที่สำคัญของข้อมูลเสียหาย

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

[1] http://www.netapp.com/us/system/pdf-reader.aspx?m=snapmirror.pdf&cc=us

คุณควรไปอ่านคำตอบที่ยอดเยี่ยมของ@Basilตอนนี้ แต่นี่คือสองเซ็นต์ของฉัน:

ไม่รู้จักแอปพลิเคชัน Snapshots

เพียงเพราะคุณถ่ายภาพสแนปชอตของโวลุ่มหน่วยเก็บข้อมูลพื้นฐานไม่ได้หมายความว่าข้อมูลในโวลุ่มนั้นจะสามารถกู้คืนได้ MS SQL เป็นตัวอย่างที่ดีในเรื่องนี้ - คุณต้องตรวจสอบให้แน่ใจว่าฐานข้อมูลของคุณสอดคล้องกับการทำธุรกรรมก่อนที่คุณจะทำการจัดเก็บที่ใช้เป็นอย่างอื่นเช่น@freiheit ที่กล่าวถึงว่าคุณไม่ได้ดีไปกว่าการกู้ DBA ชอบที่จะใช้ LUN ที่แตกต่างกันสำหรับส่วนต่างๆของ SQL เพื่อใช้ประโยชน์จากระบบจัดเก็บข้อมูลได้ดีขึ้นฐานข้อมูล temp บนที่จัดเก็บข้อมูลที่รวดเร็วฐานข้อมูลของระบบบนที่จัดเก็บข้อมูลที่ช้าลงอ่านอย่างเดียวหรือเก็บถาวร หากคุณเพียงแค่ถ่ายภาพปริมาณเหล่านั้นมันไม่น่าเป็นไปได้อย่างมากที่คุณจะสามารถกู้คืนฐานข้อมูลของคุณ

NetApp จัดหาเครื่องมือ Snap จำนวนหนึ่งเพื่อให้แอปพลิเคชันสแนปชอตทราบ SnapManager สำหรับ SQL ให้ความรู้นั้น ในระบบนิเวศของ Microsoft ฉันเชื่อว่ามีเครื่องมือ SnapManager สำหรับการแลกเปลี่ยนและ SharePoint SnapDrive ไม่มีการรับรู้แอปพลิเคชันนี้ มันเป็นเพียงวิธีการที่สะดวกในการจัดการพื้นที่เก็บข้อมูลภายในแขก

หากคุณกำลังจัดเก็บข้อมูล IIS และการกำหนดค่าทั้งหมดบน LUN และถ่ายภาพ LUN เหล่านั้นโดยตรงคุณไม่สามารถรับประกันได้ว่าข้อมูลจะกู้คืนได้ ถามฉันว่าฉันรู้ ...

ที่เก็บข้อมูลหลายประเภทสามารถมีกำหนดเวลาสแนปชอตที่แตกต่างกัน

หากคุณกำลังนำเสนอที่เก็บข้อมูลไปยังเซิร์ฟเวอร์ของคุณในรูปแบบที่แตกต่างกันสิ่งนี้อาจทำให้ภาพรวมและรูปภาพการกู้คืนของคุณยุ่งยาก ONTAP ของ NetApp เป็นข้อเสนอแบบหลายโปรโตคอลและเป็นไปได้มากที่คุณใช้มากกว่าหนึ่งวิธีหรือประเภทการจัดเก็บสำหรับเซิร์ฟเวอร์เฉพาะ ในร้านค้าของเราเซิร์ฟเวอร์บางแห่งของเราได้รับ C: \ Drive ผ่านที่เก็บข้อมูล NFS และไดรฟ์ "พื้นที่เก็บข้อมูล" ของพวกเขาผ่าน LUNs ที่แมปอุปกรณ์ดิบ เรากำลังถ่ายภาพสแนปชอตของ RDM LUN แต่ไม่ใช่ที่เก็บข้อมูลที่ใช้ NFS ทำให้การกู้คืนเซิร์ฟเวอร์ทำได้ยาก

ภาพรวมไม่มีนโยบายการเก็บรักษาที่รับประกัน

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

ภาพรวมเป็นแบบอินไลน์

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

ภาพรวมเปิดใช้งานแนวทางปฏิบัติในการปฏิบัติงานที่ไม่ดีเพื่อดำเนินการต่อ

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

แล้วภาพรวมมา! เราไม่จำเป็นต้องถอยกลับและกล่าวถึงการดำเนินงานพื้นฐานบางประการของเราเพราะเราสามารถจับภาพเซิร์ฟเวอร์ทั้งหมดของเราได้! และเราสามารถใช้ SnapMirror เพื่อย้ายสแน็ปช็อตเหล่านั้นนอกไซต์เพื่อให้เราสามารถใช้เป็นสำเนาสำรองได้!

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