הקמת התאוששות מאסון עבור 1C-Bitrix

הגדרת שחזור מאסון עבור 1C-Bitrix

השרת קרס ב-2:30 לפנות בוקר. גיבוי מסד הנתונים האחרון בוצע ב-23:00. האתר מושבת, מנהלים לא יכולים לראות הזמנות, לקוחות עוזבים למתחרים. תוכנית השחזור קיימת רק בראש של המנהל — הסקריפטים לא עודכנו כבר שנה, ושכפול מסד הנתונים אפילו לא מוגדר. תרחיש טיפוסי בפרויקטים שבהם DR מתואר בחוזה אך אף פעם לא נבדק. זמן השבתה לאתר מסחר אלקטרוני יכול לעלות בין 10,000 ל-$900–1.3k לשעה; השבתה של יום שלם עלולה לגרום להפסדים העולים על $18k–26k. השקעה בהגדרת DR נכונה (בדרך כלל $1k–3k) יכולה לחסוך מיליונים בהפסדים פוטנציאליים. אנחנו צוות מהנדסים עם 10 שנות ניסיון בשחזור פרויקטים של Bitrix — ראינו עשרות כשלונות כאלה. מאמר זה מסביר כיצד לבנות DR שבאמת עובד, לא רק אוסף אבק בתיעוד.

לפי התיעוד הרשמי של 1C-Bitrix, הגדרת גיבוי היא חובה עבור פרויקטים בייצור.

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

בניית DR אמין מתחילה בבדיקת התשתית הנוכחית ובחירת האסטרטגיה הנכונה. להלן נפרק את הרכיבים שדורשים הגנה ואת הכלים לשימוש.

רכיבים שדורשים שחזור

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

• קוד יישום — /var/www/bitrix/ (ליבה) ו-/local/ (התאמות אישיות). הקוד מאוחסן ב-git — זה צריך להיות הסטנדרט, לא היוצא מן הכלל.
• מסד נתונים — PostgreSQL או MySQL. עבור Bitrix עם עומס — סכמת ראשי/משני, תמונות מצב מהמשני.
• קבצים שהועלו — /upload/, /bitrix/backup/. הנפח גדל ברציפות, ולעתים קרובות מתעלמים ממנו בעת הגדרת גיבויים.
• קבצי תצורה — /bitrix/.settings.php, /bitrix/php_interface/dbconn.php, תצורות nginx/php-fpm.

מנגנון גיבוי מובנה

ל-Bitrix יש כלי גיבוי מובנה (/bitrix/admin/backup.php). הוא יוצר ארכיונים ב-/bitrix/backup/ דרך הסוכן CBackupAgent. הפרמטרים מאוחסנים ב-b_option, מודול main:

• backup_auto — הפעלת גיבוי אוטומטי
• backup_period — מרווח בשעות
• backup_keep_count — מספר העותקים השמורים

הגיבוי המובנה עובד אבל יש לו מגבלות: בפרויקטים גדולים (מסד נתונים > 5 GB, /upload/ > 20 GB) הוא נתקע, תופס הרבה מקום על אותו שרת, ואינו מספק שכפול מחוץ לאתר ישירות מהקופסה.

מגבלות הגיבוי המובנה לפרויקטים גדולים

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

אסטרטגיה: שלוש שכבות הגנה

שכבה 1 — שכפול מסד נתונים בזמן אמת. PostgreSQL streaming replication או MySQL GTID replication. המשני מקבל WAL/binlog ונמצא בפיגור של שניות. במקרה של כשל ראשי — מעבר ידני או אוטומטי למשני. תצורה ב-postgresql.conf:

wal_level = replica max_wal_senders = 3 wal_keep_size = 1GB 

שכבה 2 — תמונות מצב שעתיות של מסד הנתונים. wal_level = replica max_wal_senders = 3 wal_keep_size = 1GB או pg_dump דרך cron, פלט לאחסון חיצוני (S3, rsync לשרת מחוץ לאתר). עבור PostgreSQL, xtrabackup מועדף לגיבוי פיזי — השחזור מהיר פי 5 משימוש ב-pg_basebackup.

שכבה 3 — גיבויי קבצים. /upload/ גדל לינארית; גיבוי מלא כל יום אינו יעיל. rsync או Restic אינקרמנטלי:

restic -r s3:s3.amazonaws.com/bucket/upload \ backup /var/www/site/upload \ --exclude /var/www/site/upload/resize_cache 

restic -r s3:s3.amazonaws.com/bucket/upload \ backup /var/www/site/upload \ --exclude /var/www/site/upload/resize_cache אינו נכלל — הוא נוצר מחדש אוטומטית כאשר ניגשים לתמונות.

RTO ו-RPO מובטחים

עבור אתר מסחר אלקטרוני טיפוסי עם מסד נתונים עד 10 GB ועד 10,000 מבקרים ייחודיים ביום, אנו מבטיחים: RPO של לא יותר מדקה עם שכפול, RTO של לא יותר מ-30 דקות. זה מושג באמצעות סקריפט שחזור אוטומטי ובדיקות סדירות. אם הפרויקט שלך גדול יותר — אנו מחשבים באופן אישי.

בדיקת DR — שלב חובה

DR ללא בדיקות סדירות הוא ביטחון כוזב. פעם ברבעון, בצע את הצעדים הבאים:

1. ודא תקינות גיבוי מסד הנתונים באמצעות resize_cache.
2. שחזר את מסד הנתונים והקבצים בסביבה מבודדת.
3. בדוק את פונקציונליות האתר: בצע הזמנה, היכנס לפאנל הניהול, ודא טעינת קבצים.
4. מדוד את זמן השחזור בפועל והשווה ל-RTO היעד.

תעד את זמן השחזור בפועל. אם הוא חורג מה-RTO המוצהר — בצע אופטימיזציה של ההליך.

מה כלול בהגדרת DR

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

בהשוואת גיבוי מובנה עם כלים חיצוניים, האחרונים מספקים RPO נמוך בהרבה: שכפול streaming מציע שניות, בעוד שגיבוי מובנה יכול להגיע עד 24 שעות — הבדל של למעלה מ-86,000 פעמים. עבור פרויקטים גדולים, זה קריטי.

מה אנו מגדירים

• שכפול streaming של PostgreSQL/MySQL עם ניטור פיגור של המשני
• # Проверка целостности дампа БД pg_restore --list /backup/site.dump | tail -20 # Проверка, что сайт поднимается из бекапа # Тест: оформить заказ, зайти в административную часть או pg_dump שעתיים לאחסון חיצוני
• גיבוי אינקרמנטלי של pg_basebackup באמצעות Restic או rsync עם /upload/ שאינו נכלל
• סקריפט שחזור עם תהליך עבודה מתועד
• נהלי בדיקה רבעוניים עם מדידת RTO אמיתית
• התראות על כשלי גיבוי (קובץ חסר בשעות האחרונות)

תוצרים

במסגרת הגדרת DR, אתה מקבל:

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

הניסיון שלנו — 10+ שנים ב-Bitrix, למעלה מ-50 פרויקטים משוחזרים עם אחוז הצלחה של 99.9%. אנו מבטיחים שאחרי הגדרת שחזור מאסון, האתר שלך יהיה פעיל בתוך הזמן המוסכם. צור קשר לבדיקת סכמת הגיבוי הנוכחית שלך — אנו נעריך את הפרויקט ונציע פתרון אופטימלי. קבל ייעוץ על הגדרת שחזור מאסון עבור פרויקט 1C-Bitrix שלך. חיסכון מ-DR מוגדר כראוי יכול להסתכם בכ-$9k–13k במקרה של כשל.