האם עלינו למחוק את הקובץ "wp-links-opml.php" באתר WordPress שלנו? השפעת האבטחה

תשובה קצרה: מחיקת הקובץ wp-links-opml.php באתר WordPress שלכם אינה צעד אבטחה הכרחי לרוב האתרים המודרניים; עם זאת, אם אתם לא משתמשים בתכונת Blogroll או בקישורים ישנים, סגירת הגישה החיצונית לקובץ זה היא מהלך סביר להקטנת שטח ההתקפה. הגישה הבטוחה ביותר היא קודם כל לגבות, לוודא שהקובץ אכן לא בשימוש, ולאחר מכן לחסום את הגישה ברמת השרת או להוסיף כלל חומת אש במקום למחוק אותו. כי מחיקת קבצי הליבה של WordPress עשויה לגרום לקובץ לחזור בעדכונים, לאופציות של התראות בבדיקות של שלמות קובץ, ולעיתים גם להתנהגויות בלתי צפויות בחלק מהתוספים הישנים.

במאמר זה נבחן שלב אחר שלב מהו הקובץ wp-links-opml.php, מהו הסיכון האמיתי שלו מבחינת אבטחה, מתי זה הגיוני למחוק אותו, וכיצד ניתן להשבית את הקובץ הזה באתר WordPress שלכם בצורה מבוקרת יותר. המטרה היא לא לגרום לפניקה; אלא לבסס מדיניות אבטחה נקייה, ניתנת לניהול וברת קיימא של WordPress על ידי הפחתת גישות לקבצים מיותרות. במיוחד באתרים שמשתמשים בהוסטינג משותף, בהוסטינג של WordPress או בשרת מנוהל, ההחלטה הנכונה היא לא רק למחוק את הקובץ אלא גם להעריך את שכבות האבטחה הכלליות. בשלב זה גם המשאבים עבור תשתית הוסטינג בטוחה אחסון WordPress והגדרת HTTPS תעודת SSL הם חשובים.

מהו הקובץ wp-links-opml.php?

wp-links-opml.php הוא קובץ ישן המופיע בליבת WordPress. התפקיד הבסיסי שלו הוא לייצא את הקישורים בתוך WordPress או כפי שנקראו בעבר, את רשומות ה-Blogroll בפורמט OPML. OPML הוא פורמט מבוסס XML שמשמש בעיקר להעברת נתונים בין קוראי RSS, רשימות קישורים ומקורות מנוי. במהלך השנים הראשונות של WordPress, בעלי בלוגים היו לעיתים קרובות שומרים את הבלוגים המועדפים שלהם, אתרי שותפים או רשימות מקורות בתחום ה-Blogroll. הקובץ הזה הציע את הקישורים האלה בפורמט שניתן לקרוא על ידי כלים אחרים.

היום, רבים מאתרי WordPress לא משתמשים בפיצ'ר של Blogroll באופן פעיל. תבניות מודרניות, בוני דפים, תפריטים מותאמים ותוספי קישורים החליפו במידה רבה את הצורך הזה. למרות זאת, קובץ wp-links-opml.php עדיין מופיע בכמה התקנות של WordPress כחלק מהחבילה הליבתית. מצב זה לא בהכרח מעיד על פגיעות אבטחה. הקיום של קובץ לא אומר אוטומטית שהאתר ייכנס להיפגע; עם זאת, כל נקודת קצה שלא בשימוש, שניתן לגשת אליה מבחוץ, היא פוטנציאלית שטח שעליכם לעקוב אחריו.

הקשר בין OPML ל-Blogroll

קבצי OPML משמשים בדרך כלל להעברת רשימות קישורים בצורה מסודרת. לדוגמה, אם אתם שומרים 100 אתרים שונים ברשימה אחת ברשת בלוגים ישנה, ניתן לייצא את הרשימה הזו לפורמט OPML ולהעביר אותה לקורא אחר. בצד של WordPress, קובץ wp-links-opml.php עובד באותה ההיגיון של ייצוא. כאשר הקובץ נקרא, הוא יכול לקרוא את רשומות הקישורים מהמאגר ולייצר פלט בפורמט המתאים.

