นโยบายการจัดการความรู้ มหาวิทยาลัยสงขลานครินทร์ 1.ให้ใช้เครื่องมือการจัดการความรู้ผลักดัน คุณภาพคน และกระบวนทำงาน 2.ส่งเสริมการแลกเปลี่ยนประสบการณ์การทำงาน จากหน้างาน 3.ส่งเสริมให้มีเวทีเรียนรู้ร่วมกัน
อ่าน: 1543
ความเห็น: 2

ตอบคำถามคุณภัทธ์ เกี่ยวกับการ backup ข้อมูลของ share (บางส่วน)

คุณภัทธ์ ตั้งคำถามไว้ ที่นี่ เกี่ยวกับการ backup ข้อมูลของระบบ share ไว้ตามนี้ (ขอบคุณ คุณ Our Shangri-La ที่ช่วยชี้ว่ามีคำถามอยู่ครับ)

1. จำเป็นไหมที่ต้องเก็บ file ไว้มากขนาดนี้ ดูแล้วสามารถย้อนหลังกลับไปได้ 14 วัน อาจจะเป็นเรื่องปกติ

แต่จะเก็บสัก 7 วันจะได้ไหม

เพราะถ้า ข้อมูลผิด ถึงแม้ว่าจะเก็บย้อนหลังไปกี่วันก็ ข้อมูลที่เก็บก็เป็นข้อมูลที่ผิด

แต่การเก็บหลายๆ วันแบบนี้ ถ้าเรารู้ตัวว่าข้อมูลที่เก็บผิด เรามีโอกาสที่จะกู้ข้อมูลที่ถูกต้องได้สูงกว่าเก็บน้อยวัน

แต่การ ย้อนหลังไปหลายๆ วัน มันจะคุ้มไหมกับการข้อมูลที่ผิดพลาด

2. จำเป็นไหมที่เก็บไว้เพียง file เดียว ทำไมไม่แบ่งเป็น file ย่อยๆ หลายๆ file


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

เนื้อที่ที่ใช้ไปสำหรับการ backup ในส่วนนี้เท่ากับ 312 GB

cj@u7:~/file_backups$ du -s -h .
312G    .

แต่เนื้อที่ที่เหลืออยู่ ก็เหลือ 287GB

cj@u7:~/file_backups$ df -h .
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             895G  563G  287G  67% /

เพราะฉะนั้น ผมก็ยังไม่กังวลเรื่องของเนื้อที่สักเท่าไหร่

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

ลักษณะจะต่างจากการใช้งาน ข้อมูลประเภทอื่น เช่น email, document, spread sheet, program ซึ่งมีโอกาสมากที่เราจะไปแก้ไข ข้อมูลเดิม ลบไฟล์ที่คิดว่าไม่ต้องการแล้วทิ้งไป ทำให้ อาจจะต้องพึ่งพา ระบบ backup เพื่อเอาข้อมูลเก่า ย้อนหลังไปหลายวัน หรือหลายสัปดาห์คืนมา

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

ซึ่ง ถ้าปัญหาเป็นไปตามตัวอย่างของกรณีหลัง ... ฮาร์ดดิสก์พัง การ backup แบบที่ใช้อยู่บนระบบ share ปัจจุบัน ไม่ว่าจะเป็น 1 วัน หรือ 14 วัน ก็จะไม่ได้ช่วยอะไรเลย เพราะทั้งข้อมูลที่ใช้งานจริง และข้อมูลที่ backup อยู๋บนฮาร์ดดิสก์ตัวเดียวกัน :)

สำหรับการแก้ปัญหาในกรณีนี้ จริงๆแล้ว มีระบบสำรองอยู่บ้างแล้วก็คือ

1. คุณคณกรณ์มีการ backup ไฟล์ข้อมูลที่จาก share ในส่วนที่ backup เป็นไฟล์เอาไว้แล้ว ไปอยู่บนระบบ backup ข้อมูลของศูนย์คอมพิวเตอร์ ส่วนนี้ ผมเข้าใจว่าจะเป็น tape backup รวมของศูนย์


2. ผมใช้การ backup แบบ rsync ซึ่งจะ backup เฉพาะไฟล์ที่เพิ่มขึ้น มาเก็บไว้บน เครื่อง desktop ที่ผมใช้สำหรับการดูแลระบบอยู่
ระบบที่ผมใช้ (คุณภัทธ์น่าจะคุ้นเคยกับวิธีการนี้ดีอยู๋แล้ว แต่ผมขออธิบายเผื่อคนอื่นๆ ที่อาจจะยังไม่ได้คุ้นเคยกับวิธีการนี้ ที่มาอ่านบันทึกนี้ด้วย) จะตรวจสอบแค่ว่า ไฟล์ต้นทาง (บน share.psu.ac.th) กับไฟล์ปลายทาง (บนเครื่อง desktop ของผม) มีไฟล์อะไรที่ต่างกันอยู่บ้าง ถ้ามี ก็จะ copy ไฟล์จากต้นทางมาเก็บไว้ยังปลายทาง เพราะฉะนั้น ถึงแม้ข้อมูลที่จำเป็นจะต้อง backup "ทั้งหมด" จะมีอยู่มากกว่า 20 GB แต่ข้อมูลที่ผมจำเป็นจะต้อง backup ก็จะมีเพียงไม่กี่ MB ในแต่ละวัน (น้อยกว่า 10 MB) และข้อมูลที่ backup เอาไว้ก็จะเป็นข้อมูลล่าสุดย้อนหลังไม่เกิน 24 ชม.

