Windows Server 2012 R2 Deduped 356GB เป็น 1.32GB


13

ฉันกำลังทดลองกับการทำซ้ำในพื้นที่เก็บข้อมูล Server 2012 R2 ฉันปล่อยให้มันรันการเพิ่มประสิทธิภาพ dedupe ครั้งแรกเมื่อคืนและฉันยินดีที่ได้เห็นว่ามันอ้างว่าลดลง 340GB

ป้อนคำอธิบายรูปภาพที่นี่

อย่างไรก็ตามฉันรู้ว่ามันดีเกินกว่าจะเป็นจริงได้ ในไดรฟ์นั้นการขจัดข้อมูลซ้ำซ้อน 100% มาจากการสำรองข้อมูล SQL Server:

ป้อนคำอธิบายรูปภาพที่นี่

ดูเหมือนว่าไม่สมจริงโดยพิจารณาว่ามีการสำรองฐานข้อมูลที่ขนาด 20 เท่าในโฟลเดอร์ ตัวอย่างเช่น:

ป้อนคำอธิบายรูปภาพที่นี่

ถือว่าเป็นไฟล์สำรองข้อมูลขนาด 13.3GB ที่มีการซ้ำซ้อนเป็น 0 ไบต์ และแน่นอนไฟล์นั้นไม่สามารถใช้งานได้จริงเมื่อฉันทำการทดสอบการกู้คืน

หากต้องการเพิ่มการดูถูกการบาดเจ็บมีโฟลเดอร์อื่นในไดรฟ์นั้นที่มีข้อมูลเกือบ TB ในนั้นควรซ้ำซ้อนมาก แต่ยังไม่ได้

การขจัดข้อมูลซ้ำซ้อนของเซิร์ฟเวอร์ 2012 R2 ทำงานได้หรือไม่


5
ฉันจะต้องจำไว้ "แน่นอนฉันไม่ได้ลบข้อมูลของคุณเพราะคุณทำให้ฉันโกรธฉันทำมันซ้ำซ้อนเป็น 0 ไบต์ทั้งหมด"
HopelessN00b

เป็นไปได้ไหมที่มันกำลังทำการลบข้อมูลโดยสมมติว่าข้อมูลค่อนข้างเหมือนกันจากคืนหนึ่งไปยังอีกวันถัดไป ความหมายถ้าคุณมีการสำรองข้อมูลครั้งแรกและครั้งสุดท้ายสิ่งเดียวในแต่ละคืนจะเป็นภาพรวมของความแตกต่างเช่น VSS ในทางทฤษฎีแล้วมันอาจเป็นไปได้ที่จะลดจำนวนเป็น 0 เนื่องจากสำเนาแรกและสุดท้ายอาจเพียงพอที่จะสร้างไฟล์ที่อยู่ตรงกลาง แต่เนื่องจากมันล้มเหลวในการกู้คืนฉันจะรอเพื่อดูสิ่งที่คุณคิดว่าเป็นคำอธิบาย แต่การทดสอบของคุณไม่ได้สัญญาว่า ..
MikeAWood

@ MikeAWood ยกเลิกการสำรองข้อมูลที่แตกต่างกันโดยสิ้นเชิงกับ 0 ไบต์เช่นกันซึ่งเป็นสิ่งที่ผิดอย่างแน่นอน หนึ่งในสิ่งที่ฉันต้องการให้ dedupe สำหรับคือในขณะที่คุณได้ชี้ให้เห็น 90% ของการสำรองข้อมูลจากคืนสู่คืนเหมือนกัน
Mark Henderson

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

@ MikeAWood - ฉันไม่ได้ลอง ฉันนับตั้งแต่ไดรฟ์นั้นและสร้างใหม่อีกครั้งด้วยการตั้งค่าที่ซ้ำซ้อนดังนั้นฉันจะเห็นว่าเกิดอะไรขึ้นในคืนนี้เมื่อมีการถ่ายโอนข้อมูลอีกครั้ง
Mark Henderson

คำตอบ:


5

การคัดลอกใช้งานไม่ได้

ด้วยการขจัดข้อมูลซ้ำซ้อนขนาดบนดิสก์จะไม่มีความหมาย ไฟล์ดังกล่าวไม่ใช่ "ไฟล์" ปกติ แต่เป็นจุดแยกย่อยและไม่มีข้อมูลจริง แต่เป็นข้อมูลเมตาสำหรับเอ็นจิ้นการลบไฟล์เพื่อสร้างไฟล์ใหม่ เป็นความเข้าใจของฉันที่คุณไม่สามารถรับการประหยัดต่อไฟล์ได้เนื่องจากที่เก็บข้อมูลขนาดใหญ่เป็นแบบต่อปริมาตรดังนั้นคุณจะได้รับการประหยัดแบบต่อปริมาณเท่านั้น http://msdn.microsoft.com/en-us/library/hh769303(v=vs.85).aspx

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

ฉันปรับใช้การหักข้อมูลซ้ำซ้อนในหลายระบบ (Windows 2012 R2) ในสถานการณ์ที่แตกต่างกัน (SCCM DP, ระบบการปรับใช้ที่แตกต่างกัน, ไฟล์เซิร์ฟเวอร์ทั่วไป, ไฟล์เซิร์ฟเวอร์โฮมโฟลเดอร์ของผู้ใช้ ฯลฯ ) ประมาณหนึ่งปีแล้ว เพียงตรวจสอบให้แน่ใจว่าคุณได้รับการแพตช์อย่างสมบูรณ์แล้วฉันจำได้ว่ามีแพทช์หลายตัวสำหรับการทำงานที่ซ้ำซ้อน (ทั้งการปรับปรุงที่สะสมและโปรแกรมแก้ไขด่วน) ตั้งแต่ RTM

