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

ฉันเริ่มเห็นลูกค้าที่มีข้อมูลหลายร้อยเทราไบต์ (ในการติดตั้ง SQL Server) ในขณะที่ปริมาณข้อมูลทั้งหมดในองค์กรบางแห่งเข้าใกล้เศษส่วนที่มีความหมายของเพตาไบต์ฉันต้องการเพิ่มฐานความรู้แบบกลุ่มเพื่อดูว่าผู้คนกำลังจัดการกับข้อมูลขนาดใดที่กำลังทำอยู่เพื่อปกป้องข้อมูล

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

ตัวเลือกที่ฉันเห็นมีดังนี้:

1. สร้างสำเนามิรเรอร์ของข้อมูลในศูนย์ข้อมูลอื่นและจัดส่งความแตกต่างอย่างต่อเนื่อง (ใช้กลไกใดก็ได้ที่มีอยู่สำหรับแหล่งข้อมูลของคุณเช่นบันทึกการจัดส่งหรือการทำมิเรอร์ฐานข้อมูลด้วย SQL Server)
2. ใช้การสำรองข้อมูลปกติโดยใช้อัลกอริทึมการบีบอัดที่หนักหน่วง (อาจเหมาะสมเฉพาะในกรณีที่ข้อมูลที่ยืมมานั้นถูกบีบอัดอย่างหนัก )
3. ใช้การสำรองข้อมูลทีละน้อยของส่วนที่สำคัญ / การเปลี่ยนแปลงของข้อมูล
4. อย่าสำรองข้อมูลและไว้วางใจกับผู้ทุจริต

ฉันเห็นตัวเลือก # 4 ถูกนำมาใช้เป็นค่าเริ่มต้นและในฐานะผู้เชี่ยวชาญ HA / DR มันน่ากลัวจริงๆ แต่ฉันจะแนะนำอะไรให้เป็นทางเลือก ฉันคิดว่า # 1 เป็นวิธีที่ดีที่สุด แต่ "ฉันไม่คิดอย่างนั้น" เป็นคำตอบปกติเมื่อมีทางเลือกอื่นนอกเหนือจาก # 4 และ # 3 อาจแนะนำ

แน่นอนว่ามันขึ้นอยู่กับอัตราการเปลี่ยนแปลงและความสำคัญของข้อมูล ไม่จำเป็นต้องตอบเพราะฉันเคยรับผิดชอบคุณลักษณะ HA ทั้งหมดของ SQL Server ในขณะที่ฉันทำงานที่ Microsoft ดังนั้นฉันจึงมีความเชี่ยวชาญในอาร์กิวเมนต์ 'มันขึ้นอยู่กับ' - นั่นคือวลีที่ฉัน :-)

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

ขอขอบคุณล่วงหน้า - เครดิตจะถูกให้กับทุกคำตอบที่คิดออกมาอย่างดี

แนวคิดที่ปิดอยู่ - ข้อมูลที่เก็บไว้ทั้งหมดจำเป็นต้องใช้หรือเป็นประโยชน์หรือไม่?

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

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

มีข้อมูลซ้ำซ้อนกันในฐานข้อมูลหรือไม่? ตัวอย่างเช่นคนหลายพันคนเก็บสิบสำเนาจดหมายข่าว 10MB ต่อสัปดาห์หรือไม่

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

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

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

ส่วนที่ลื่นคือกระบวนการทั้งหมดไม่สามารถมองเห็นได้ในเซิร์ฟเวอร์ที่เกี่ยวข้อง หากคุณใช้ SQL Server คุณออกแบบกลุ่มไฟล์ของคุณเพื่อให้สิ่งต่าง ๆ มีอัตราการเปลี่ยนแปลงต่ำด้วยกัน (เช่นที่เก็บการขายจาก> 3 ปีที่แล้ว) และสิ่งต่าง ๆ ที่มีอัตราการเปลี่ยนแปลงสูง (เช่นยอดขายปัจจุบัน) ในกลุ่มไฟล์แยกต่างหาก พวกเขาไม่จำเป็นต้องอ่านอย่างสมบูรณ์ - คุณเพียงแค่ต้องการออกแบบมันเพื่อให้คุณสามารถใช้วิธีการจำลองแบบที่แตกต่างกันสำหรับแต่ละกลุ่มไฟล์ อุปกรณ์ SAN สามารถซิงค์ luns ผ่านเครือข่ายเทปหรือผ่าน SAN - ความหมายคุณสามารถจัดส่งชิ้นส่วนของ SAN กลับไปกลับมา สิ่งนี้มีประสิทธิภาพมากขึ้นเมื่อใช้อุปกรณ์เช่น LeftHand's ที่ SAN ประกอบด้วยกลุ่มของหน่วยที่เข้าร่วม

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

ฉันยังไม่ได้ทำสิ่งนี้ในระดับเพตาไบต์ คุณรู้ว่าสิ่งที่พวกเขาพูด - ในทางทฤษฎีในทางทฤษฎีและในทางปฏิบัติเหมือนกัน ในทางปฏิบัติ ...

