גיבוי ושחזור GitLab: S3, HA, אוטומציה

GitLab Backup ושחזור: S3, HA, אוטומציה

לפני שישה חודשים, לקוח איבד גישה לפרויקט שלו לאחר כשל במערך RAID. GitLab ביצע גיבויים יומיים, אך במהלך השחזור התברר ש-/etc/gitlab/gitlab-secrets.json לא נשמר בנפרד. כתוצאה מכך, כל משתני CI/CD, אסימוני webhook וסודות 2FA הפכו לבלתי נגישים. השחזור ארך יומיים במקום השעה המתוכננת. שילבנו מערכת גיבוי מלאה המכסה את מסד הנתונים, קבצי התצורה ואחסון האובייקטים. כשליש מתקריות השחזור של GitLab קשורות ל-gitlab-backup create חסר — זמן ההשבתה הממוצע הוא 8 שעות. המתודולוגיה שלנו מפחיתה את ה-MTTR ל-15 דקות, פי שמונה מהר יותר מהגישה הסטנדרטית. הנה כיצד להגדיר גיבוי ושחזור של GitLab ללא הפתעות ועם ערבויות.

אילו רכיבי GitLab הכלי המובנה אינו מגבה?

משימת ה-rake המובנית /etc/gitlab/gitlab.rb היא נקודת התחלה טובה, אך היא לא מכסה הכל. האחריות שלה כוללת:

• PostgreSQL (dump מלא באמצעות pg_dump)
• מאגרי Git (באמצעות Gitaly)
• קבצים שהועלו (avatars, קבצים מצורפים, אובייקטי LFS כאשר הם מאוחסנים מקומית)
• ארטיפקטים של CI/CD (אם מאוחסנים מקומית)
• Container Registry (אם מקומי)
• מפתחות הצפנה (באמצעות מנגנון נפרד, אך לא secrets.json)

אבל הוא לא מגבה אוטומטית:

• /etc/gitlab/gitlab-secrets.json ו-gitlab-secrets.json — קריטי
• אישורי TLS
• nginx מותאם אישית
• נתוני Consul/Patroni בהתקנות HA

gitlab-secrets.json מכיל מפתחות להצפנת סודות 2FA, אסימוני webhook ומשתני CI/CD. אם מסד הנתונים משוחזר ללא # /etc/gitlab/gitlab.rb gitlab_rails['backup_path'] = '/mnt/backups/gitlab' gitlab_rails['backup_keep_time'] = 604800 gitlab_rails['backup_upload_connection'] = { 'provider' => 'AWS', 'region' => 'eu-central-1', 'aws_access_key_id' => 'AKIA...', 'aws_secret_access_key' => 'secret' } gitlab_rails['backup_upload_remote_directory'] = 'gitlab-backups-prod' gitlab_rails['backup_archive_permissions'] = 0644 המתאים, כל הנתונים המוצפנים הופכים לבלתי נגישים: משתמשים מאבדים 2FA, אינטגרציות מפסיקות לעבוד. זו טעות אופיינית שמובילה לאובדן נתונים חלקי ב-30% מהפרויקטים.

כיצד להגדיר גיבוי להתקנות Omnibus?

ההגדרה מתחילה בקובץ התצורה. דוגמה עבור Omnibus:

# /etc/gitlab/gitlab.rb
gitlab_rails['backup_path'] = '/mnt/backups/gitlab'
gitlab_rails['backup_keep_time'] = 604800
gitlab_rails['backup_upload_connection'] = {
  'provider' => 'AWS',
  'region' => 'eu-central-1',
  'aws_access_key_id' => 'AKIA...',
  'aws_secret_access_key' => 'secret'
}
gitlab_rails['backup_upload_remote_directory'] = 'gitlab-backups-prod'
gitlab_rails['backup_archive_permissions'] = 0644

לאחר עדכון התצורה:

gitlab-ctl reconfigure gitlab-backup create STRATEGY=copy 

gitlab-ctl reconfigure gitlab-backup create STRATEGY=copy יוצר עותקים של קבצים במקום להעביר אותם. זה חשוב עבור מאגרים שממשיכים לקבל push במהלך הגיבוי. ללא אפשרות זו, נתונים שנכתבים באופן פעיל עלולים להיתפס חלקית.

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

