גיבוי VDS מצטבר עם אתר ב-1C-Bitrix ב-Yandex.Cloud

היה לי צורך לגבות את האתר ל-2C-Bitrix: ניהול אתרים 1 פעמים ביום (קבצים ומסד נתונים של mysql) ולאחסן היסטוריית שינויים למשך 90 יום.

האתר ממוקם על VDS המריץ CentOS 7 עם "1C-Bitrix: Web Environment" מותקן. בנוסף, צור עותק גיבוי של הגדרות מערכת ההפעלה.

דרישות:

• תדירות - 2 פעמים ביום;
• שמור עותקים עבור 90 הימים האחרונים;
• היכולת לקבל קבצים בודדים לתאריך מסוים, במידת הצורך;
• הגיבוי חייב להיות מאוחסן במרכז נתונים שאינו VDS;
• היכולת לגשת לגיבוי מכל מקום (שרת אחר, מחשב מקומי וכו').

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

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

נתונים ראשוניים:

• VDS על וירטואליזציה של XEN;
• OS CentOS 7;
• 1C-Bitrix: סביבת אינטרנט;
• אתר מבוסס על "1C-Bitrix: ניהול אתר", גרסה סטנדרטית;
• גודל הקובץ הוא 50 GB והוא יגדל;
• גודל מסד הנתונים הוא 3 GB והוא יגדל.

גיבוי סטנדרטי מובנה ב-1C-Bitrix - לא נכלל באופן מיידי. זה מתאים רק לאתרים קטנים, כי:

• עושה עותק שלם של האתר בכל פעם, בהתאמה, כל עותק יתפוס מקום כמו שאני תופס את הקבצים, במקרה שלי זה 50 GB.
• הגיבוי נעשה באמצעות PHP, דבר בלתי אפשרי עם נפחים כאלה של קבצים, זה יעמיס על השרת ולא ייגמר לעולם.
• וכמובן, אי אפשר לדבר על 90 ימים כלשהם בעת אחסון עותק מלא.

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

מכל האמור לעיל, הבחירה הטובה ביותר עבורי היא גיבוי מצטבר לפי התרחיש שלי ב-Yandex.Cloud (Object Storage) או Amazon S3 (Amazon Simple Storage Service).

זה דורש:

• גישת שורש ל-VDS;
• מותקן שירות כפילות;
• חשבון ב-Yandex.Cloud.

גיבוי מצטבר - שיטה שבה מאוחסנים בארכיון רק נתונים שהשתנו מאז הגיבוי האחרון.

כפילות - כלי גיבוי המשתמש באלגוריתמים של rsync ויכול לעבוד עם Amazon S3.

Yandex.Cloud מול Amazon S3

אין הבדל בין Yandex.Cloud לאמזון S3 במקרה הזה עבורי. Yandex תומך בחלק העיקרי של ה-API של Amazon S3, כך שתוכל לעבוד איתו באמצעות הפתרונות הזמינים לעבודה עם S3. במקרה שלי, זה כלי השירות הכפול.

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

הגדרת Yandex.Cloud

1. עליך ליצור חשבון חיוב ב-Yandex.Cloud. כדי לעשות זאת, עליך להתחבר ל-Yandex.Cloud דרך חשבון Yandex שלך או ליצור חשבון חדש.

2. צור ענן.


3. ב"ענן" צור "קטלוג".


4. עבור "קטלוג" צור "חשבון שירות".


5. עבור "חשבון שירות" צור מפתחות.


6. שמור את המפתחות, תצטרך אותם בעתיד.


7. עבור "קטלוג" צור "דלי", קבצים ייפלו לתוכו.


8. אני ממליץ להגדיר מגבלה ולבחור ב"אחסון קר".

הגדרת גיבויים מתוזמנים בשרת

מדריך זה מניח כישורי ניהול בסיסיים.

1. התקן את תוכנית השירות הכפילות ב-VDS

yum install duplicity

2. צור תיקייה ל-mysql dumps, במקרה שלי זה /backup_db בשורש VDS

3. צור תיקייה ל-bash scripts /backup_scripts וצור את הסקריפט הראשון שיגבה את /backup_scripts/backup.sh

תוכן התסריט:

#!`which bash`


# /backup_scripts/backup.sh

# Это условие проверяет не идёт ли в данный момент процесс резервного копирования, если идёт, то на email отправляется сообщение об ошибке (этот блок можно не использовать)
if [ -f /home/backup_check.mark ];
then

DATE_TIME=`date +"%d.%m.%Y %T"`;

/usr/sbin/sendmail -t <<EOF
From:backup@$HOSTNAME
To:<Ваш EMAIL>
Subject:Error backup to YANDEX.CLOUD
Content-Type:text/plain; charset=utf-8
Error backup to YANDEX.CLOUD

$DATE_TIME
EOF

else

# Основной блок отвечающий за резервное копирование
# Если нет ощибки ставим метку и запускаем backup

echo '' > /home/backup_check.mark;


# Удаляем файлы с дампами базы оставшиеся от предыдущего backup

/bin/rm -f /backup_db/*


# Делаем дамп всех mysql баз, предполагается что доступ добавлен в файле /root/.my.cnf

DATETIME=`date +%Y-%m-%d_%H-%M-%S`;

`which mysqldump` --quote-names --all-databases | `which gzip` > /backup_db/DB_$DATETIME.sql.gz


# Добавляем данные для отправки в Яндекс.

export PASSPHRASE=<Придумайте пароль для шифрования архива>
export AWS_ACCESS_KEY_ID=<Идентификатор ключа полученный у Яндекса>
export AWS_SECRET_ACCESS_KEY=<Секретный ключ полученный у Яндекса>


# Запускаем duplicity для резервирования необходимых папок на сервере.
# Данная команда будет создавать полный backup раз в месяц и до следующего месяца добавлять инкрементальные к нему
# -- exclude это папки, которые нужно исключить, я исключаю все папки с кешем битрикса
# --include папки которые нужно резервировать в моём случае это:
# - /backup_db
# - /home
# - /etc
# s3://storage.yandexcloud.net/backup , backup это имя созданного выше бакета

# Техническая особенность и значения некоторых параметров:
# Две строки "--exclude='**'" и "/" нужны, чтобы можно было выше оперировать --include и --exclude для разных папок. Эти две строчки сначала добавляют в бэкап весь сервер "/", потом исключают его "--exclude='**'"
# --full-if-older-than='1M' - создавать полную копию каждый месяц
# --volsize='512' - максимальный размер каждого из файлов в бэкапе в мегабайтах
# --log-file='/var/log/duplicity.log' - куда писать лог файл

`which duplicity` 
    --s3-use-ia --s3-european-buckets 
    --s3-use-new-style 
    --s3-use-multiprocessing 
    --s3-multipart-chunk-size='128' 
    --volsize='512' 
    --no-print-statistics 
    --verbosity=0 
    --full-if-older-than='1M' 
    --log-file='/var/log/duplicity.log' 
    --exclude='**/www/bitrix/backup/**' 
    --exclude='**/www/bitrix/cache/**' 
    --exclude='**/www/bitrix/cache_image/**' 
    --exclude='**/www/bitrix/managed_cache/**' 
    --exclude='**/www/bitrix/managed_flags/**' 
    --exclude='**/www/bitrix/stack_cache/**' 
    --exclude='**/www/bitrix/html_pages/*/**' 
    --exclude='**/www/bitrix/tmp/**' 
    --exclude='**/www/upload/tmp/**' 
    --exclude='**/www/upload/resize_cache/**' 
    --include='/backup_db' 
    --include='/home' 
    --include='/etc' 
    --exclude='**' 
    / 
    s3://storage.yandexcloud.net/backup



# Данная команда нужна для чистки.
# Она оставляет 3 последних полных backup и ассоциированных с ними инкрементальных backup.
# Т.о. у меня остаются backup за 3 месяца, т.к. первая команда каждый месяц делает новый полный backup

`which duplicity` remove-all-but-n-full 3 --s3-use-ia --s3-european-buckets --s3-use-new-style --verbosity=0 --force s3://storage.yandexcloud.net/backup



unset PASSPHRASE
unset AWS_ACCESS_KEY_ID
unset AWS_SECRET_ACCESS_KEY

# Удаляем метку об идущем backup

/bin/rm -f /home/backup_check.mark;

fi

4. הפעל את הסקריפט בפעם הראשונה ובדוק את התוצאה, הקבצים אמורים להופיע ב-Bucket.

`which bash` /backup_scripts/backup.sh

5. הוסף סקריפט ל-cron עבור משתמש השורש שיבוצע 2 פעמים ביום, או בתדירות שתצטרך.

10 4,16 * * * `which bash` /backup_scripts/backup.sh

שחזור נתונים מ-Yandex.Cloud

1. צור תיקיית שחזור /backup_restore

2. הפוך את ה-bash restore script /backup_scripts/restore.sh

אני נותן את הדוגמה המבוקשת ביותר לשחזור קובץ ספציפי:

#!`which bash`

export PASSPHRASE=<Пароль для шифрования архива используемый при бэкапе>
export AWS_ACCESS_KEY_ID=<Идентификатор ключа полученный у Яндекса>
export AWS_SECRET_ACCESS_KEY=<Секретный ключ полученный у Яндекса>

# 3 примера, раскомментировать нужный

# Получить статус backup
#`which duplicity` collection-status s3://storage.yandexcloud.net/backup

# Восстановить index.php из корня сайта
#`which duplicity` --file-to-restore='home/bitrix/www/index.php' s3://storage.yandexcloud.net/backup /backup_restore/index.php

# Восстановить index.php из корня сайта 3х дневной давности
#`which duplicity` --time='3D' --file-to-restore='home/bitrix/www/index.php' s3://storage.yandexcloud.net/backup /backup_restore/index.php

unset PASSPHRASE
unset AWS_ACCESS_KEY_ID
unset AWS_SECRET_ACCESS_KEY

3. הפעל את הסקריפט והמתן לתוצאה.

`which bash` /backup_scripts/backup.sh

בתיקייה /backup_restore/ תמצאו את הקובץ index.php שנכלל בעבר בגיבוי.

אתה יכול לבצע התאמות עדינות יותר כדי להתאים לצרכים שלך.

מינוס כפילות

לכפילות יש חיסרון אחד - אין דרך להגדיר מגבלת שימוש בערוץ. בערוץ רגיל זה לא יוצר בעיה, אבל בערוץ מוגן DDoS עם חיוב מהירות ליום הייתי רוצה להגדיר מגבלה של 1-2 מגה ביט.

כמסקנה

גיבוי ב-Yandex.Cloud או ב-Amazon S3 מספק עותק עצמאי של הגדרות האתר ומערכת ההפעלה שניתן לגשת אליה מכל שרת אחר או מחשב מקומי. יחד עם זאת, עותק זה אינו גלוי לא בלוח הבקרה של האירוח או בפאנל הניהול של Bitrix, מה שמספק אבטחה נוספת.

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

אתה יכול להשתמש בטכניקה זו עם כל VDS או שרת ואתרים ייעודיים בכל מנועים, לא רק 1C-Bitrix. מערכת ההפעלה יכולה להיות גם אחרת מאשר CentOS, כגון אובונטו או דביאן.

מקור: www.habr.com