วิธีการอัปเกรด Zimbra 9 เป็น Zimbra 10 (Daffodil) ทีละขั้นตอน

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

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

เลือกกลยุทธ์การอัปเกรดก่อนเริ่มการผลิต

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

ขั้นตอนที่ 1: บันทึกเวอร์ชัน Zimbra ปัจจุบันและสถานะการให้บริการ

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

su - zimbra
zmcontrol -v
zmcontrol status

หากบริการต่างๆ ล้มเหลวอยู่แล้ว ให้แก้ไขปัญหานั้นก่อนการอัปเกรดครั้งใหญ่ การอัปเกรดไม่ใช่เวลาที่เหมาะสมที่จะค้นพบว่าปัญหาเกี่ยวกับ LDAP, กล่องจดหมาย, MTA หรือพร็อกซี เกิดขึ้นก่อนช่วงเวลาการบำรุงรักษา นอกจากนี้ ให้ตรวจสอบ Zimlets ที่กำหนดเอง การตรวจสอบสิทธิ์ภายนอก การผสานรวม ใบรับรอง กฎการส่งต่อ สคริปต์ และการเปลี่ยนแปลงในเครื่องใดๆ ภายใต้/opt/zimbra.

ขั้นตอนที่ 2: เรียกใช้การตรวจสอบความสมบูรณ์ของฐานข้อมูลและยืนยันการสำรองข้อมูล

Zimbra ระบุzmdbintegrityreportว่าการตรวจสอบก่อนการอัปเกรดนี้มีประโยชน์อย่างยิ่ง เนื่องจากความเสียหายของ MariaDB ที่มีอยู่ก่อนแล้วอาจวินิจฉัยได้ยากขึ้นระหว่างการเปลี่ยนแปลงเวอร์ชันหลัก เรียกใช้คำสั่งนี้ในฐานะzimbraผู้ใช้บนโหนดสโตร์:

su - zimbra
zmdbintegrityreport

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

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

นอกจากนี้ ให้สำรองข้อมูลการปรับแต่ง SAML และ SPNEGO แยกต่างหากด้วย Zimbra เตือนว่าการปรับแต่งเหล่านั้นอาจถูกเขียนทับระหว่างการอัปเกรด หากคุณต้องพึ่งพาไฟล์ที่กำหนดเองsalocal.cf.inกฎ SpamAssassin ที่กำหนดเอง หรือไฟล์อื่นๆ ที่จัดเก็บไว้ในเครื่อง ให้เปรียบเทียบบันทึกการเผยแพร่ปัจจุบันกับไฟล์ที่อาจถูกแทนที่ และบันทึกสำเนาไว้ก่อนเริ่มดำเนินการ

ขั้นตอนที่ 3: สำหรับการติดตั้งใช้งานแบบหลายเซิร์ฟเวอร์ ให้ปฏิบัติตามลำดับบทบาท

การติดตั้งบนเซิร์ฟเวอร์เดียวสามารถดำเนินการต่อไปยังตัวติดตั้งได้โดยตรงหลังจากตรวจสอบเบื้องต้นเสร็จสิ้น แต่สำหรับการติดตั้งบนหลายเซิร์ฟเวอร์ จำเป็นต้องมีลำดับขั้นตอนที่ชัดเจน ลำดับขั้นตอนที่ Zimbra กำหนดไว้คือ เริ่มจาก LDAP master ก่อน จากนั้นจึงเป็น LDAP replicas, เซิร์ฟเวอร์ MTA, เซิร์ฟเวอร์พร็อกซี, License Daemon Service, เซิร์ฟเวอร์ OnlyOffice และสุดท้ายคือเซิร์ฟเวอร์ mailstore

ต้องอัปเกรดและตรวจสอบให้แน่ใจว่ามาสเตอร์ LDAP ทำงานอยู่ก่อนจึงจะดำเนินการกับบทบาทอื่นๆ ได้ ในระหว่างการอัปเกรดแบบค่อยเป็นค่อยไป Zimbra ยังเตือนด้วยว่า หากมีการใช้งาน Zimbra 10 และที่เก็บอีเมลเวอร์ชันเก่าร่วมกันzimbraReverseProxyUpstreamLoginServersควรมีเฉพาะเซิร์ฟเวอร์กล่องจดหมาย Zimbra 10 เท่านั้น มิเช่นนั้น ผู้ใช้ในที่เก็บอีเมล Zimbra 10 อาจพบปัญหาในการเข้าสู่ระบบ Modern Web App

ขั้นตอนที่ 4: ตรวจสอบระบบปฏิบัติการ พื้นที่ว่าง และใบอนุญาต

