SSD Nodes Learn 🎉 VPS החל מ־$5.50/חודש
מדריכים Matt Connorמאת Matt Connor · עודכן 2026-08-13

Ubuntu LTS לעומת גרסת ביניים: מה מתאים לשרת שלך?

ההבדל המרכזי הוא משך התמיכה: גרסת LTS מציעה 5 שנים של עדכוני אבטחה יציבים, בעוד גרסת ביניים מסתיימת לאחר 9 חודשים ומחייבת שדרוג מערכת. גלו מה מתאים לצרכי השרת שלכם.

ההבדל בין Ubuntu LTS לגרסאות ביניים: התשובה הקצרה

הבחירה בין גרסת LTS של Ubuntu לבין גרסת ביניים בשרת מסתכמת במספר אחד: כמה זמן הגרסה תמשיך לקבל עדכוני אבטחה. גרסת LTS מקבלת חמש שנים של תחזוקת אבטחה סטנדרטית. גרסת ביניים מקבלת תשעה חודשים, ולאחר מכן העדכונים נפסקים, כך שחובה לשדרג או לבנות מחדש את המערכת. הריצו גרסת LTS על כל שירות שאנשים אחרים תלויים בו. הריצו גרסת ביניים רק במקומות שבהם בנייה מחדש היא פעולה שניתן לבצע ללא צורך באישור מאף אחד.

LTS פירושו Long Term Support (תמיכה לטווח ארוך). Canonical מפרסמת גרסת LTS אחת בכל שנתיים, באפריל של שנים זוגיות, וגרסת ביניים אחת בכל שישה חודשים בפרק הזמן שביניהן. גרסת 26.04 LTS שוחררה ב-23 באפריל 2026 ותחזוקת האבטחה הסטנדרטית שלה נמשכת עד שנת 2031. גרסת 26.10 צפויה ב-15 באוקטובר 2026, והיא גרסת ביניים, לכן התמיכה בה מסתיימת ביולי 2027.

משך התמיכה בכל גרסת Ubuntu

ChartSupport length and release upgrades needed over five years
The data behind this chart
[
  {
    "label": "LTS, standard support",
    "support_months": 60,
    "upgrades_over_5_years": 1
  },
  {
    "label": "LTS with Ubuntu Pro",
    "support_months": 120,
    "upgrades_over_5_years": 0
  },
  {
    "label": "Interim release",
    "support_months": 9,
    "upgrades_over_5_years": 10
  }
]

אלו הם נתוני המדיניות הרשמיים של Canonical נכון לאוגוסט 2026, ולא מדידות משרת בדיקה. גרסת LTS כוללת 60 חודשים של תחזוקת אבטחה סטנדרטית, מה שמתרגם ל-1 שדרוגי גרסה מתוכננים בתוך חמש שנים. גרסת ביניים (interim release) כוללת 9 חודשים. הישארות במסלול גרסאות הביניים לאורך אותן חמש שנים דורשת 10 שדרוגי גרסה, כיוון שלא ניתן לדלג על גרסה ובחמש שנים נכללות עשר גרסאות כאלו.

מנוי Ubuntu Pro מעלה את נתון ה-LTS ל-120 חודשים, כלומר עשר שנים, ומרחיב את הכיסוי מרכיב ה-main לכל הארכיון. נכון לאוגוסט 2026, Pro ניתן בחינם לשימוש אישי עבור עד חמישה מחשבים, מה שמכסה את רוב ציי ה-VPS הקטנים. אין מקבילה לכך בגרסאות ביניים. תשעה חודשים הם מלוא ההצעה, ושום מנוי אינו מאריך אותם.

מה המשמעות של תשעה חודשים בשרת אמיתי

ניקח את 26.10 כדוגמה לעבודה. הגרסה משתחררת ב-15 באוקטובר 2026 ותחזוקת האבטחה שלה מסתיימת ביולי 2027, לפי אותו דפוס של תשעה חודשים שהסתיים ב-25.10 ביולי 2026. בקריאה לוח-שנתית, זה נראה כמו חלון תחזוקה אחד בכל שלושה רבעונים. הקריאה הזו שגויה, והיא שגויה בכיוון היקר.

שרשרת המועדים, ניתוח המקרה