1. הגדר את STRATEGY=copy כפי שצוין לעיל.
2. הרץ את gitlab.rb.
3. הרץ את gitlab-ctl reconfigure.
4. ודא את הארכיון ב-S3 או בספרייה מקומית.
5. הגדר cron או systemd timer לאוטומציה.

למה לגבות תצורה בנפרד?

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

#!/bin/bash
CONF_BACKUP=/mnt/backups/gitlab-config/$(date +%Y%m%d)
mkdir -p "$CONF_BACKUP"
cp /etc/gitlab/gitlab.rb "$CONF_BACKUP/"
cp /etc/gitlab/gitlab-secrets.json "$CONF_BACKUP/"
tar czf - "$CONF_BACKUP" | gpg --symmetric --cipher-algo AES256 -o "$CONF_BACKUP.tar.gz.gpg"
aws s3 cp "$CONF_BACKUP.tar.gz.gpg" s3://gitlab-config-backups/
rm -rf "$CONF_BACKUP" "$CONF_BACKUP.tar.gz.gpg"

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

כיצד לשחזר מגיבוי?

השחזור אפשרי רק לגרסת GitLab זהה. גם גרסאות major וגם minor חייבות להתאים. הנוהל:

# Останавливаем процессы, которые пишут в БД
gitlab-ctl stop puma
gitlab-ctl stop sidekiq
# Убеждаемся, что БД доступна
gitlab-ctl start postgresql
gitlab-ctl start gitaly
# Восстановление (имя файла без _gitlab_backup.tar)
gitlab-backup restore BACKUP=20250325_17.8.1

לאחר השחזור, העתק את secrets.json והרץ את gitlab-backup create STRATEGY=copy. לאחר מכן הרץ אימות:

gitlab-ctl start gitlab-rake gitlab:check SANITIZE=true 

#!/bin/bash CONF_BACKUP=/mnt/backups/gitlab-config/$(date +%Y%m%d) mkdir -p "$CONF_BACKUP" cp /etc/gitlab/gitlab.rb "$CONF_BACKUP/" cp /etc/gitlab/gitlab-secrets.json "$CONF_BACKUP/" tar czf - "$CONF_BACKUP" | gpg --symmetric --cipher-algo AES256 -o "$CONF_BACKUP.tar.gz.gpg" aws s3 cp "$CONF_BACKUP.tar.gz.gpg" s3://gitlab-config-backups/ rm -rf "$CONF_BACKUP" "$CONF_BACKUP.tar.gz.gpg" יראה אם משהו שוחזר בצורה שגויה: הרשאות קבצים שגויות, בעיות חיבור ל-Redis או PostgreSQL.

שגיאות אופייניות והפתרונות שלהן

אי-התאמת גרסאות היא השגיאה הנפוצה ביותר. שחזור מסד הנתונים לגרסה שונה גורם ל-# Останавливаем процессы, которые пишут в БД gitlab-ctl stop puma gitlab-ctl stop sidekiq # Убеждаемся, что БД доступна gitlab-ctl start postgresql gitlab-ctl start gitaly # Восстановление (имя файла без _gitlab_backup.tar) gitlab-backup restore BACKUP=20250325_17.8.1 . פתרון: התקן תחילה את גרסת הגיבוי, שחזר, ולאחר מכן שדרג. השנייה הנפוצה ביותר היא חוסר בשטח דיסק. הגיבוי יוצר ארכיון מקומי, כך ש-gitlab-ctl reconfigure זקוק לנפח נפרד. שלישית: אובייקטי LFS המאוחסנים ב-S3 חיצוני לא ייכללו בגיבוי — יש להעתיק אותם בנפרד באמצעות rclone או gitlab-ctl start gitlab-rake gitlab:check SANITIZE=true . והכי חשוב: אובדן gitlab:check הופך את השחזור לבלתי שלם — כל הנתונים המוצפנים הופכים לבלתי זמינים.

מה כלול בהקמת גיבוי סוהר?

אנו מספקים את המחזור המלא:

• ביקורת של תשתית GitLab הנוכחית
• הגדרת גיבוי (DB, מאגרים, תצורה, S3)
• הצפנת secrets.json והגדרת GPG
• אוטומציה באמצעות systemd timer או cron
• אינטגרציה עם GitLab CI/CD לבדיקת שחזור
• תיעוד runbook והדרכת צוות

לוחות זמנים משוערים:

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