การสำรองข้อมูลส่วนที่ 7: บทสรุป

การสำรองข้อมูลส่วนที่ 7: บทสรุป

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

ข้อมูลดิบ

เซิร์ฟเวอร์เฉพาะส่วนใหญ่มักจะมีฮาร์ดไดรฟ์อย่างน้อยสองตัวที่ทำหน้าที่จัดระเบียบอาร์เรย์ RAID ระดับแรก (มิเรอร์) นี่เป็นสิ่งจำเป็นเพื่อให้สามารถดำเนินการเซิร์ฟเวอร์ต่อไปได้หากดิสก์ตัวหนึ่งล้มเหลว หากนี่คือเซิร์ฟเวอร์เฉพาะทั่วไป อาจมีตัวควบคุม RAID ฮาร์ดแวร์แยกต่างหากพร้อมเทคโนโลยีแคชที่ใช้งานอยู่บน SSD เพื่อให้สามารถเชื่อมต่อ SSD ได้ตั้งแต่หนึ่งตัวขึ้นไปนอกเหนือจากฮาร์ดไดรฟ์ทั่วไป บางครั้งมีการเสนอเซิร์ฟเวอร์เฉพาะซึ่งดิสก์ในเครื่องมีเพียง SATADOM (ดิสก์ขนาดเล็กซึ่งมีโครงสร้างเป็นแฟลชไดรฟ์ที่เชื่อมต่อกับพอร์ต SATA) หรือแม้แต่แฟลชไดรฟ์ขนาดเล็กปกติ (8-16GB) ที่เชื่อมต่อกับพอร์ตภายในพิเศษและ ข้อมูลถูกนำมาจากระบบจัดเก็บข้อมูล เชื่อมต่อผ่านเครือข่ายจัดเก็บข้อมูลเฉพาะ (Ethernet 10G, FC ฯลฯ) และมีเซิร์ฟเวอร์เฉพาะที่โหลดโดยตรงจากระบบจัดเก็บข้อมูล ฉันจะไม่พิจารณาตัวเลือกดังกล่าวเนื่องจากในกรณีเช่นนี้งานสำรองข้อมูลเซิร์ฟเวอร์ได้อย่างราบรื่นจะส่งต่อไปยังผู้เชี่ยวชาญที่ดูแลระบบจัดเก็บข้อมูล โดยปกติแล้วจะมีเทคโนโลยีที่เป็นกรรมสิทธิ์ต่าง ๆ สำหรับการสร้างสแน็ปช็อตการขจัดข้อมูลซ้ำซ้อนในตัวและความสุขอื่น ๆ ของผู้ดูแลระบบ ที่กล่าวถึงในส่วนก่อนหน้าของซีรี่ส์นี้ ไดรฟ์ข้อมูลของอาร์เรย์ดิสก์ของเซิร์ฟเวอร์เฉพาะสามารถเข้าถึงได้หลายสิบเทราไบต์ ขึ้นอยู่กับจำนวนและขนาดของดิสก์ที่เชื่อมต่อกับเซิร์ฟเวอร์ ในกรณีของ VPS ปริมาณจะน้อยกว่า: โดยปกติจะไม่เกิน 100GB (แต่ก็มีมากกว่านั้นด้วย) และภาษีสำหรับ VPS ดังกล่าวอาจมีราคาแพงกว่าเซิร์ฟเวอร์เฉพาะที่ถูกที่สุดจากโฮสต์เดียวกันได้อย่างง่ายดาย VPS ส่วนใหญ่มักจะมีดิสก์เพียงแผ่นเดียว เนื่องจากจะมีระบบจัดเก็บข้อมูล (หรือไฮเปอร์คอนเวิร์จ) อยู่ข้างใต้ บางครั้ง VPS อาจมีดิสก์หลายตัวที่มีคุณสมบัติแตกต่างกัน เพื่อวัตถุประสงค์ที่แตกต่างกัน:

  • ระบบขนาดเล็ก - สำหรับการติดตั้งระบบปฏิบัติการ
  • ขนาดใหญ่ - จัดเก็บข้อมูลผู้ใช้

เมื่อคุณติดตั้งระบบใหม่โดยใช้แผงควบคุม ดิสก์ที่มีข้อมูลผู้ใช้จะไม่ถูกเขียนทับ แต่ดิสก์ระบบจะถูกเติมใหม่ทั้งหมด นอกจากนี้ ในกรณีของ VPS โฮสต์อาจเสนอปุ่มที่จับภาพสถานะของ VPS (หรือดิสก์) แต่หากคุณติดตั้งระบบปฏิบัติการของคุณเองหรือลืมเปิดใช้งานบริการที่ต้องการภายใน VPS บางส่วน ของข้อมูลอาจจะยังสูญหายได้ นอกจากปุ่มแล้ว ยังมีบริการจัดเก็บข้อมูลอีกด้วย ซึ่งส่วนใหญ่มักมีข้อจำกัดมาก โดยทั่วไปแล้ว นี่คือบัญชีที่เข้าถึงได้ผ่าน FTP หรือ SFTP ซึ่งบางครั้งอาจใช้ร่วมกับ SSH โดยมีเชลล์แบบแยกส่วน (เช่น rbash) หรือมีข้อจำกัดในการรันคำสั่งผ่านauthorized_keys (ผ่าน ForcedCommand)

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