อย่าคิดว่าระบบปฏิบัติการของเซิร์ฟเวอร์ Zimbra 9 ยังคงใช้งานได้ดีในปี 2026 เอกสารประกอบของ Zimbra ในปัจจุบันแสดงให้เห็นว่าแพลตฟอร์มที่รองรับนั้นใหม่กว่า ได้แก่ RHEL/Rocky/Oracle Linux 9 และ Ubuntu 22.04 ในขณะที่การสนับสนุน Ubuntu 24.04 เริ่มใช้งานได้ทั่วไปใน Zimbra 10.1.17 บันทึกการเผยแพร่ Zimbra 10.1.21 ยังระบุด้วยว่าการสนับสนุน Ubuntu 18.04 จะถูกยกเลิกในเวอร์ชันถัดไป หากโฮสต์ Zimbra 9 ของคุณอยู่บนแพลตฟอร์มเก่า การติดตั้งใหม่และย้ายข้อมูลอาจเหมาะสมกว่าการเปลี่ยนแปลง Zimbra ครั้งใหญ่พร้อมกับการเปลี่ยนระบบปฏิบัติการ

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

Zimbra 10.1 ได้เปลี่ยนแปลงระบบการอนุญาตใช้งานด้วยเช่นกันlicense.xmlรูปแบบเก่าไม่ได้รับการสนับสนุนในเวอร์ชัน 10.1 คุณต้องใช้รหัสอนุญาตใช้งานแบบตัวอักษรและตัวเลข 18-26 ตัวแบบใหม่ก่อนการติดตั้งหรืออัปเกรด โปรดขอรับรหัสที่ถูกต้องจาก Zimbra ก่อนช่วงเวลาการบำรุงรักษาสิ้นสุดลง หน้าดาวน์โหลดอย่างเป็นทางการของ Zimbraได้แจ้งเตือนลูกค้าอย่างชัดเจนว่าต้องมีรหัสอนุญาตใช้งานเวอร์ชัน 10.1 ใหม่ก่อนเริ่มดำเนินการ

ขั้นตอนที่ 5: ดาวน์โหลด Zimbra 10.1 เวอร์ชันที่ถูกต้อง

ดาวน์โหลดแพ็กเกจที่ตรงกับระบบปฏิบัติการและสถาปัตยกรรม CPU ที่รองรับจากพื้นที่ดาวน์โหลดอย่างเป็นทางการของ Zimbra ห้ามนำแพ็กเกจที่สร้างขึ้นสำหรับระบบปฏิบัติการอื่นมาใช้ซ้ำ เก็บไฟล์เก็บถาวรไว้ในไดเร็กทอรีการทำงาน เช่น/var/tmp.

หาก Zimbra แสดงค่าตรวจสอบความถูกต้อง (checksum) สำหรับแพ็กเกจที่คุณดาวน์โหลด โปรดตรวจสอบก่อนแตกไฟล์ การคำนวณค่าตรวจสอบความถูกต้องในเครื่องจะมีลักษณะดังนี้:

sha256sum zcs.tgz

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

ขั้นตอนที่ 6: แตกไฟล์และเริ่มโปรแกรมติดตั้งการอัปเกรด

กระบวนการอัปเกรดแบบติดตั้งทับ (in-place) ของ Zimbra ที่ระบุไว้ในเอกสาร ไม่จำเป็นต้องให้คุณหยุดบริการด้วยตนเองก่อนการอัปเกรด ตัวติดตั้งจะหยุดและเริ่มบริการตามความจำเป็น จากนั้นrootให้แตกไฟล์ที่ดาวน์โหลดมา เข้าไปในไดเร็กทอรีที่แตกไฟล์แล้ว และเรียกใช้คำสั่งinstall.sh:

cd /var/tmp
tar xzvf zcs.tgz
cd <expanded-directory>
./install.sh

Zimbra แนะนำให้ทำการอัปเกรดภายในโปรแกรมจัดการเทอร์มินัลแบบมัลติเพล็กเซอร์ เช่น โดยscreenเฉพาะอย่างยิ่งในการเชื่อมต่อ SSH ระยะไกล เพื่อป้องกันไม่ให้การอัปเกรดที่ใช้เวลานานต้องหยุดชะงักหากการเชื่อมต่อหลุด:

screen ./install.sh

ขั้นตอนที่ 7: ตอบคำถามของโปรแกรมติดตั้งอย่างรอบคอบ

โปรแกรมติดตั้งจะตรวจพบการติดตั้ง Zimbra ที่มีอยู่แล้วและแสดงเส้นทางการอัปเกรด คำแนะนำปัจจุบันของ Zimbra ระบุให้ยอมรับการใช้ที่เก็บแพ็กเกจของ Zimbra เมื่อได้รับแจ้ง จากนั้นยืนยันว่าคุณต้องการอัปเกรด สำหรับการอัปเกรดเป็นเวอร์ชัน 10.1 บนเครื่องเดียวzimbra-license-daemonแพ็กเกจนี้จำเป็น หากปฏิเสธจะทำให้การอัปเกรดไม่สามารถดำเนินการต่อได้