מתקינים את 26.10 באוקטובר 2026 וממתינים עד לרגע הבטוח האחרון. משדרגים ל-27.04 ביוני 2027, רגע לפני ש-26.10 מסתיימת. אולם 27.04 שוחררה באפריל 2027, ותקופת תשעת החודשים שלה מסתיימת בינואר 2028. המועד השני שלכם מגיע שבעה חודשים אחרי הראשון, לא תשעה.

משדרגים שוב בדצמבר 2027 ל-27.10, ששוחררה באוקטובר 2027 ומסתיימת ביולי 2028. מכאן הדפוס קבוע. אתם תמיד גרסה אחת מאחורי הגרסה הנוכחית, כך שמועד סיום מגיע בערך כל שישה חודשים. תשעה חודשים הם אורך התמיכה של גרסה בודדת. זהו אינו המרווח בין חלונות התחזוקה שלכם.

שדרוג גרסה מחליף את מערכת ההפעלה במקומה. do-release-upgrade משכתב את מקורות ה-apt, משבית מאגרים של צד שלישי, משנה את הגרסה של כמעט כל חבילה מותקנת, עוצר כדי לשאול על קובצי תצורה שערכתם, ומבצע reboot בסיום. זו הסיבה שמדובר בחלון מתוכנן ולא במשימת רקע.

הריצו זאת דרך ssh והכלי יגן עליכם מניתוק החיבור שלכם. הוא מתחיל סשן screen משלו ופותח sshd שני, תוך שהוא מודיע לכם על כך מראש:

To make recovery in case of failure easier, an additional sshd will
be started on port '1022'. If anything goes wrong with the running ssh
you can still connect to the additional one.

אפשרו לו. אם ה-firewall שלכם או ה-firewall הרשתי הנפרד של ספק התשתית חוסם את 1022, מנגנון הגיבוי הזה לא יהיה קיים, וניתוק חיבור במצב כזה ישאיר אתכם עם סט חבילות ששודרג חלקית. הרצה בתוך tmux או screen באופן עצמאי תעניק לכם את אותה הגנה בכל שרת.

ההנחיות לגבי קובצי תצורה הן מה שהופך שדרוג של חמש-עשרה דקות לשעה שלמה:

Configuration file '/etc/ssh/sshd_config'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?

שמירה על הקובץ שלכם משמעותה שתחמיצו כל שינוי בברירת המחדל החדשה. קבלת הקובץ של מתחזק החבילה משמעותה שהקשחת האבטחה שלכם נמחקה עד שתחזירו אותה. אף אחת מהתשובות אינה בטוחה ללא ידיעה מה השתנה באותה גרסה, וזו הסיבה שקריאת הערות השחרור היא חלק מהחלון ולא שיעורי בית אופציונליים.

כעת הכפילו זאת במספר השרתים. שרת VPS אחד במסלול הביניים דורש עשרה חלונות שדרוג בחמש שנים. חמישה שרתי VPS דורשים חמישים, אלא אם כל שרת הוא חד-פעמי ונבנה מחדש מתוך image. חמישה שרתים במסלול LTS דורשים חמישה שדרוגים באותה תקופה, ואתם בוחרים את החודש שבו כל אחד מהם יתבצע.

מדוע לא ניתן לדלג על גרסת Ubuntu

נתיבי השדרוג קבועים. גרסת ביניים משתדרגת לגרסה הבאה אחריה, תהיה אשר תהיה. גרסת LTS משתדרגת ישירות לגרסת ה-LTS הבאה, או לגרסת הביניים הבאה אם תבקשו זאת. שום דבר לא משתדרג בשני שלבים בבת אחת. מעבר מ-26.10 ל-28.04 LTS מחייב מעבר דרך 27.04 ו-27.10, או התקנה מחדש של המכונה.

כדאי להכיר את המנגנון, כיוון שהוא מבהיר שהכלל אינו גמיש. do-release-upgrade מושך קובץ meta-release מהכתובת changelogs.ubuntu.com, ולאחר מכן מוריד כלי שדרוג שנבנה עבור מעבר ספציפי אחד. Canonical בונה ובודקת מעבר אחד בכל פעם, כך שקפיצה המדלגת על גרסה אינה נתמכת בכלי או בבדיקות. כלי השדרוג אינו מסרב מתוך זהירות; פשוט אין לו מה להציע.

הגרסה שתוצע לכם נקבעת על פי שורת הגדרה אחת:

grep -i prompt /etc/update-manager/release-upgrades
sudo do-release-upgrade -c

Prompt=lts מציע רק את גרסת ה-LTS הבאה. Prompt=normal מציע את הגרסה הבאה, בין אם היא LTS ובין אם לא. Prompt=never אינו מציע דבר, וזו הדרך למנוע מעמית לעבודה בעל כוונות טובות להתחיל שדרוג שלא תכננתם. בגרסה שאינה LTS, lts מתנהג בדיוק כמו normal, כיוון שהגרסה הבאה אחרי 26.10 היא 27.04 בשתי ההגדרות. הבדיקה מדפיסה Checking for a new Ubuntu release ולאחריה שורת New release ... available. או No new release found..

כלל תזמון נוסף מפתיע משתמשים רבים. שדרוג מ-LTS ל-LTS אינו מוצע ביום שבו גרסת ה-LTS החדשה משוחררת. הוא נפתח עם גרסת ה-point release הראשונה, ו-26.04.1 מתוכננת ל-27 באוגוסט 2026. שרת 24.04 עם Prompt=lts שהשיב No new release found. לאורך קיץ 2026 לא היה תקול. הוא פעל לפי המדיניות. כאשר הנתיב נפתח, השדרוג מ-24.04 ל-26.04 LTS הוא התהליך שיש לתכנן ולתרגל.

מתי גרסת ביניים היא הבחירה הנכונה

ארבעה מקרים שבהם היא אכן עדיפה:

  • אתם זקוקים לגרסת kernel או userspace שאינה קיימת במאגר ה-LTS, על השרת הזה, עכשיו.
  • המכונה היא שרת בנייה (build host), מריץ CI או סביבת בדיקות שאתם משחזרים מ-image, כך ששדרוג הוא למעשה יצירת מופע חדש במקום חלון תחזוקה.
  • תכונת חומרה או hypervisor הושקה לאחר הקפאת ה-LTS, ולא קיים עבורה backport.
  • אתם בודקים מה יכיל ה-LTS הבא. גרסת 28.04 מורכבת מ-26.10, 27.04 ו-27.10, ועלות גילוי שינוי שובר תאימות ב-VPS משני נמוכה מאשר גילויו בשרת קריטי.

רוב האנשים שבוחרים בגרסת ביניים מחפשים חבילה אחת חדשה יותר, לא הפצה חדשה יותר. קיימים שני פתרונות זולים יותר. ה-hardware enablement stack מביא kernels מגרסאות מאוחרות יותר לתוך ה-LTS: ב-24.04 מדובר ב-sudo apt install linux-generic-hwe-24.04, והוא מתעדכן בכל point release, החל מהשני. עבור יישום בודד, container image או מאגר רשמי של היצרן משדרגים רכיב אחד במקום את מערכת ההפעלה כולה.

מתי גרסת ביניים היא בחירה שגויה

  • כל שירות שיש לו משתמשים משלמים או כוננות (on-call). אתם מקבלים על עצמכם שדרוג חובה פעמיים בשנה בתמורה לגרסאות חבילות שאולי לעולם לא תשתמשו בהן.
  • כל שרת שבו unattended-upgrades מבצע עבורכם את עדכוני האבטחה. האוטומציה הזו טובה רק כטיב מאגר האבטחה שממנו היא מושכת עדכונים.
  • צי שרתים שאתם משדרגים ידנית, כיוון שהעלות האמיתית היא חלון תחזוקה אחד כפול מספר השרתים.
  • כל רכיב שאתם מתקינים ולא בודקים במשך שנה. גרסת ביניים ששכחתם ממנה הופכת לשרת חשוף לאינטרנט ללא עדכונים כעבור תשעה חודשים.

הכשל האחרון הוא שקט, וזה מה שהופך אותו למסוכן. כאשר גרסה מגיעה לסוף חייה, החבילות שלה עוברות ל-old-releases.ubuntu.com, ולכן sudo apt update מתחיל להיכשל מול archive.ubuntu.com עם שגיאות 404. רשימות החבילות בדיסק הופכות למיושנות. unattended-upgrades ממשיך לרוץ לפי הטיימר שלו וממשיך לכתוב שורות כאלו לתוך /var/log/unattended-upgrades/unattended-upgrades.log:

No packages found that can be upgraded unattended and no pending auto-removals

