כיצד אנו משחזרים אתרי 1C-Bitrix מגיבויים

כיצד אנו משחזרים אתרי 1C-Bitrix מגיבויים

שיחה בערב שישי: "האתר מושבת, האחסון דיבר על משהו על שטח דיסק, האתר לא נפתח." דווקא ברגעים כאלה, אנחנו, מהנדסי Bitrix מוסמכים עם עשר שנות ניסיון ולמעלה מ-200 פרויקטים ששוחזרו, מבינים כמה קריטית היא מערכת גיבוי תקינה. אם קיים גיבוי, זה עניין של כמה שעות. אם לא או שהוא מיושן, זו קטסטרופה עם השלכות בלתי צפויות. זמן השחזור הממוצע כאשר קיים גיבוי הוא 3.5 שעות, עם 98% מהפרויקטים שהושלמו ללא אובדן נתונים. הצוות שלנו שחזר למעלה מ-200 אתרי 1C-Bitrix, ובכל מקרה, הגורם המרכזי היה איכות הגיבוי.

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

מה כולל גיבוי מלא

גיבוי מלא של אתר Bitrix מורכב משני חלקים עצמאיים:

• מערכת הקבצים — כל הפרויקט: ליבת Bitrix (/bitrix/), נתוני משתמשים (/upload/), תבניות (/local/templates/), רכיבים מותאמים אישית (/local/components/), קבצי תצורה (.env או /bitrix/.settings.php, /bitrix/php_interface/dbconn.php).
• מסד הנתונים — dump של MySQL/MariaDB. מכיל את כל התוכן, ההגדרות, המשתמשים, ההזמנות, ההיסטוריה. עבור אתרים גדולים, ה-dump יכול להיות כמה ג'יגה-בייט — טבלאות כמו b_stat_* (סטטיסטיקות) ו-b_event_log מהוות לעיתים קרובות את רוב הנפח.

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

באיזה מנגנון גיבוי לבחור?

קיימות שלוש גישות עיקריות, ואנו ממליצים לשלב ביניהן. הארכיבר המובנה (/bitrix/admin/backup.php) יוצר ארכיון של מערכת הקבצים ו-dump של מסד הנתונים בתיקיית /bitrix/backup/. זה נוח אבל איטי באתרים גדולים (מעל 10 GB) ודורש שטח פנוי על אותו דיסק. לשחזור, השתמשו ב-restore.php. גיבוי בצד השרת — תמונות מצב של מכונה וירטואלית, משימות cron עם mysqldump + tar. זה אמין יותר מהמנגנון המובנה, בלתי תלוי ב-Bitrix, ומאפשר שחזור מחוץ למערכת. זו השיטה שבה אנו משתמשים עבור הלקוחות שלנו: גיבוי מלא יומי עם אחסון ב-Yandex Object Storage. ניתן לקרוא עוד על mysqldump בויקיפדיה. להלן השוואה:

שחזור אתר באמצעות restore.php

תהליך השחזור באמצעות restore.php: הורידו את קובץ restore.php מאתר 1C-Bitrix התואם לגרסה שלכם והניחו אותו בשורש האתר. העלו את ארכיון הגיבוי (.tar.gz) אל bitrix/backup/ או ציינו את הנתיב בממשק restore.php. לאחר מכן הריצו את אשף החילוץ: שחזור קבצים, שחזור מסד נתונים, בדיקת תקינות. בעת שחזור לשרת אחר, הזינו פרטי חיבור חדשים ל-MySQL. לאחר השחזור, בדקו את /bitrix/.settings.php — ייתכן שיידרשו התאמות לסביבה החדשה. מגבלה: ארכיונים גדולים (10+ GB) לא ניתנים לשחזור דרך הדפדפן — התהליך ייפסק עקב מגבלת זמן PHP. במקרים כאלה, אנו משתמשים בשורת הפקודה.

שחזור באמצעות שורת הפקודה (CLI)

לתקריות חמורות, אנו משתמשים רק ב-CLI. אלגוריתם השחזור המלא על שרת חדש מורכב מכמה שלבים. ראשית, הכינו את הסביבה: התקינו BitrixEnv או הגדירו nginx + php-fpm + MySQL ידנית עם פרמטרים התואמים לשרת המקורי. גרסת PHP חייבת להתאים — אפילו פער בגרסה משנית עלול לגרום לשגיאות קריטיות. לאחר מכן פרסו את הקבצים:

cd /home/bitrix/www tar -xzf /path/to/files_backup.tar.gz --strip-components=N chown -R bitrix:bitrix /home/bitrix/www 

לאחר מכן שחזרו את מסד הנתונים:

mysql -u bitrix -p sitedb < /path/to/db_backup.sql
# или для gzip-архива:
gunzip -c /path/to/db_backup.sql.gz | mysql -u bitrix -p sitedb

עבור מסדי נתונים גדולים (מעל 1 GB), הוסיפו פרמטרי האצה:

mysql -u bitrix -p --init-command="SET SESSION foreign_key_checks=0; SET SESSION unique_checks=0;" sitedb < db_backup.sql 

