การทำความเข้าใจผลกระทบ / ความเสี่ยงของการปิด“ ตรวจสอบความถูกต้องของข้อมูลสำรอง” ในการสำรองข้อมูล SQL


12

ขณะนี้เราใช้แผนการบำรุงรักษามาตรฐานสำหรับการสำรองข้อมูลบนเซิร์ฟเวอร์ SQL Server 2005/2008 / 2008R2 / 2012 ในสภาพแวดล้อมของเราและมีการทำเครื่องหมายในช่อง "ตรวจสอบความถูกต้องของการสำรองข้อมูลที่สมบูรณ์"

การสำรองข้อมูลบางอย่างใช้เวลานานมากดังนั้นฉันแนะนำให้ปิดตัวเลือกนั้น แต่ฝ่ายบริหารต้องการให้ฉันบันทึกผลกระทบและความเสี่ยงของการเปลี่ยนแปลงนี้

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

ฉันผิดหรือเปล่า? เป็นความเสี่ยงเพียงเล็กน้อยในการปิดการทำงานนี้หากฉันสำรองข้อมูลไว้ในดิสก์และไม่ทำการสตรีมเทปหรือบางสิ่งบางอย่าง (เราสำรองข้อมูลผ่านเครือข่ายไปยังอุปกรณ์สำรองข้อมูล EMC DD-800 หากมีความเกี่ยวข้อง)

มีคำแนะนำอย่างเป็นทางการของ MS สำหรับเมื่อใดที่ปลอดภัยที่จะปิด

คุณเรียกใช้ "ยืนยัน" ในการสำรองข้อมูลทุกครั้งในระบบของคุณหรือไม่? คุณตรวจสอบพวกเขาหรือไม่

แก้ไข : เพื่อชี้แจงเมื่อคุณทำเครื่องหมายที่ "ตรวจสอบความถูกต้องสำรองข้อมูล" ในแผนการบำรุงรักษา SQL จะทำการคืนค่าข้อมูลทั้งหมดในฐานข้อมูลแต่ละรายการทันทีหลังจากการสำรองข้อมูลแต่ละครั้ง นี่เป็นเพียงข้อมูล / IO มากเช่นเดียวกับการสำรองข้อมูลดั้งเดิมและ (โดยทั่วไป) จะเพิ่มเวลาโดยรวมของงานสำรองเป็นสองเท่า นี่ไม่เหมือนกับการเปิดใช้งานตัวเลือก "checksum" ในการสำรองข้อมูล (ซึ่งไม่สามารถทำได้ในตัวช่วยสร้างเท่าที่ฉันรู้)


ขอบคุณทุกคน เพิ่มอีกหนึ่งลิงก์สำหรับการอ้างอิงของฉันเองเกี่ยวกับการใช้แฟล็กการติดตามเพื่อเปิดใช้งาน checksum ในการสำรองข้อมูลแม้ว่าจะใช้แผนการบำรุงรักษาของ SQL: nebraskasql.blogspot.com/2014/03/ …
BradC

คำตอบ:


5

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

ไม่คุณพูดถูก :-)

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

วิธีที่ดีกว่าคือการสำรองข้อมูลของคุณเป็นระยะและทำการกู้คืนที่ถูกต้องบนเซิร์ฟเวอร์อื่นและดำเนินการ DBCC CHECKDB

นี่คือเหตุผลข้อหนึ่งทำไมฉันไม่ได้เป็นแฟนตัวยงของแผนการบำรุงรักษาเนื่องจาก GUI ไม่ได้เปิดเผยตัวเลือกมากมายเช่นbackup .. with CHECKSUMนั้นโดย T-SQL

จากบล็อก Myth ของ Paul Randal

24p) ใช้ RESTORE …กับ VERIFYONLY ตรวจสอบข้อมูลสำรองทั้งหมด

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

คุณเรียกใช้ "ยืนยัน" ในการสำรองข้อมูลทุกครั้งในระบบของคุณหรือไม่? คุณตรวจสอบพวกเขาหรือไม่

ฉันไม่เรียกใช้ VERIFYONLY แต่ฉันจะสำรองข้อมูลด้วย CHECKSUM จากนั้นให้พวกเขากู้คืน + CHECKDB'ed บนเซิร์ฟเวอร์อื่น คุณสามารถทำตาม สถิติการสุ่มตัวอย่างเพื่อตรวจสอบวิธีการสำรองฐานข้อมูลหากคุณต้องการสร้างสรรค์