โหลดโดยทั่วไปของเซิร์ฟเวอร์เฉพาะหรือ VPS คือเว็บเซิร์ฟเวอร์ ฐานข้อมูล และแอปพลิเคชันเซิร์ฟเวอร์ บางครั้งอาจมีการติดตั้งบริการเสริมเพิ่มเติมต่างๆ รวมถึงเว็บเซิร์ฟเวอร์หรือฐานข้อมูล: เครื่องมือค้นหา ระบบเมล ฯลฯ

เซิร์ฟเวอร์ที่จัดเตรียมเป็นพิเศษทำหน้าที่เป็นพื้นที่สำหรับจัดเก็บสำเนาสำรองเราจะเขียนรายละเอียดเพิ่มเติมในภายหลัง

การจัดระเบียบแบบลอจิคัลของระบบดิสก์

หากคุณมีตัวควบคุม RAID หรือ VPS ที่มีดิสก์เดียว และไม่มีการตั้งค่าพิเศษสำหรับการทำงานของระบบย่อยของดิสก์ (เช่น ดิสก์แบบเร็วแยกต่างหากสำหรับฐานข้อมูล) พื้นที่ว่างทั้งหมดจะถูกแบ่งดังนี้: หนึ่งพาร์ติชัน ถูกสร้างขึ้นและกลุ่มวอลุ่ม LVM ถูกสร้างขึ้นด้านบน มีการสร้างวอลุ่มหลายวอลุ่มในนั้น: วอลุ่มขนาดเล็ก 2 วอลุ่มที่มีขนาดเท่ากัน ใช้เป็นระบบไฟล์รูท (เปลี่ยนทีละตัวในระหว่างการอัพเดตเพื่อความเป็นไปได้ที่จะย้อนกลับอย่างรวดเร็ว แนวคิดนี้หยิบมาจากการกระจาย Calculate Linux) อีกอันหนึ่งสำหรับพาร์ติชัน swap พื้นที่ว่างที่เหลือแบ่งออกเป็นวอลุ่มขนาดเล็ก ใช้เป็นระบบไฟล์รูทสำหรับคอนเทนเนอร์แบบเต็ม ดิสก์สำหรับเครื่องเสมือน ไฟล์ ระบบสำหรับบัญชีใน /home (แต่ละบัญชีมีระบบไฟล์ของตัวเอง), ระบบไฟล์สำหรับคอนเทนเนอร์แอปพลิเคชัน

หมายเหตุสำคัญ: ไดรฟ์ข้อมูลจะต้องครบถ้วนในตัวเอง เช่น ไม่ควรขึ้นอยู่กับแต่ละอื่น ๆ หรือบนระบบไฟล์รูท ในกรณีของเครื่องเสมือนหรือคอนเทนเนอร์ จุดนี้จะถูกสังเกตโดยอัตโนมัติ หากสิ่งเหล่านี้เป็นคอนเทนเนอร์แอปพลิเคชันหรือโฮมไดเร็กทอรี คุณควรพิจารณาแยกไฟล์การกำหนดค่าของเว็บเซิร์ฟเวอร์และบริการอื่น ๆ ในลักษณะที่จะกำจัดการขึ้นต่อกันระหว่างไดรฟ์ข้อมูลให้มากที่สุด ตัวอย่างเช่น แต่ละไซต์ทำงานโดยผู้ใช้ของตัวเอง ไฟล์การกำหนดค่าไซต์อยู่ในไดเร็กทอรีโฮมของผู้ใช้ ในการตั้งค่าเว็บเซิร์ฟเวอร์ ไฟล์การกำหนดค่าไซต์จะไม่รวมผ่าน /etc/nginx/conf.d/.conf และ ตัวอย่างเช่น /home//configs/nginx/*.conf