อย่างไรก็ตาม ระบบที่มีอยู่ ทั้งสองระบบที่สำรองเอาไว้ก็เป็นแค่ระบบ "ชั่วคราว" ที่ "เผื่อ" เอาไว้สำหรับกรณีฉุกเฉิน เท่านั้น ระบบ backup จริงๆ ที่น่าจะเหมาะกับการใช้งานระบบ share ที่มีอยู่ในปัจจุบัน คงจะต้องรออีกสักพักครับ ประเด็นที่ผมอยากจะทำก่อนก็คือ การปรับให้ share อยู่บนระบบที่ทันสมัยก่อน ... หมายถึงว่า แทนที่จะอยู่บน ubuntu 11.04 และไม่ได้มีการ update system ให้ทันสมัยอยู่ในแบบปัจจุบัน share ควรที่จะปรับไปอยู่บน ubuntu 12.04 และ update package ให้ทันสมัยสำหรับ 12.04 หรือ ถ้าไม่อย่างนั้น ก็ควรที่จะปรับไปใช้ Debian Wheezy เลย ... แต่เรื่องนี้อยู่ในขั้นตอนที่ผมกำลังศึกษา/ตรวจสอบอยู่ครับว่า ถ้ามีการ upgrade ในส่วนของ OS จะมีผลกระทบอะไรกับ ส่วนของระบบ share หรือเปล่าครับ

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

ในกรณีนี้ ข้อมูลที่เก็บเอาไว้ในไฟล์ backup ไม่ได้เก็บโดยวิธีการปกติโดยทั่วไป ยกตัวอย่างเช่น ถ้าคุณภัทธ์บอกว่าต้องการ ภาพที่ 2 อยู่ในบันทึก 27778 ผมก็ไม่สามารถหาจากไฟล์ ที่ backup เอาไว้ได้โดยตรง เนื่องจากวิธีการจัดเก็บ ว่าไฟล์เหล่านี้ อยูใน blog ใหนก็จะจัดเก็บเอาไว้ใน database ซึ่งจัดการโดยตัว knowledgEvolution เอง

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

แต่ระบบที่ว่า ผมยังไม่พร้อมที่จะเอามาใช้ในตอนนี้ครับ คงจะต้องรออีกสักพักให้เรื่องของการ transfer ระบบ share ที่ผมกำลังทดลองอยู่สามารถทำได้โดยไม่มีปัญหาก่อน แล้วถีงจะ upgrade system และเพิ่ม package ที่จะใช้ในการจัดการระบบ backup ให้เหมาะสมได้ครับ :)

Sections: Miscellaneous
License: ซีซี: แสดงที่มา-ไม่ใช้เพื่อการค้า-อนุญาตแบบเดียวกัน Cc-by-nc-sa
created: 21 March 2013 18:20 Modified: 21 March 2013 18:20 [ Report Abuse ]
ดอกไม้
People who like this: Ico24 Our Shangri-La, Ico24 ServiceMan, and 6 others.
People Who Like This
 
Facebook
Twitter
Google

Other Posts By This Blogger

ความเห็น

ขอบคุณครับ

Ico48
Our Shangri-La (Recent Activities)
21 March 2013 22:09
#85675

ค่อย ๆ แกะไปเรื่อย ๆ ขยับไปทีละนิด

ผมเห็นตรงกับ อ. ฉัตรชัย เรื่องการ backup ในขณะนี้ ในเรื่องเนื้อที่ของ server เองก็ไม่ต่างจากที่ประมาณการเอาไว้มากนัก เวลาการ backup ที่ลดเวลาลงมาเหลือเพียงครึ่งชั่วโมงต่อวัน

เทียบกับระยะเวลา ๕ ปี ส่วนที่เป็นแฟ้มข้อมูลประกอบบันทึกมีเพียง ๒๒ จิกะไบต์ หรือ ๒๒ / ๕ ซึ่งอยู่ที่ประมาณ ๔ จิกะไบต์ต่อปี แต่ผมคาดว่าช่วงปีแรก ๆ น่าจะมีขนาดมากกว่าปีหลัง ๆ ค่อนข้างมาก

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

เราเอง

ร่วมแสดงความเห็นในหน้านี้

ชื่อ:
อีเมล:
IP แอดเดรส: 35.175.191.168
ข้อความ:  
เรียกเครื่องมือจัดการข้อความ
   
ยกเลิก หรือ