นี่ไม่เหมือนกับการเปิดใช้งานตัวเลือก "checksum" ในการสำรองข้อมูล (ซึ่งไม่สามารถทำได้ในตัวช่วยสร้างเท่าที่ฉันรู้)

คุณสามารถเปิดใช้งานการติดตามสถานะ 3023เพื่อให้CHECKSUMตัวเลือกนั้นเปิดใช้งานโดยอัตโนมัติสำหรับคำสั่ง BACKUP เช่นเคยทดสอบพฤติกรรมของแฟล็กการติดตามใด ๆ ในสภาวะแวดล้อมของคุณ!

บรรทัดล่างคือ - แผนการบำรุงรักษาที่มีร่องและใช้โซลูชันสำรองข้อมูลที่สมเหตุสมผลมากขึ้น (คำแนะนำ: โซลูชันสำรองข้อมูลของ Ola)ที่จะช่วยให้คุณสามารถปรับแต่งได้ตามความต้องการของคุณ

(เราสำรองข้อมูลผ่านเครือข่ายไปยังอุปกรณ์สำรองข้อมูล EMC DD-800 หากมีความเกี่ยวข้อง)

สำรองข้อมูลภายในดิสก์แล้วมีงานถ่ายโอน PowerShell ที่จะคัดลอกข้อมูลสำรองจากเซิร์ฟเวอร์ไปยังเครือข่ายที่ใช้ร่วมกัน (เซิร์ฟเวอร์สำรอง) นั่นจะเร็วกว่าการคัดลอกไปยังเครือข่ายที่แชร์โดยตรง

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

การอ่านที่ดีจะเป็น: การสำรองข้อมูล: การวางแผนกลยุทธ์การกู้คืน


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

@BradC ดีใจที่คำตอบของฉันเป็นประโยชน์กับคุณ ส่วนสำคัญของคำตอบของฉันคือใช้TSQLเมื่อเทียบกับGUI(ดูแลแผนการ) เพื่อให้คุณสามารถใช้ประโยชน์จากความยืดหยุ่นและปรับใช้กับมือที่เปิดอยู่ แผนการบำรุงรักษาได้รับการปรับปรุงใน SQL Server 2016 CTP 2.4ซึ่ง MS เรียกว่าแผนการบำรุงรักษาสมาร์ทเซิร์ฟเวอร์ SQL - รวมแนวทางปฏิบัติที่ดีที่สุดและสามารถระบุกลยุทธ์ที่ดีที่สุดได้ทันที ยังไม่มี GUI ที่สามารถเอาชนะTSQL :-)
Kin Shah

ขอบคุณ @Kin ฉันคุ้นเคยกับวิธีสคริปต์แบบกำหนดเองทั้งหมดจากสภาพแวดล้อมอื่น ๆ อย่างชัดเจนว่าอาจมีปัญหาของตัวเองด้วยข้อผิดพลาดและการบำรุงรักษาสคริปต์ เรากำลังประเมินเอเจนต์การบีบอัดของบุคคลที่สามบางตัวดังนั้นจึงอาจจำเป็นต้องใช้สคริปต์ที่กำหนดเองในที่สุด
BradC

2

บรรทัดล่างคือถ้าคุณไม่ทำการกู้คืนฐานข้อมูลคุณไม่สามารถมั่นใจได้อย่างสมบูรณ์ว่าไฟล์สำรองที่กำหนดนั้นดี

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

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

ในที่สุดคุณคิดจะย้ายออกจากแผนการบำรุงรักษาหรือไม่? สคริปต์เช่นสคริปต์ของ Ola นั้นยกเว้นการสำรองข้อมูลและการบำรุงรักษา: https://ola.hallengren.com/


เราอาจย้ายออกจากแผนการบำรุงรักษาในอนาคตเนื่องจากเรากำลังประเมินตัวแทนสำรองข้อมูลบุคคลที่สามบางราย (ซึ่งทำงานกับอุปกรณ์สำรองข้อมูลเฉพาะของเรา) ฉันสมมติว่าสิ่งเหล่านี้จะต้องใช้สคริปต์ที่กำหนดเองคล้ายกับสิ่งที่ Ola ได้พัฒนาขึ้น
BradC

1

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


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

ถูกต้อง imo ตรวจสอบจริงเพียงอย่างเดียวคือทำการกู้คืนจริง
Gelder
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.