หากมีดิสก์หลายแผ่น คุณสามารถสร้างซอฟต์แวร์อาร์เรย์ RAID ได้ (และกำหนดค่าแคชบน SSD หากมีความจำเป็นและโอกาส) นอกเหนือจากนั้น คุณสามารถสร้าง LVM ตามกฎที่เสนอข้างต้น นอกจากนี้ ในกรณีนี้ คุณสามารถใช้ ZFS หรือ BtrFS ได้ แต่คุณควรคิดให้รอบคอบเกี่ยวกับเรื่องนี้ ทั้งสองอย่างนี้ต้องใช้ทรัพยากรที่จริงจังกว่ามาก และนอกจากนี้ ZFS ก็ไม่ได้รวมอยู่ในเคอร์เนล Linux

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

อุปกรณ์เซิร์ฟเวอร์จัดเก็บข้อมูลสำรอง

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

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

หลักการดำเนินการคือสร้างโวลุ่มแยกกันสำหรับแต่ละเซิร์ฟเวอร์สำหรับที่เก็บ BorgBackup ซึ่งข้อมูลจากเซิร์ฟเวอร์การต่อสู้จะไป ที่เก็บข้อมูลทำงานในโหมดต่อท้ายเท่านั้น ซึ่งกำจัดความเป็นไปได้ของการลบข้อมูลโดยเจตนา และเนื่องจากการขจัดข้อมูลซ้ำซ้อนและการทำความสะอาดที่เก็บข้อมูลเป็นระยะจากการสำรองข้อมูลเก่า (สำเนารายปียังคงอยู่ ทุกเดือนสำหรับปีที่แล้ว ทุกสัปดาห์สำหรับเดือนที่แล้ว ทุกวันสำหรับ สัปดาห์ที่แล้ว อาจเป็นกรณีพิเศษ - รายชั่วโมงสำหรับวันสุดท้าย: รวม 24 + 7 + 4 + 12 + ต่อปี - ประมาณ 50 สำเนาสำหรับแต่ละเซิร์ฟเวอร์)
ที่เก็บ BorgBackup ไม่ได้เปิดใช้งานโหมดต่อท้ายเท่านั้น แต่ ForcedCommand ใน .ssh/authorized_keys จะใช้ในลักษณะนี้แทน:

from="адрес сервера",command="/usr/local/bin/borg serve --append-only --restrict-to-path /home/servername/borgbackup/",no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-user-rc AAAAA.......

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

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

กระบวนการสำรองข้อมูล

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

หากมีฐานข้อมูลขนาดเล็ก (สูงสุด 1 GB สำหรับแต่ละไซต์) จะมีการสร้างดัมพ์ฐานข้อมูลซึ่งจะถูกบันทึกในโลจิคัลวอลุ่มที่เหมาะสม โดยที่ข้อมูลส่วนที่เหลือสำหรับไซต์เดียวกันนั้นตั้งอยู่ แต่เพื่อให้ดัมพ์นั้น ไม่สามารถเข้าถึงได้ผ่านเว็บเซิร์ฟเวอร์ หากฐานข้อมูลมีขนาดใหญ่ คุณควรกำหนดค่าการลบข้อมูลแบบ “ฮอต” เช่น การใช้ xtrabackup สำหรับ MySQL หรือทำงานกับ WAL ด้วย archive_command ใน PostgreSQL ในกรณีนี้ ฐานข้อมูลจะถูกกู้คืนแยกจากข้อมูลไซต์

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

ดำเนินการเพิ่มเติมบนเซิร์ฟเวอร์จัดเก็บข้อมูลสำรอง:

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

กระบวนการกู้คืนเซิร์ฟเวอร์

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

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

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

บทความอื่น ๆ ในชุด

การสำรองข้อมูล ตอนที่ 1: เหตุใดจึงต้องสำรองข้อมูล ภาพรวมของวิธีการ เทคโนโลยี
การสำรองข้อมูลส่วนที่ 2: การตรวจสอบและทดสอบเครื่องมือสำรองข้อมูลที่ใช้ rsync
การสำรองข้อมูลส่วนที่ 3: การตรวจสอบและทดสอบการซ้ำซ้อน การซ้ำซ้อน
การสำรองข้อมูลส่วนที่ 4: การตรวจสอบและทดสอบ zbackup, restic, borgbackup
การสำรองข้อมูลส่วนที่ 5: การทดสอบการสำรองข้อมูล Bacula และ Veeam สำหรับ Linux
การสำรองข้อมูล: ส่วนหนึ่งตามคำขอของผู้อ่าน: ตรวจสอบ AMANDA, UrBackup, BackupPC
การสำรองข้อมูลส่วนที่ 6: การเปรียบเทียบเครื่องมือสำรองข้อมูล
การสำรองข้อมูลส่วนที่ 7: บทสรุป

ฉันขอเชิญคุณให้หารือเกี่ยวกับตัวเลือกที่เสนอในความคิดเห็นขอขอบคุณสำหรับความสนใจของคุณ!

ที่มา: will.com

เพิ่มความคิดเห็น