ems
1
เนื่องจากผมไม่มีความรู้เรื่องนี้มากมักจึงขอเขียนเชิงปรึกษานะครับ ถึงข้อดีข้อเสียและความเป็นไปได้ที่จะใช้งานแบบนี้
เริ่มต้นด้วยการติดตั้งและใช้งาน LVM อ่านข้อมูลได้จากที่นี่ http://spalinux.com/2008/05/use_lvm_to_manage_disk_part2
สรุปขั้นตอนของ LVM ดังนี้
- มี HDD เปล่า ผมใช้ /dev/sdb
- ทำการ Fdisk โดยดูข้อมูลจากเว็บ http://spalinux.com/2008/05/use_lvm_to_manage_disk_part2
คำสั่งในการทำ Snapshot
รูปแบบ
lvcreate -Lsize -s -n snapshot_dev_name original_lv_dev_name
ตัวอย่างการทำการใช้งาน
lvcreate -L500m -s -n backup-12-03-2017-17-15 /dev/mapper/VG_HOME/LV_HOME
โดยเราอาจสามารถใส่ใน Crontab ไว้ โดยเปลี่ยนตรง backup-12-03-2017-17-15 เป็นวันที่และเวลาที่ทำ Snapshot
การลบ Snapshot
ใช้คำสั่ง lvremove
ตัวอย่าง
lvremove /dev/VG_HOME/ backup-12-03-2017-17-15
โดยจะเลือก Remove เฉพาะตัวที่นานที่สุดออกไป
สิ่งที่ได้คือจะมี Snapshot เป็นวันๆ ย้อนหลังไปได้ตามที่เราอยากจะตั้งตราบเท่าที่ยังมีพื้นที่เหลือ
การ Mount Snapshot เพื่อดึงข้อมูลที่ Backup ไว้
ตัวอย่าง
mount /dev/VG_HOME/ backup-12-03-2017-17-15 /backup
เราก็จะสามารถเห็นไฟล์ทั้งหมดที่ Snapshot ใน /backup
ขอดี
- ใช้เวลาในการทำ Snapshot น้อยมาก ไม่เกิน 5 นาที
- ใช้พื้นที่ในการจัดเก็บน้อยกว่าทำ Backup ทั้งก้อน
- สามารถนำมาประยุคใช้กับ Openvzได้ทำให้ประหยัดเวลาการทำ Backup
สิ่งที่ผมต้องการจะสอบถามเซียนท่านอื่นๆ ที่รู้เรื่องนี้รบกวนช่วยตอบให้ผมหน่อยนะครับ
- ทำแบบนี้พื้นที่ที่ใช้ในการ Snapshot จะใช้อยู่ประมาณเท่าไหร่
- ตอน Create ตรง -Lsize ผลอะไรบ้างและควรกำหนดเป็นเท่าไหร่ดี
- วิธีนี้สามารถนำมาใช้ทำ Backup ที่สามารถย้อนหลังได้นานๆ ได้หรือไม่ มีความเสี่ยงหรือไม่ หรือจริงๆ แล้วมันไม่ใช่วิธี Backup
[COLOR=#ff0000]คำเตือน [/COLOR]การทำ Snapshot ไม่ใช่เป็นการ Backup ข้อมูลที่ดีถ้าไม่ได้ทำ RAID ดังนั้นผู้ใช้งานจะต้องทำ Backup แบบปกติแยกต่างหากไว้ด้วยนะครับ
ขอบคุณทุกความเห็นนะครับจะได้แบ่งปันความรู้ให้เป็นวิทยาทานครับ
Snapshot ใช้พื้นที่ “เพิ่ม” รายวัน เท่ากับปริมาณข้อมูลที่มีการเปลี่ยนแปลงในวันนั้นๆ + overhead อีกนิดหน่อย
ไม่เหมาะสมที่จะใช้เป็น backup รายวัน แต่เหมาะสำหรับการทำ snap ไว้ สั่ง mount แล้วก็อ่านออกไป backup โดยที่ระบบยังสามารถทำงานต่อไปได้ตามปกติ แม้ว่าจะมาการเขียนไฟล์ใหม่ๆ เพิ่มมาหลังจากจุดที่เราสั่ง snap แล้ว แต่ไฟล์ ดังกล่าว จะยังคงเป็น version ณ ตอนที่สั่ง snap ครับ
ผมกำลังดูเรื่องนี้อยู่เหมือนกัน
ว่าจะเอามาประยุกต์ใช้ในการทำ coldbackup สำหรับ app server บางตัวที่ต้อง shutdown ก่อนเริ่ม backup จะได้ร่นเวลาการทำ coldbackup ให้เหลือแค่
1 shutdown app server
2 make snapshot
3 start app server
4 mount snapshot
5 backup
6 unmount & merge snapshot
ถ้าเป็นของเดิมก็ต้องเป็น
1 shutdown app server
2 backup
3 start app server
ซึ่งทำให้ service ใช้ไม่ได้เป็นเวลานานเท่ากับเวลาที่เราใช้ในการ backup ครับ
open snapshot มีข้อเสียอย่างนึงคือทำให้การ access volume ต้นฉบับช้าลงครับ เพราะต้องมีการทำ cow (copy-on-write) ด้วย
ถ้าอันเดียวอาจไม่เห็นผลมาก แต่ถ้าหลายอัน หรือ snapshot บน SAN ที่ใช้งานหนักๆ จะเห็นผลเลยว่า lvm ต้นฉบับนั้นช้าลง
แต้ข้อดีเยอะ อย่างที่ จขกท. แจ้งไว้ครับ
rtsp
4
ผมไม่เคยลองจริงจังนะครับ แต่เท่าที่คุ้นๆคือ ถ้ารัน openvz อยู่บน lvm เนี่ย คำสั่ง vzdump จะมีให้ทำ lvm snapshot ก่อนรันได้ ทำให้ไม่ต้อง lock vm ครับ
ems
5
ขอบคุณมากครับ แสดงว่าไม่เหมาะกับข้อมูลที่มีการเปลี่ยนแปลงเยอะๆ ถูกต้องมั้ยครับ
แต่อย่างพวก Email Server ที่ Email มีการเข้าออกต่อวันไม่มาก แบบนี้ก็น่าจะใช้ได้ใช่มั้ยครับ
พอดีพวก Email Server ลูกค้าชอบตั้ง POP แล้วดึงข้อมูลไป พอเผลอลบข้อมูลในเครื่องแล้วชอบมาถาม Backup กับเรา
แต่ผมเปลี่ยนวิธีคิดใหม่แล้วสำหรับการ Backup ไฟล์พวก OpenVZ ด้วย Rsync
- ทำ LVM ไว้บน HDD Server ที่ใช้ทำ Backup
- ทำ Rsync Backup รายวันเหมือนเดิม
- ทำ [COLOR=#333333]snapshot เป็นรายสัปดาห์ไม่เกิน 8 [/COLOR][COLOR=#333333]snapshot ซึ่งก็จะทำให้ย้อนหลังได้สูงสุด 2 เดือนซึ่งก็นานพอแล้วละครับ[/COLOR][COLOR=#333333]
ข้อดี
- สามารถย้อนหลัง Backup ได้หลายวัน ไม่จำเป็นต้องทำทุกวันย้อนหลังได้เยอะๆ อาจทำ ทุกๆ สัปดาห์ ก็ทำให้ย้อนหลังได้มากเป็นเดือน
- ถึงการ Access ต้นฉบับจะช้าลง แต่ว่า HDD ที่ใช้ทำ Backup คงไม่ได้ใช้ I/O อยู่แล้ว จึงเป็นการดีที่จะทำกับ HDD ที่ใช้ Backup
[/COLOR]
ถ้าจำนวน snapshot มีมาก ผมว่า overhead จะสูงมากๆ เพราะว่ามันต้องวิ่งอ่านข้อมูลไล่ทีละ snapshot (อารมณ์เมหือนว่าการวางไฟล์บน layer ซ้อนขึ้นมาเรื่อยๆ ดังนั้นจะอ่านข้อมูลทั้งหมด ก็ต้องมองทุก layer)