השורה הזו נראית אותו דבר בשרת מעודכן לחלוטין ובשרת שהגרסה שלו פגה לפני ארבעה חודשים. אלא אם מישהו קורא את שגיאות ה-apt או עוקב אחר תאריך סוף החיים של הגרסה, שום דבר במכונה לא יגיד לכם באיזה מצב היא נמצאת.

סוג השינוי שמגיע תחילה למסלול ה-interim

במרץ 2026 הציע מהנדס של Canonical, בפורום Ubuntu discourse, להסיר את ה-bootloader החתום GRUB שמגיע כחלק מ-secure boot בגרסה 26.10. ההצעה מסירה את מנהלי ההתקנים (drivers) עבור מערכות הקבצים btrfs, hfsplus, xfs ו-zfs, את מנתחי (parsers) התמונות בפורמט JPEG ו-PNG, את טבלאות המחיצות של Apple, את /boot על גבי LVM, את ה-software RAID למעט RAID 1, ואת ה-/boot המוצפן ב-LUKS. הסיבה המוצהרת היא שמנתחים בתוך ה-bootloader הם מקור חוזר לבאגים אבטחתיים, וכי הלוגיקה של אחסון והצפנה צריכה להימצא ב-initramfs, מערכת הקבצים הקטנה ב-RAM שה-kernel טוען לפני ה-root האמיתי. נכון לאוגוסט 2026, מדובר בהצעה שנמצאת בדיון, ולא בשינוי שכבר שוחרר.

עבור רוב שרתי ה-VPS, שינוי זה לא ישנה דבר, כיוון שהם עולים ללא secure boot מתוך /boot פשוט מסוג ext4 על גבי טבלת מחיצות GPT. בדקו את השרת שלכם במקום להניח הנחות. אם ה-root שלכם הוא ZFS, או ש-/boot נמצא על btrfs או בתוך LUKS, זהו בדיוק סוג השינוי שתפגשו ראשון במסלול ה-interim, והעצה שניתנה באותו שרשור למשתמשים המושפעים היא להישאר בגרסת LTS. עצה זו מסכמת את כל הטיעון במשפט אחד. גרסאות interim הן המקום שבו בוחנים שינויים. גרסת LTS היא המקום שבו הם מגיעים לאחר שנתיים של גרסאות interim שחשפו מה הם עלולים לשבור.

אותו דפוס מופיע בדרכים קטנות יותר בכל גרסת interim. גרסאות ברירת המחדל של מסד הנתונים, סביבת ההרצה של השפה ותצורת ה-init מתקדמות, ולכן קובצי תצורה שעבדו עלולים להפסיק לעבוד. קידום ברירות המחדל הוא התפקיד שלשמו קיימת גרסת interim, מה שאומר שקריאת הערות השחרור (release notes) לפני כל אחד מעשרת השדרוגים הללו היא חלק מהמחיר שהסכמתם לשלם.

בחירת ערוץ ההפצה בעת הקמת השרת

בחרו את ערוץ ההפצה (track) בזמן ההתקנה, שכן שינויו לאחר מכן מחייב התקנה מחדש או שרשרת שדרוגים. בשרת חדש, ארבע פקודות יבהירו לכם היכן אתם עומדים:

lsb_release -a
grep -i prompt /etc/update-manager/release-upgrades
sudo do-release-upgrade -c
pro security-status

הפקודה lsb_release -a אמורה להציג את גרסת ההפצה שהתכוונתם להתקין, ובגרסת LTS שורת התיאור מסתיימת ב-LTS. השורה Prompt צריכה להתאים לערוץ שבחרתם, ולא לגרסה המקרית שהגיעה עם ה-image של ספק השרתים. הפקודה do-release-upgrade -c על גרסת LTS עדכנית אמורה להחזיר No new release found.. אם היא מציעה גרסת ביניים (interim release), סימן ש-Prompt מוגדר ל-normal, ומישהו צריך להחליט אם זה נעשה במכוון. הפקודה pro security-status מדווחת כמה מהחבילות המותקנות מכוסות על ידי איזה ערוץ עדכונים, ומציינת בבירור מתי המכונה אינה רשומה למנוי.