עם זאת, עבור אתר ארגוני טיפוסי, אתר מסחר אלקטרוני, אתר פורטפוליו או אתר חדשות, הפיצ'ר הזה לרוב לא נחוץ. שמירה על פיצ'ר שלא בשימוש, במיוחד עבור צוותי אבטחה, היא מורכבות שיש לצמצם. לכן, הנושא של מחיקת הקובץ wp-links-opml.php מתבסס למעשה על עיקרון רחב יותר: סגור פיצ'ר שלא בשימוש, שמור על נקודות קצה מיותרות במידה מוגבלת, ומדוד באופן סדיר את הקבצים והרשאות.

האם קובץ wp-links-opml.php הוא פגיעות אבטחה?

קיום של קובץ wp-links-opml.php לבדו לא צריך להיחשב כפגיעות אבטחה קריטית שניתן לנצל בכל אתר. קובץ זה הוא חלק מליבת WordPress ולרוב לא נועד להריץ קוד זדוני באופן ישיר. עם זאת, אבטחה לא נמדדת רק לפי פגיעויות קריטיות. דליפות מידע, הכוונה על ידי סורקי בוטים, אינטראקציות בלתי צפויות עם תוספים ישנים, הרשאות קובץ לא נכונות והגדרות הוסטינג חלשות יכולים להשפיע על הציון הכולל של הסיכון.

למשל, אם תוקף סורק את הקבצים באתר שלכם, הוא עשוי לשלוח בקשות לקבצים מהליבה כמו wp-links-opml.php. בקשות אלו עשויות להופיע לפעמים ביומני השרת עם תגובות של 200, 403 או 404. גם אם הקובץ לא מייצר נתונים רגישים, התוקף יכול להבין שהאתר הוא WordPress, שיש קבצים מהליבה נגישים, ואיזו רמת חיזוק אבטחה קיימת. מידע זה אינו הרסני בפני עצמו; אך הוא חלק משלב הגילוי בהתקפות ממוקדות.

מאיפה מתחיל הסיכון האמיתי?

הסיכון לרוב עולה לא מהקובץ wp-links-opml.php עצמו אלא מהתנאים הסובבים אותו. אם ישנם התנאים הבאים, יש להתייחס לנושא הזה ברצינות רבה יותר:

• ליבת WordPress, תבניות או תוספים לא עודכנו במשך זמן רב.
• בהגדרות השרת ההרשאות מוגדרות לרמה רחבה מדי כמו 777.
• אין חומת אש לאפליקציות אינטרנט או סינון בוטים בסיסי.
• האתר מכיל קישורים שאינכם רוצים שיהיו זמינים לציבור ברשומות Blogroll הישנות.
• שגיאות PHP מוצגות חיות בסביבה חיה ואם יש שגיאות שמודלות החוצה.
• יומני השרת מצביעים על בקשות בוט רבות לקובץ זה.

במקרים אלו, במקום למחוק את הקובץ wp-links-opml.php, חוסמים את הגישה, עוקבים אחרי היומנים ומשפרים את אבטחת WordPress הכוללת זו התוכנית הפעולה הנכונה יותר. הקובץ עשוי לא להיות הקישור היחיד בשרשרת ההתקפה; אך סגירתו כנקודה מיותרת עשויה להיות הגיונית.

האם עלינו למחוק את קובץ wp-links-opml.php?

התשובה הנכונה על מחיקת הקובץ wp-links-opml.php תלויה בתרחיש השימוש של האתר שלכם. אם אתם לא מייצאים קישורים של Blogroll בפורמט OPML, לא משתמשים בתכונת הקישורים הישנים ואין לכם צורך בשום אינטגרציה עם קובץ זה, טכנית מחיקתו לא תגרום לאובדן פונקציה משמעותי. עם זאת, הגישה למחוק קבצי הליבה של WordPress אינה בת קיימא. כי כאשר אתם מעדכנים WordPress, הקובץ עלול לחזור. בנוסף, חלק מתוספי האבטחה עשויים לספק התראות על קבצים חסרים בבדיקת שלמות קבצים.

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