ตัวเลือกที่ 1 คือการทำมิเรอร์ซึ่งเกือบจะแย่เท่ากับ # 4: ข้อผิดพลาดใด ๆ ที่ทำให้ข้อมูลเสียหายและไม่ถูกค้นพบในทันทีจะทำให้สำเนาทั้งคู่เสียหาย

หากข้อมูลมีความสำคัญให้พิจารณาวิธีแก้ปัญหาเฉพาะ อ่านเกี่ยวกับผลิตภัณฑ์ Shark ของ IBM ตัวอย่างเช่นหรือผลิตภัณฑ์คู่แข่งจาก EMS และอื่น ๆ พวกเขามีคุณสมบัติเช่น Flash-copy ที่ช่วยให้คุณสร้างสำเนาเชิงตรรกะของไฟล์ได้ทันทีโดยไม่ต้องเพิ่มความต้องการดิสก์เป็นสองเท่า จากนั้นคุณสามารถสำรองข้อมูลสำเนานี้ลงในเทป (เช่น) ดูในการสำรองข้อมูลเทปหุ่นยนต์เช่นกัน

ชี้ไปที่ผู้ที่ต้องการจัดเก็บ Petabyte ของข้อมูลที่จัดเก็บไม่ถูก

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

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

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

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

วิดีโอที่น่าสนใจที่มีรายละเอียดสถาปัตยกรรมของ myspace.com (แบ็กเอนด์ SQL2005) ไม่แน่ใจว่าพวกเขามี Petabyte dbs แต่ละตัวหรือไม่เนื่องจากพวกมันขยายใหญ่หลาย dbs พวกเขาใช้การสำรองข้อมูล SAN snap

http://wtv.watchtechvideos.com/topic70.html

ZFS แน่นอนว่ามันยังเพิ่งเริ่มต้น แต่มีหลายพื้นที่ที่ ZFS ออกแบบมาเพื่อจัดการกับสิ่งเหล่านี้ ก่อนอื่นความสามารถในการจัดการข้อมูลจำนวนมากรวมถึงอุปกรณ์จัดเก็บข้อมูลที่หลากหลาย (ในพื้นที่, SAN, ไฟเบอร์ ฯลฯ ) ทั้งหมดในขณะที่รักษาข้อมูลให้ปลอดภัยด้วย checksums และ "เลเยอร์ที่ละเมิด" การรับรู้สุขภาพของอุปกรณ์และ ความล้มเหลว แม้ว่าจะช่วยแก้ปัญหาในการสำรองข้อมูลจำนวนมากนี้ได้อย่างไร

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

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

และคุณบอกว่า ZFS ไม่รองรับ Windows สถานที่ปกติที่คุณอาจพบ sqlserver บางทีคุณเรียกใช้ Sun / ZFS บนแบ็กเอนด์และเชื่อมต่อผ่าน iSCSI อาจเป็นความคิดที่น่ากลัว แต่อย่างน้อยก็คุ้มค่าที่จะให้ความคิดเพื่อที่คุณจะได้รู้ว่าจะไม่ทำอะไร

คุณเคยลองใช้ Amazon Glacier เป็นทางเลือกหรือไม่?

IMO ยกเว้นว่าคุณมีฮาร์ดแวร์ระดับ godzilla บางชนิดถ้าคุณมีข้อมูลมากมายคุณควรใช้เทคโนโลยีการบีบอัดข้อมูลสำรอง ฉันคุ้นเคยกับ LiteSpeed ​​มากที่สุด แต่มีผลิตภัณฑ์ที่คล้ายคลึงกันจากผู้จำหน่ายรายอื่นและ (แน่นอน) มีคุณลักษณะที่คล้ายกันใน SQL2008 คุณอาจไม่ได้รับการบีบอัด 10 ต่อ 1 แต่มันลดข้อกำหนดการจัดเก็บสำหรับการสำรองข้อมูลลงและยังสามารถลดขนาดหน้าต่างการสำรองข้อมูลของคุณ หากเป้าหมายของคุณคือเก็บชุดข้อมูลสำรองหลายชุด (เมื่อวานบวกวันก่อนหน้านั้นบวกหนึ่งชุดจากสัปดาห์ที่แล้วและอีกหนึ่งเดือนจากเดือนที่แล้วหรือชุดของส่วนต่างบวกชุดเต็มซึ่งจะมีจำนวนมากหากคุณเปลี่ยนข้อมูลจำนวนมากใน ฐานข้อมูล) มันเป็นเรื่องง่ายของพื้นที่จัดเก็บ

การสำรองข้อมูลตาม Filegroup (IOW นำข้อมูลที่ไม่ลบเลือนไปยัง FGs บางส่วนและด้านหลังไม่บ่อยนัก) ดูเหมือนจะไม่บินเพราะ devs หรือผู้ใช้จะไม่หรือไม่สามารถตัดสินใจได้ว่าข้อมูลใดที่มีความผันผวนและสิ่งใดที่ไม่และใน Brownfield สถานการณ์ที่คุณมักไม่สามารถรับความเสี่ยงได้

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

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

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

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