לאחר מכן, רשמו את תאריך סוף התמיכה (EOL) במקום שבו תראו אותו שוב, לצד שאר הערות ההקמה של אותו שרת. מידע זה שייך לשאר הפעולות ב-עשר הדקות הראשונות ב-VPS חדש, כיוון שתאריך תמיכה שקיים רק בזיכרון של מישהו הוא זה שיפוג ללא התראה. אם אתם מנסים להימנע לחלוטין מהתחלופה של כל שישה חודשים, כדאי להקדיש שעה לקריאת מודל ההפצה של FreeBSD בהשוואה ל-Linux לפני שאתם מחייבים צי שרתים לאחת מהן.

FAQ

האם כדאי להריץ גרסת ביניים (interim release) של Ubuntu על שרת ייצור?

ברוב המוחלט של המקרים, לא. גרסת ביניים מפסיקה לקבל עדכוני אבטחה תשעה חודשים לאחר שחרורה, כך שעבודה בסביבת ייצור על מסלול זה מחייבת חלון שדרוג קבוע פעמיים בשנה, לנצח. החריגים היחידים הם מכונות שאתם ממילא בונים מחדש מתוך image, כמו CI runners או שרתי build, שבהם שדרוג הוא למעשה יצירת instance חדש ולא חלון תחזוקה. אם משתמשים אמיתיים תלויים בשרת, התקינו גרסת LTS והשקיעו את הזמן שחסכתם במשימות אחרות.

לכמה זמן נתמכת גרסת ביניים של Ubuntu?

תשעה חודשים. גרסת 26.10 משתחררת ב-15 באוקטובר 2026 ותחזוקת האבטחה שלה מסתיימת ביולי 2027, באותו דפוס שבו הסתיימה התמיכה ב-25.10 ביולי 2026. כל גרסת ביניים פועלת כך: שחרור באפריל או באוקטובר, וסיום תשעה חודשים לאחר מכן. גרסת LTS מקבלת חמש שנים של תחזוקת אבטחה סטנדרטית, המורחבת לעשר שנים עם Ubuntu Pro, אשר נכון לאוגוסט 2026 זמין בחינם לשימוש אישי עבור עד חמש מכונות.

האם ניתן לדלג על גרסאות Ubuntu בעת שדרוג?

לא. do-release-upgrade מתבצע צעד אחר צעד: גרסת ביניים עוברת לגרסה הבאה אחריה, וגרסת LTS יכולה לעבור ישירות לגרסת ה-LTS הבאה. מעבר מ-26.10 ל-28.04 LTS מחייב ביצוע שדרוג דרך 27.04 ו-27.10 תחילה, או התקנה מחדש של המכונה. Canonical בונה ובודקת מעבר אחד בכל פעם, וכלי השדרוג מוריד רכיבים ספציפיים עבור אותו דילוג, כך שדילוג כפול אינו נתמך ואינו מוצע לעולם.

מה קורה כאשר גרסת ה-Ubuntu שלי מגיעה לסוף חייה?

החבילות שלה עוברות ל-old-releases.ubuntu.com, ולכן sudo apt update מתחיל להיכשל מול archive.ubuntu.com עם שגיאות 404, ולא מתפרסמים יותר עדכוני אבטחה עבור גרסה זו. שום דבר במכונה לא מתריע על כך. השרת ממשיך לעבוד ולהעביר תעבורה, בעוד כל פגיעות חדשה שמתגלה נותרת פתוחה. התאוששות במצב כזה מחייבת שדרוג גרסה תחת לחץ זמן, או בנייה מחדש, לכן עקבו אחר התאריכים במקום לחכות להופעת תסמינים.

האם ה-kernel של גרסת LTS ישן מדי עבור חומרה חדשה?

בדרך כלל לא, כיוון שגרסת LTS לא שומרת על ה-kernel המקורי שלה למשך חמש שנים. ה-hardware enablement stack, הידוע כ-HWE, מביא kernels מגרסאות מאוחרות יותר אל תוך ה-LTS בנקודות שחרור (point releases), והתקנת שרת יכולה להצטרף לכך באמצעות חבילה כמו linux-generic-hwe-24.04. בדקו מה אתם מריצים בעזרת uname -r לפני שאתם מניחים שה-kernel הוא הגורם החוסם. אם הרכיב החסר הוא גרסת userspace ולא ה-kernel, שימוש ב-container או ב-repository של הספק הוא שינוי קטן בהרבה מאשר העברת כל המכונה למסלול גרסאות הביניים.