ทางเลือกในการสำรองข้อมูลเครือข่าย


11

ในสภาพแวดล้อมของเราเรามีเซิร์ฟเวอร์บางตัวที่อยู่ในกลุ่ม Always On Availability และบางเซิร์ฟเวอร์เป็นแบบสแตนด์อโลน

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

สคริปต์ของ Ola hallengren กำลังถูกใช้กับการบีบอัดและยังแยกไฟล์สำรองข้อมูล ฉันกำลังทำการสำรองข้อมูล "เต็มรูปแบบ" ทุกวันเท่านั้น การสำรองข้อมูลจะไปที่ไดรฟ์เครือข่ายแบ่งปัน EMC isilon

ฉันไม่เคยพอใจกับ EMC DD Boost ทางเลือกเดียวคือทำการสำรองข้อมูลในเครื่องแล้วคัดลอกไปยังเครือข่ายเดียวกัน

มีวิธีที่มีประสิทธิภาพนอกเหนือจากข้างต้นหรือไม่


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

คำตอบ:


10

ตัวเลือกที่คุณกล่าวถึงน่าจะเป็นตัวเลือกที่ดีที่สุด

สิ่งที่คุณสามารถทำได้คือกระบวนการ 2 ขั้นตอน:

  • ใช้การสำรองข้อมูลเซิร์ฟเวอร์ sql แบบเนทีฟพร้อมการบีบอัดโดยใช้โซลูชันสำรองข้อมูลของ Ola ภายในเครื่อง
  • ใช้ Robocopy เพื่อถ่ายโอนไปยังเครือข่ายที่ใช้ร่วมกัน นี่เป็นการแยกส่วนและสามารถทำงานเป็นงานที่กำหนดเวลาไว้กับ Windows

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

อีกทางหนึ่งตามคำแนะนำของ Max Vernon ให้ทำ Robocopy เป็นขั้นตอนในงานสำรองเพื่อให้แน่ใจว่า robocopy จะเกิดขึ้นก็ต่อเมื่อการสำรองข้อมูลเสร็จสมบูรณ์และเร็วที่สุดหลังจากการสำรองข้อมูลเสร็จสมบูรณ์ การสำรองข้อมูลมีความเสี่ยงเช่นเดียวกับข้อมูลตราบใดที่ยังคงอยู่ในพื้นที่

นอกจากนี้ให้ทดสอบการกู้คืนของคุณอย่างสม่ำเสมอเพราะหากคุณไม่สามารถกู้คืนการสำรองข้อมูลได้ - มันมีจุดประสงค์อะไร!

นอกจากนี้โปรดดูคำตอบของฉันเกี่ยวกับSQL Backup การปรับฐานข้อมูลขนาดใหญ่


15

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

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

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

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

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


9

โซลูชั่นที่เป็นไปได้สองอย่าง:

  1. การเปลี่ยนจากการสำรองข้อมูลเต็มไปสู่การสำรองข้อมูลเต็มรูปแบบรายสัปดาห์และส่วนต่างรายคืนอาจเป็นวิธีแก้ปัญหาที่ง่าย
  2. มีพารามิเตอร์ที่เกี่ยวข้องกับประสิทธิภาพหลายอย่างที่คุณสามารถปรับแต่งในสคริปต์ของ Ola คุณอาจสามารถปรับแต่งพารามิเตอร์เหล่านี้เพื่อรับประสิทธิภาพตามที่คุณต้องการ:

    • BlockSize
      ระบุขนาดบล็อกแบบฟิสิคัลเป็นไบต์

      ตัวเลือก BlockSize ใน DatabaseBackup ใช้BLOCKSIZEตัวเลือกในคำสั่ง SQL Server BACKUP

    • BufferCount
      ระบุจำนวนของบัฟเฟอร์ I / O ที่จะใช้สำหรับการดำเนินการสำรองข้อมูล

      ตัวเลือก BufferCount ใน DatabaseBackup ใช้BUFFERCOUNTตัวเลือกในBACKUPคำสั่งSQL Server

    • MaxTransferSize ระบุหน่วยการโอนที่ใหญ่ที่สุดเป็นไบต์ที่จะใช้ระหว่าง SQL Server และสื่อสำรองข้อมูล

      ตัวเลือก MaxTransferSize ใน DatabaseBackup ใช้MAXTRANSFERSIZEตัวเลือกในBACKUPคำสั่งSQL Server


5

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

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

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

เราใช้ EMC DD Boost และคุณยินดีรับฟังความคิดเห็นของคุณเอง แต่เราได้พบว่าเนื่องจากวิธีการทำสำเนาฝั่งไคลเอ็นต์ที่ใช้การสำรองข้อมูลเต็มรูปแบบของฐานข้อมูลแบบหลาย TB อาจทำได้รวดเร็วมาก จนถึงจุดที่เราไม่ต้องกังวลกับการสำรองข้อมูลต่างกันของ SQL Server โดยการใช้ EMC DD คุณกำลังทำการสำรองข้อมูลต่างกันไม่ใช่ใน SQL Server การใช้ไฟล์ปลายทางหลายไฟล์ยังช่วยเพิ่มความเร็วได้อย่างมากแม้ใน DDBoost

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