อย่างไรก็ตามมีปัญหาบางอย่างที่บางระบบไม่สามารถอ่านข้อมูลโดยตรงจากไฟล์ที่ดีที่สุดในระบบภายใน (IIS, SCCM ในบางสถานการณ์) ตามที่แนะนำโดย yagmoth555 คุณควรลอง Expand-DedupFile เพื่อยกเลิกการขยายหรือเพียงแค่ทำสำเนาไฟล์ (ไฟล์เป้าหมายจะไม่ได้รับการปรับปรุงจนกว่าจะเพิ่มประสิทธิภาพครั้งต่อไป) และลองอีกครั้ง http://blogs.technet.com/b/configmgrteam/archive/2014/02/18/configuration-manager-distribution-points-and-windows-server-2012-data-deduplication.aspx https: //kickthatcomputer.wordpress .com / 2013/12/22 / ไม่มีการป้อนข้อมูลไฟล์ที่ระบุหน้าต่างเซิร์ฟเวอร์ 2012 dedupe-on-iis ที่มี PHP /

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


ขอบคุณสำหรับคำตอบ. คำตอบของคุณสะท้อนการค้นพบของฉัน ฉันมีความเข้าใจผิดเกี่ยวกับ dedupe และวิธีการทดสอบของฉันมีข้อบกพร่อง
มาร์คเฮนเดอร์สัน

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

1
@AshleySteel ฉันไม่ได้บล็อกอีกต่อไป เคยเป็นครั้งคราว โดยทั่วไปสิ่งทั้งหมดนั้นทำให้ฉันไม่เข้าใจว่า Windows Server dedupe ทำงานอย่างไร ...
Mark Henderson

2

ดูเหมือนว่าฉันอาจกระโดดปืนโดยบอกว่าการขจัดข้อมูลซ้ำซ้อนแบบนี้เป็นไปไม่ได้ เห็นได้ชัดว่ามันเป็นไปได้โดยสิ้นเชิงเพราะนอกเหนือจากการสำรองข้อมูล SQL Server ที่ไม่มีการบีบอัดเหล่านี้ฉันยังมีการสำรองข้อมูลระดับ snapshot ระดับสแนปชอตของ VMWare ของโฮสต์ VM

ตามที่แนะนำให้ yagmoth555 ฉันExpand-DedupeFileใช้ไฟล์ 0 ไบต์บางไฟล์และฉันได้รับไฟล์ที่สามารถใช้งานได้ทั้งหมดในตอนท้าย

จากนั้นฉันดูที่วิธีการทดสอบของฉันสำหรับวิธีที่ฉันระบุว่าไฟล์ไม่ดีและฉันพบข้อบกพร่องในการทดสอบของฉัน (สิทธิ์!)

ฉันยังเปิดไฟล์สำรองข้อมูลแบบซ้ำซ้อนแบบ 0 ไบต์ในโปรแกรมแก้ไข hex และทุกอย่างดูโอเค

ดังนั้นฉันจึงปรับวิธีการทดสอบของฉันและทุกอย่างดูเหมือนจะใช้ได้จริง ในขณะที่ฉันออกไปมัน dedupes จะดีขึ้นจริง ๆ และตอนนี้ฉันประหยัดพื้นที่ได้มากกว่า 1.5TB ด้วยขอบคุณ dedupe

ฉันจะทดสอบสิ่งนี้ให้ละเอียดยิ่งขึ้นก่อนที่ฉันจะเริ่มต้นผลิต แต่ตอนนี้มันดูมีแนวโน้ม


0

ใช่ แต่ฉันเห็นกรณีของคลัสเตอร์ hyperv db dedup'ed เท่านั้น 4tb ถึง 400g และ VM ทำงานอยู่ ระบบปฏิบัติการได้รับการติดตั้งอย่างสมบูรณ์

สำหรับไฟล์สำรอง sql ของคุณมันเป็นดัมพ์ที่คุณสามารถอ่านได้หรือไม่? ฉันจะตรวจสอบเนื้อหา สำหรับส่วนนั้นฉันไม่สามารถตอบได้ว่าไฟล์ ascii ของ dedup


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

1
@ MarkHenderson มันอาจจะเป็นความเสียหายอันใหญ่หลวงในเมตาดาต้าที่ซ้ำซ้อนตามขนาดคือ 0 อ้างถึง; "การคัดลอกซ้ำทำให้เกิดความเสียหายของชิ้นข้อมูลเดี่ยวเนื่องจากชิ้นส่วนที่เป็นที่นิยมสามารถอ้างอิงได้ด้วยไฟล์จำนวนมากลองนึกภาพกลุ่มที่อ้างอิงด้วยไฟล์ 1,000 ไฟล์หายไปเนื่องจากข้อผิดพลาดของเซกเตอร์คุณจะได้รับไฟล์สูญเสีย 1,000 รายการทันที " cmd Expand-DedupFile จะแยกออกถ้ามันเป็น. bak หรือการทุจริตที่
ซ้ำซ้อน
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.