טבלת החלטות: למחוק, לחסום, או להשאיר כמו שזה?

כפי שנראה בטבלה, האפשרות המאוזנת ביותר עבור רוב האתרים היא לחסום את הגישה לקובץ wp-links-opml.php במקום למחוק אותו. זה מפחית את הסיכון ומקל על התחזוקה.

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

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

1. קחו גיבוי מלא

השלב הראשון הוא לגבות את הקבצים והמאגר. לא מספיק להעתיק רק את הקובץ wp-links-opml.php. כי השינויים שאתם עושים עשויים להשפיע על אזורים שונים כמו .htaccess, קונפיגורציית Nginx, תוספי אבטחה או הרשאות קובץ. השתמשו במדיניות גיבוי אוטומטית אם אפשר, וגיבוי של האתר כולו. חשוב לשמור את הגיבויים במקום נפרד. אם יש לכם תכונת גיבוי יומי בלוח הבקרה שלכם, הקפידו לבדוק את זה באופן קבוע. בנושא זה אחסון אתרים ו-פתרונות גיבוי עשויים להיות מועילים.

2. בדקו אם הקובץ בשימוש

בדקו ביומני הגישה של השרת אם יש בקשות לקובץ wp-links-opml.php. אם ביומנים של 30 הימים האחרונים יש בקשות לקובץ זה רק מבוטים, ואין משתמשים אמיתיים או אינטגרציה נראית, חוסמים את הגישה עשוי להיות בטוח. אם כלי RSS מסוים, אינטגרציה מיוחדת או מערכת תוכן ישנה קוראים לקובץ הזה באופן קבוע, עליכם קודם כל להסיר את התלות הזו.

3. בדקו בסביבת staging

ביישומים מקצועיים לא מבצעים פעולות ישירות באתר החי. יש ליצור סביבת staging ולבדוק את אותו הכלל שם. בדקו את הדף הראשי, דפי המאמרים, לוח הבקרה, מפת האתר, זרם ה-RSS, טפסים ושלבי תשלום. קובץ wp-links-opml.php בדרך כלל לא משפיע על אזורים אלו; אך אם תכתבו את כלל האבטחה לא נכון, זה עלול לגרום לשגיאות 403 בלתי צפויות.

4. רשמו את התנהגות העדכון

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

כיצד נחסום את הגישה לקובץ wp-links-opml.php בצורה בטוחה?

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

אתרים שמשתמשים ב-Apache

באתרי WordPress שמשתמשים ב-Apache וב-.htaccess אפשר להוסיף כלל חסימה לקובץ wp-links-opml.php. ההיגיון פשוט: רק לבקשות HTTP חיצוניות לקובץ הזה לא יינתן אישור והשרת יחזיר תגובה של 403. לפני הוספת הכלל, גבו את הקובץ .htaccess הנוכחי שלכם. לאחר מכן הוסיפו את הכלל מחוץ לחסימות שה-WordPress יצר אוטומטית, רצוי עם הערת האבטחה שלכם. לאחר הפעולה, בדקו בדפדפן את הכתובת domain.com/wp-links-opml.php. התוצאה הצפויה היא חסימת גישה של 403 Forbidden או משהו דומה.

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

אתרים שמשתמשים ב-Nginx

בצד של Nginx, פעולה דומה מתבצעת בתוך בלוק השרת עם כלל מיקום ספציפי. בקשות לקובץ wp-links-opml.php יקבלו תגובה של 403. לאחר השינוי, יש לבצע בדיקת קונפיגורציה ב-Nginx ולחדש את השירות. אם אתם משתמשים בהוסטינג מנוהל, ייתכן שלא תהיה לכם גישה ישירה לאזור זה. במקרה כזה, תוכלו לבקש מהספק שלכם לחסום גישה לקובץ הרלוונטי.

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

חסימה באמצעות תוסף אבטחה או WAF

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

אם אתם באמת רוצים למחוק את הקובץ, מדריך בטוח