ฉันไม่คิดว่าคุณจะสำรองข้อมูลมากเท่ากับที่คุณเก็บรักษาสำเนาที่สองไว้เพื่อที่จะกู้คืนจากปัญหาเกี่ยวกับเอกสารหลักของคุณ นั่นหมายถึงฮาร์ดแวร์ความเสียหาย ฯลฯ และคุณสวดมนต์ทุกวันว่ามีการส่งข้อผิดพลาดไปยังสำเนาที่สอง สำเนาที่น่าจะถูกสร้างเป็น SAN-SAN ด้วยเทคโนโลยี snap-shot'ing แม้ว่าสำเนาต้นฉบับอาจจะผ่านทาง Fed-Ex แทนที่จะข้ามสาย แบนด์วิดท์ในการย้าย 100TB ไม่ใช่เรื่องง่ายสำหรับทุกคน

ฉันคิดว่าคุณต้องการการรวมกันของ 1, 2 และ 3 (ไม่ใช่ 4) ด้วยการจัดการการสำรองข้อมูลบันทึกที่ยอดเยี่ยม

ที่จริงแล้วฉันคิดว่า ณ เวลาใดก็ตามคุณกำลังดูข้อมูลของคุณ 3 ชุด เรียกใช้ CHECKDB บน ​​1 ของสำเนาในขณะที่สำเนาที่สองจะถูกใช้เพื่อรับการเปลี่ยนแปลงจริง จากนั้นคุณจับภาพสำเนาที่สองไปที่หน้าแรกและดำเนินการต่อ ด้วยข้อมูลมากมายนี้ฉันคิดว่าคุณจะต้องใช้ความขยันที่นี่ Paul, checkdb ทำงานอย่างไรกับผู้ใช้หลายคน, 100TB db ที่ออนไลน์?

ดังที่กล่าวไว้ไม่ใช่การสำรองข้อมูลบันทึกและอาจเป็นเครื่องอ่านบันทึกข้อมูลที่สำคัญ คุณไม่ต้องการกู้คืนตารางข้อผิดพลาดของผู้ใช้ / จากบันทึกแทนการสำรองข้อมูลหรือไม่? คุณสามารถลัดสิ่งนี้ได้โดยส่งสำเนา SAN ผ่านความล่าช้าบ้าง แต่ฉันไม่เห็นเทคโนโลยีนั้น บันทึกการจัดส่ง SAN ที่สามารถชะลอการเปลี่ยนแปลง 4 ชั่วโมง (หรือบางช่วงเวลา) เพื่อให้คุณสามารถกู้คืนจากปัญหาก่อนเขียนทับข้อมูล หรือเครื่องมือ log-reader-of-SAN-block-change? หากไม่มีคุณจะต้องจัดการบันทึกธุรกรรมเหล่านั้นซึ่งอาจเป็นอีกระดับหนึ่งของการติดตามการสำรองข้อมูลเหล่านั้นในระบบไฟล์ต่างๆเป็นเวลา xxx ชั่วโมงบางช่วงเพื่อให้คุณสามารถกู้คืนจากข้อผิดพลาดที่ไม่ร้ายแรง

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

อีกวิธีหนึ่งเช่น Amazon S3 อาจเล่นด้วยขึ้นอยู่กับแบนด์วิดท์ของคุณและปริมาณข้อมูลที่เปลี่ยนแปลงในระดับเสียงโดยวางอย่างน้อยในเซิร์ฟเวอร์ของผู้อื่นและปล่อยให้พวกเขากังวลเกี่ยวกับความซ้ำซ้อนที่เพิ่มขึ้น คุ้มค่า

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

ในคลังข้อมูลองค์กรขนาดใหญ่ข้อมูลส่วนใหญ่มาจากแหล่งข้อมูลที่สำรองไว้แล้ว ฉันทำงานกับการติดตั้ง Teradata และ ODW ที่พวกเขาใช้ตัวเลือก # 4 แต่รู้ว่าพวกเขาสามารถกู้คืนข้อมูลธุรกรรมหนึ่งวันหรือสองวันและแปลงจากระบบต้นทาง

ที่ลูกค้ารายย่อยหนึ่งราย (ในขณะที่พวกเขามีหนึ่งใน 5 DW ที่ใหญ่ที่สุดในโลกที่ประมาณ 200TB ... ให้ความคิดแก่คุณว่านานแค่ไหนที่ผ่านมา) พวกเขาไปด้วยตัวเลือก # 1 หลังจากซื้อ Petabyte ใหม่ - คลาสเซิร์ฟเวอร์ Teradata โหนดเก่าจะถูกใช้เป็นสแนปช็อตของระบบของวันก่อนหน้าขณะที่โหนดใหม่จะคงอยู่เดิม นี่เป็นสิ่งที่ดีจากมุมมองที่ล้มเหลว - ทุกครั้งในขณะที่พวกเขาต้องการลดปัญหาทั้งหมดในการบำรุงรักษาและเราเพียงแค่เปลี่ยนไปใช้เซิร์ฟเวอร์เก่าที่ช้ากับข้อมูลรายวัน

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