ก่อนตอบคำถามสุดท้าย โปรดตรวจสอบรายการแพ็กเกจ ในขั้นตอนนี้The system will be modified. Continue? [N]ให้ป้อนYเฉพาะเมื่อคุณแน่ใจแล้วว่าการสำรองข้อมูล ใบอนุญาต แหล่งที่มาของแพ็กเกจ พื้นที่จัดเก็บ และการสื่อสารสำหรับการบำรุงรักษาพร้อมใช้งานแล้ว จากนั้นโปรแกรมติดตั้งจะหยุดบริการเก่า แทนที่แพ็กเกจ กู้คืนการกำหนดค่า ดำเนินการอัปเกรด และเริ่มต้นบริการใหม่ สภาพแวดล้อมขนาดใหญ่อาจใช้เวลานานกว่าระบบทดสอบขนาดเล็กมาก

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

ขั้นตอนที่ 8: ตรวจสอบบริการ เวอร์ชัน การไหลของอีเมล และการเข้าถึงของลูกค้า

หลังจากติดตั้งเสร็จแล้ว ให้กลับไปที่zimbraบัญชีผู้ใช้ และตรวจสอบสถานะบริการและเวอร์ชันที่ติดตั้ง:

su - zimbra
zmcontrol status
zmcontrol -v

จากนั้นทดสอบพฤติกรรมที่ผู้ใช้ใช้งานจริง ได้แก่ การรับและส่งออก SMTP, การส่งอีเมลภายใน, IMAP/POP (หากเปิดใช้งาน), การเข้าสู่ระบบเว็บแอปพลิเคชันแบบสมัยใหม่และแบบคลาสสิก, กล่องจดหมายที่ได้รับมอบหมาย, การดำเนินการปฏิทิน, การซิงโครไนซ์บนมือถือ, การเชื่อมต่อ Outlook (หากได้รับอนุญาต), การตรวจสอบสิทธิ์ภายนอก, Zimlets, การสำรองข้อมูล, การตรวจสอบ และแอปพลิเคชันใดๆ ที่ใช้ส่วนต่อประสาน Zimbra SOAP หรือ EWS

อย่าข้ามขั้นตอนหลังการอัปเกรดที่เฉพาะเจาะจงสำหรับแต่ละเวอร์ชัน บันทึกประจำรุ่นของ Zimbra 10.1.19 และเวอร์ชันที่ใหม่กว่า ระบุถึงการแก้ไขปัญหา SNMP ที่ได้รับการอัปเดตสำหรับลูกค้าที่อัปเกรดจากเวอร์ชัน 10.0.x, 9.0.x หรือ 8.8.15 สำหรับการอัปเกรดเวอร์ชันใช้งานจริงในปี 2026 โปรดอ่านบันทึกการแก้ไขล่าสุดและใช้มาตรการแก้ไขที่จำเป็นหลังจากอัปเกรดครั้งใหญ่เสร็จสิ้น Zimbra 10.1.21 ยังรวมถึงการแก้ไขด้านความปลอดภัยที่ส่งผลกระทบต่อ Classic Web Client, การตรวจสอบสิทธิ์ WebDAV, การกู้คืนรหัสผ่าน, OpenJDK, NGINX และการผสานรวม ซึ่งเป็นอีกเหตุผลหนึ่งที่ไม่ควรหยุดอยู่ที่เวอร์ชัน 10.0 ที่ล้าสมัย

เมื่อใดที่คุณควรเปลี่ยนเส้นทางแทนที่จะเดินหน้าต่อไปในเส้นทางเดิม?

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

• ระบบปฏิบัติการปัจจุบันล้าสมัยหรือใกล้จะหมดระยะเวลาการสนับสนุนจาก Zimbra แล้ว
• รายงานการตรวจสอบความสมบูรณ์ของฐานข้อมูลระบุข้อผิดพลาดที่คุณไม่สามารถอธิบายได้
• คุณมีโมดูล NG และยังไม่ได้ตรวจสอบขั้นตอนการย้ายข้อมูลที่รองรับ
• SAML, SPNEGO, Zimlets, การปรับแต่งโปรแกรมป้องกันไวรัส/ป้องกันสแปม หรือการผสานรวมจากบุคคลที่สาม เป็นสิ่งที่มีความสำคัญต่อธุรกิจและยังไม่ได้รับการทดสอบกับเวอร์ชัน 10.1
• นอกจากนี้ คุณยังกำลังเปลี่ยนแปลงสถาปัตยกรรมจัดเก็บข้อมูล ชื่อโฮสต์ การออกแบบเครือข่าย หรือฮาร์ดแวร์ไปพร้อมกันด้วย
• คุณไม่สามารถขอรับใบอนุญาตเวอร์ชัน 10.1 ที่จำเป็นได้ก่อนช่วงเวลาการบำรุงรักษา

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