בכמה ארגונים, מדיניות האבטחה עשויה לדרוש הסרה פיזית של נקודות קצה ליבה שלא בשימוש. במקרה זה, פעלו בדרך מבוקרת למחיקת הקובץ wp-links-opml.php. קודם כל קחו גיבוי מלא, נסו בסביבה מנותקת, ולאחר מכן בחרו שעת תנועה נמוכה לחיות. רשמו את נתיב הקובץ והרשאותיו לפני המחיקה. לאחר המחיקה, בדקו את האתר עם לפחות 10 כתובות URL קריטיות שונות.

לאחר תהליך המחיקה, בצעו את הבדיקות הבאות:

• האם הדף הראשי ודפי פתיחה חשובים נותנים תגובת 200?
• האם ניתן להיכנס לפאנל הניהול?
• האם זרמי ה-RSS פועלים?
• האם תוסף האבטחה מייצר התראה על שלמות קבצים?
• האם ביומני השרת יש שגיאות PHP חדשות?
• האם הקובץ חוזר לאחר עדכון WordPress?

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

עדיפויות אבטחה גדולות יותר מאשר wp-links-opml.php

מיקוד בקובץ אחד עשוי להיות מועיל; אך אבטחת WordPress לא מתמקדת רק בקובץ אחד. בעולם האמיתי, חלק משמעותי מההתקפות מתבצע דרך סיסמאות חלשות, תוספים שאינם מעודכנים, תבניות לא חוקיות, הרשאות קובץ לא נכונות, והפרדת שרתים לא מספקת. מחיקת קובץ wp-links-opml.php עשויה להעניק תחושת אבטחה; אך אם הפגיעויות הבסיסיות ממשיכות להתקיים, הסיכון לא מצטמצם.

אל תדחו עדכונים

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

שמרו על הרשאות קובץ הדוקות

הגישה הכללית לגבי הרשאות קובץ היא 755 לתיקיות ו-644 לקבצים. קבצים רגישים כמו wp-config.php צריכים להיות מוגנים יותר. הרשאות 777, במיוחד בסביבות משותפות, מהוות סיכון חמור. גם אם תסגרו את הקובץ wp-links-opml.php, אם התיקיות ניתנות לכתיבה בצורה לא נכונה, תוקף עשוי להעלות קבצים זדוניים בדרכים אחרות.

חזקו את אבטחת הכניסה

יש ליישם סיסמאות חזקות, אימות דו-שלבי, הגבלת ניסיונות כניסה וניהול חשבונות מנהל מיותרים בחשבונות המנהל. יש לבצע הערכה נפרדת עבור נקודות קצה כמו wp-login.php ו-XML-RPC, אשר תוקפים נוטים להתמקד בהם. סגירת הגישה ל-XML-RPC שלא בשימוש עשויה לספק השפעת אבטחה גבוהה יותר מאשר הגבלת wp-links-opml.php ברוב האתרים.

אל תזניחו את HTTPS ואבטחת שם הדומיין

אתרים ללא תעודת SSL עשויים לסכן את פרטי הכניסה והטפסים. כל אתרי WordPress צריכים להיות מוגנים ב-HTTPS. בנוסף, יש לוודא שהדומיין לא פג תוקף, שניהול רשומות ה-DNS מתבצע כראוי, ושנשמר נעילת הדומיין. בנושאים אלו ניתן לבדוק את השירותים הקשורים דרך בדיקת דומיין, מעבר דומיין ו-תעודת SSL.

האם יש השפעה על הביצועים וה-SEO?

מחיקת או חסימת הקובץ wp-links-opml.php לא תשדרג ישירות את דירוגי ה-SEO שלכם. גוגל לא רואה את הקיום של הקובץ הזה כסיגנל איכותי. עם זאת, אתר מאובטח, מהיר, ללא שגיאות ומנוהל היטב עשוי לתרום באופן עקיף לביצועי SEO. הפחתת בקשות בוטים מיותרות עשויה לעזור בשימוש יעיל יותר במשאבי השרת. במיוחד בחבילות הוסטינג משותפות עם משאבים נמוכים, תנועת בוטים אינטנסיבית עשויה להגדיל את השימוש ב-CPU וב-I/O.

