กฎสำรอง 3-2-1 ยังคงเกี่ยวข้องกับกลยุทธ์ของคุณหรือไม่?

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

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

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

คุณควรสร้างแผนสำรองอย่างไร?

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

รายละเอียดที่ต้องจำสำหรับกฎนี้มีดังนี้:

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

• 2 : สำเนาสำรองสองชุดของคุณควรเขียนบนสื่อที่แตกต่างกัน สิ่งนี้ใช้เพื่อสื่อสารข้อมูลสำรองจริงประเภทต่างๆ เช่น ดีวีดีหรือเทปไดร์ฟ แต่เราสามารถขยายกฎให้รวมการจำลองเสมือนได้อย่างปลอดภัย ตัวอย่างเช่น คุณปฏิบัติตามข้อกำหนดของ *สื่อสองสื่อ* ด้วยข้อมูลสำรองหนึ่งรายการที่จัดเก็บไว้ในฮาร์ดไดรฟ์ และอีกข้อมูลหนึ่งจัดเก็บไว้ในเครื่องเสมือน หากเครื่องเสมือนนั้นอยู่ในระบบคลาวด์ ก็สามารถตอบสนองความต้องการในการสำรองข้อมูลนอกสถานที่ได้ ซึ่งช่วยให้เกิดความล้มเหลวหรือการทำลายข้อมูลสำรองในสื่อประเภทหนึ่งนอกเหนือจากข้อมูลที่อาจเสียหายในการผลิต

• 1 : หนึ่งในสำเนาสำรองเหล่านั้นควรอยู่นอกสถานที่อย่างแน่นอน นอกสถาน ที่ไม่ได้หมายถึงนอกสถานที่ของคุณเท่านั้น หมายความว่าอยู่ห่างจากการผลิตและสำเนาสำรองอื่น ๆ ของคุณ ธุรกิจในระบบคลาวด์เต็มรูปแบบควรปฏิบัติตามกฎนี้ด้วยวิธีเดียวกัน: หากคุณโฮสต์ข้อมูลของคุณในผู้ให้บริการคลาวด์รายใหญ่หรือ SaaS ข้อมูลสำรองของคุณไม่ควรโฮสต์กับพวกเขา

ทำไมถึงเลือก 3-2-1 ในการฝึกซ้อม?

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

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

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

ทำไมคุณไม่เลือก 3-2-1?

3-2-1 สูญเสียยูทิลิตี้บางอย่างในยุคที่ธุรกิจขนาดกลางและขนาดย่อม (SMB) พึ่งพาซอฟต์แวร์ในรูปแบบบริการ (SaaS) เทคโนโลยีสารสนเทศกลายเป็นประชาธิปไตยมากขึ้น โดยไม่ต้องใช้การโฮสต์และการพัฒนาไอทีภายในองค์กรอีกต่อไปเพื่อรองรับฟังก์ชันเทคโนโลยี

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

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

แล้วการสำรองข้อมูลของผู้ให้บริการ SaaS ล่ะ?

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

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

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

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

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

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

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

• การนำเข้าและส่งออกขนาดใหญ่ ซึ่งมักจะเป็นวิธีที่สะดวกกว่าในการสร้างผลิตภัณฑ์ใหม่หรือดาวน์โหลดข้อมูลสำหรับรายงาน

มีอะไรผิดพลาด?

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

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

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

3-2-1 ครอบคลุมเฉพาะการสร้างและป้องกันข้อมูลสำรองเท่านั้น มันไม่ได้สร้างแผนการกู้คืนข้อมูลด้วยตัวเอง

คุณต้องมีแผนการกู้คืน

ปัญหาใหญ่ที่สุดในการใช้ผู้ให้บริการ SaaS เพื่อสำรองข้อมูลจากผู้ให้บริการรายนั้นคือการคืนค่าข้อมูลสำรอง เพียงแค่ดาวน์โหลดไฟล์ repos ไฟล์ผลิตภัณฑ์ ตั๋ว ฯลฯ ก็ยอดเยี่ยม แต่คุณจะใส่ข้อมูลนั้นกลับเข้าไปในแพลตฟอร์ม SaaS ของคุณในกรณีฉุกเฉินได้อย่างไร

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

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

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

บริการเชิงพาณิชย์สำหรับการกู้คืน

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

หากคุณตัดสินใจที่จะใช้ BaaS ให้มองหาผู้ให้บริการที่ตรงกับการใช้งานคลาวด์หรือแอปพลิเคชัน SaaS ของคุณ ตัวอย่างเช่น หากคุณต้องการใช้แอป SaaS เชิงธุรกิจและเชิงเทคนิคร่วมกัน คุณสามารถใช้ [ย้อนกลับ](https://rewind.com/products/backups/github/) พวกเขามีการผสานรวมการสำรองข้อมูลที่สร้างไว้ล่วงหน้าสำหรับผู้ให้บริการระบบคลาวด์จำนวนมาก และคุณจะต้องเรียนรู้ผลิตภัณฑ์ BaaS เพียงรายการเดียวเพื่อให้ครอบคลุมการแพร่กระจาย

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

BaaS เชิงพาณิชย์สามารถเป็นทางออกหลักหรือแทนที่ส่วนหนึ่งของแนวทางปฏิบัติ 3-2-1 ของคุณเองก็ได้ คำตอบเดียวที่ถูกต้องคือคำตอบที่เหมาะกับงบประมาณ ความพร้อมใช้งานของทักษะทางเทคนิค และความต้องการเวลาพักฟื้นของคุณ

บทสรุป

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

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

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