לאחר מכן, הגדירו את חיבור מסד הנתונים: בדקו את cd /home/bitrix/www tar -xzf /path/to/files_backup.tar.gz --strip-components=N chown -R bitrix:bitrix /home/bitrix/www ו-mysql -u bitrix -p sitedb < /path/to/db_backup.sql # или для gzip-архива: gunzip -c /path/to/db_backup.sql.gz | mysql -u bitrix -p sitedb — פרמטרי החיבור חייבים להתאים לסביבה החדשה. הקפידו לנקות את המטמון:

rm -rf /home/bitrix/www/bitrix/cache/*
rm -rf /home/bitrix/www/bitrix/managed_cache/*
rm -rf /home/bitrix/www/bitrix/stack_cache/*

ואימתו הרשאות: תיקיית mysql -u bitrix -p --init-command="SET SESSION foreign_key_checks=0; SET SESSION unique_checks=0;" sitedb < db_backup.sql חייבת להיות ניתנת לכתיבה על ידי שרת האינטרנט (מטמון, קבצים זמניים), /bitrix/php_interface/dbconn.php גם כן ניתנת לכתיבה.

כיצד לקבוע את תאריך הפריצה כדי לבחור את הארכיון הנכון

אם האתר נפרץ, שחזור מגיבוי אינו רק החזרה לאחור. צריך לקבוע את תאריך הפריצה (יומני nginx, /bitrix/.settings.php, חותמות זמן של קבצים ששונו באמצעות rm -rf /home/bitrix/www/bitrix/cache/* rm -rf /home/bitrix/www/bitrix/managed_cache/* rm -rf /home/bitrix/www/bitrix/stack_cache/* ). בחרו ארכיון שנוצר לפני תאריך זה. שחזרו ובדקו אם קיימות דלתות אחוריות — אפילו ארכיון "נקי" עשוי להכיל קוד זדוני אם הפריצה התרחשה לפני יצירת הארכיון. תקנו את הפרצה: עדכנו את Bitrix, סגרו את וקטור התקיפה (לעיתים קרובות תוסף מיושן, סיסמת FTP/SSH חלשה, סקריפט PHP פגיע).

אחד הלקוחות שלנו — חנות בגדים מקוונת — התמודד עם הדבקה מסיבית של קבצי PHP. גוגל החלה להציג אזהרה "אתר זה עלול להיות מסוכן," חברת האחסון השביתה את האתר. סרקנו את הפרויקט עם כלי ה-AI-Bolit — נמצאו 847 קבצים ששונו. קבענו שההדבקה התרחשה לפני 5 ימים, כך שהעותק "מאתמול" היה גם הוא נגוע. השתמשנו בעותק קבצים מלפני שבועיים ובמסד נתונים טרי (נתוני הזמנות). האתר שוחזר תוך 1.5 ימים עם אבטחה משופרת. אובדן נתונים: רק תוכן משבועיים היה צריך לשחזר ידנית, ההזמנות נשמרו. מקרה זה מראה שגם עם פריצה חמורה, שחזור אתר 1C-Bitrix מגיבוי אפשרי עם הפסדים מינימליים.

מה לעשות אם הגיבוי מיושן

לפעמים הגיבוי האחרון הוא מלפני שבוע, אבל רק נתונים מהימים האחרונים אבדו. במקרים כאלה, אנו מיישמים שחזור גרעיני: פורסים את הארכיון בסביבת בדיקה, מייצאים אלמנטים נדרשים (בלוקי מידע, עמודים, הזמנות) מהעותק הבדיקתי, ומעבירים אותם לסביבת הייצור באמצעות API או לוח הניהול. זה מונע אובדן נתונים טריים. לדוגמה, במקרה של שגיאת עדכון מודול (מסך לבן), אנו מחזירים רק את קבצי המודול מהגיבוי מבלי לגעת במסד הנתונים. השחזור אורך 15–30 דקות.

טעויות שחזור נפוצות וכיצד להימנע מהן

אחת הטעויות הנפוצות ביותר היא התעלמות מגרסאות PHP ו-MySQL. אם לשרת החדש יש גרסה ראשית שונה, עלולות להתרחש שגיאות קריטיות. אנו בודקים את פרמטרי /bitrix/ על השרת המקורי לפני הקריסה. הטעות השנייה היא שחזור לאותו שרת ללא ניקוי המטמון. קבצי מטמון ישנים עלולים להתנגש עם מסד הנתונים המעודכן — תמיד מחקו את /upload/. השלישית היא חוסר סנכרון בין קבצים למסד נתונים. אם משתמשים בעותקים מתאריכים שונים, ודאו שגרסת Bitrix בקבצים וב-DB תואמת. ולבסוף, שחזור ללא בדיקת הרשאות: גם לאחר שחזור מוצלח, העלאת תמונות או מטמון עלולים לא לעבוד — הגדירו בעלות של access_log.

מסגרות זמן לשחזור: מה משפיע

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