מבחינת SEO, הנושא החשוב הוא להבטיח שהחסימה לא תשפיע בטעות על דפים חשובים, זרם RSS, מפת האתר או מקורות ניהול. אם הכלל נכתב שגוי וגוגל לא מצליח לגשת לתוכן חשוב, זה עלול לגרום לבעיות אינדוקס. לכן, יש לעקוב אחרי דוחות הכיסוי ב-Google Search Console, יומני השרת וטעויות סריקה באופן סדיר.

תוכנית יישום מקצועית מומלצת

תוכנית יישום פרקטית ובטוחה עבור אתר WordPress שלכם עשויה להיות:

• 1. גיבוי של האתר הנוכחי והמאגר.
• 2. בדוק יומני גישה של 30 הימים האחרונים עבור בקשות לקובץ wp-links-opml.php.
• 3. ודא שאין תלות ב-Blogroll או OPML.
• 4. בדוק את כלל החסימה בסביבת staging.
• 5. בהצלחה, החל כלל של 403 רק עבור קובץ זה בסביבה החיה.
• 6. בדוק את הדף הראשי, לוח הבקרה, RSS, מפת האתר וטפסים.
• 7. עקוב אחרי תוספי האבטחה ויומני השרת במשך 7 ימים.
• 8. לאחר עדכוני WordPress, בדוק שוב שהכלל פועל.

תוכנית זו מתמקדת בגישה לשליטה על חסימת הקובץ wp-links-opml.php במקום למחוק אותו. כך נשמרת גם מבנה הליבה של WordPress וגם מופחתת הגישה החיצונית המיותרת. עבור אבטחה ברמה רחבה יותר, יש להתמודד עם שכבת ההוסטינג, גיבויים, SSL, WAF, מדיניות עדכונים וניהול סיסמאות יחד.

סיכום: חסימה מבוקרת עדיפה על מחיקה

מחיקת הקובץ wp-links-opml.php באתר WordPress שלכם לא תגרום לאובדן פונקציונלי ברוב האתרים המודרניים; אך בדרך כלל, הפרקטיקה הטובה ביותר היא לא למחוק את הקובץ אלא להגביל את הגישה בצורה בטוחה. הקובץ עצמו לא מהווה פגיעות קריטית, אך הפחתת נקודות קצה שאין להן שימוש היא הרגל אבטחה טוב. אם תתקדמו על ידי גיבוי, בדיקות staging, ניתוח יומנים והגדרות חוקים מצומצמות ברמת השרת, תוכלו לשפר את האבטחה ולהקטין את בעיות התחזוקה שיכולות להיגרם מעדכוני WordPress.

בקיצור: אם אתם לא משתמשים ב-Blogroll/OPML, חסמו את הגישה לקובץ wp-links-opml.php; אך עשו זאת לא בצורה של מחיקת קובץ לא מתוכננת, אלא כצעד אבטחה מבוקר ובר-שחזור. כדי לשמור על אתר WordPress שלכם בטוח, מהיר ומעודכן, חשוב לבחור תשתית הוסטינג נכונה, SSL וגיבויים סדירים באותה מידה כמו הקובץ הזה. כדי לבחון את פתרונות ההוסטינג המתאימים לכם, אתם יכולים לבדוק את אחסון WordPress ב-Hostragons.

שאלות נפוצות

האם הקובץ wp-links-opml.php הוא וירוס?

לא. wp-links-opml.php הוא קובץ ישן המופיע בליבת WordPress. הוא לא וירוס או קובץ מזיק בפני עצמו. אך אם הוא לא בשימוש, סגירת הגישה החיצונית עשויה להקטין את שטח ההתקפה.

אם אני מוחק את הקובץ wp-links-opml.php, האם האתר שלי יתמוטט?

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

האם עדכון WordPress מחזיר את הקובץ wp-links-opml.php?

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

האם חסימת הקובץ wp-links-opml.php משפיעה על ביצועי SEO?

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

האם חסימת הקובץ wp-links-opml.php מספיקה לאבטחת WordPress?

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