รายการตรวจสอบการอัปเกรดเชิงปฏิบัติ

• โปรดตรวจสอบเวอร์ชัน Zimbra 9 ที่แน่นอนและสถานะการให้บริการในปัจจุบัน
• โปรดตรวจสอบบันทึกการเปลี่ยนแปลงเวอร์ชัน 10.1 ล่าสุดและคู่มือการอัปเกรดอย่างเป็นทางการ
• เรียกใช้งานzmdbintegrityreportบนโหนดร้านค้าและแก้ไขข้อผิดพลาด
• สร้างและตรวจสอบการสำรองข้อมูลแบบเต็ม บันทึกการตั้งค่าการตรวจสอบสิทธิ์และการกรองแบบกำหนดเอง
• ตรวจสอบว่าระบบปฏิบัติการปลายทางรองรับเวอร์ชัน 10.1 ที่ต้องการหรือไม่
• โปรดขอรับรหัสใบอนุญาตเวอร์ชัน 10.1 ใหม่ อย่าใช้รหัสใบอนุญาตlicense.xmlเก่า
• ตรวจสอบความจุของดิสก์และดาวน์โหลดแพ็คเกจแพลตฟอร์มที่ถูกต้อง
• สำหรับการใช้งานแบบหลายเซิร์ฟเวอร์ ให้ปฏิบัติตามลำดับบทบาทที่ระบุไว้ในเอกสาร
• เรียกใช้โปรแกรมติดตั้งในscreenเซสชันเทอร์มินัลแบบถาวร หรือเทียบเท่า
• ตรวจสอบบริการ เวอร์ชัน การไหลของอีเมล ไคลเอ็นต์เว็บ การตรวจสอบสิทธิ์ การผสานรวม และการตรวจสอบ
• ดำเนินการแก้ไขปัญหาหลังการอัปเกรดตามเวอร์ชัน และสร้างการสำรองข้อมูลแบบเต็มใหม่

สรุป

สำหรับเซิร์ฟเวอร์ Zimbra 9 ที่ทำงานได้ดีบนระบบปฏิบัติการที่รองรับและมีการกำหนดค่าแบบทั่วไป การอัปเกรดแบบติดตั้งทับไปยังเวอร์ชัน Zimbra 10.1 Daffodil ปัจจุบันมักจะเป็นวิธีที่ตรงที่สุด แต่สำหรับระบบปฏิบัติการที่เก่า การติดตั้งโมดูล NG ที่ซับซ้อน หรือเซิร์ฟเวอร์ที่ต้องการการเปลี่ยนแปลงโครงสร้างพื้นฐานครั้งใหญ่ การติดตั้งและย้ายข้อมูลใหม่ทั้งหมดอาจให้ขอบเขตการทำงานที่ชัดเจนกว่า แม้ว่าจะต้องใช้ความพยายามมากขึ้นก็ตาม

การตรวจสอบคุณภาพที่สำคัญไม่ได้อยู่ที่ว่าการinstall.shอัปเกรดจะเสร็จสมบูรณ์หรือไม่ การอัปเกรดที่ประสบความสำเร็จหมายความว่าเซิร์ฟเวอร์ใช้แพทช์ 10.1 ที่รองรับ บริการที่จำเป็นทั้งหมดทำงานได้อย่างปกติ การรับส่งอีเมลและการเข้าถึงของผู้ใช้ทำงานได้ตามที่คาดไว้ การผสานรวมแบบกำหนดเองได้รับการทดสอบซ้ำแล้ว ใบอนุญาตใช้งานได้ การแก้ไขปัญหาเฉพาะเวอร์ชันเสร็จสมบูรณ์ และคุณมีข้อมูลสำรองหลังการอัปเกรดที่อัปเดตแล้ว โปรด เปิด คู่มือการอัปเกรด Zimbra Daffodil อย่างเป็นทางการบันทึกการเผยแพร่ 10.1.21 ปัจจุบันและเอกสารประกอบการใช้งานหลายเซิร์ฟเวอร์อย่างเป็นทางการไว้ในระหว่างการวางแผน เนื่องจากแหล่งข้อมูลเหล่านั้นควรมีความสำคัญเหนือกว่าคำสั่งตัวอย่างเก่าๆ