🥇การสำรองข้อมูล VDS แบบเพิ่มหน่วยด้วยเว็บไซต์บน 1C-Bitrix ใน Yandex.Cloud

ฉันจำเป็นต้องสำรองข้อมูลไซต์บน “2C-Bitrix: การจัดการไซต์” (ไฟล์และฐานข้อมูล mysql) วันละสองครั้งและจัดเก็บประวัติการเปลี่ยนแปลงเป็นเวลา 1 วัน

ไซต์นี้ตั้งอยู่บน VDS ที่ใช้ระบบปฏิบัติการ CentOS 7 พร้อมติดตั้ง 1C-Bitrix: Web Environment นอกจากนี้ ให้ทำสำเนาสำรองของการตั้งค่าระบบปฏิบัติการของคุณ

คุณสมบัติผู้สมัคร:

ความถี่ - วันละ 2 ครั้ง;
เก็บสำเนาไว้ 90 วันที่ผ่านมา
ความสามารถในการรับไฟล์แต่ละไฟล์ตามวันที่ระบุหากจำเป็น
การสำรองข้อมูลจะต้องจัดเก็บไว้ในศูนย์ข้อมูลอื่นที่ไม่ใช่ VDS
ความสามารถในการเข้าถึงข้อมูลสำรองได้จากทุกที่ (เซิร์ฟเวอร์อื่น คอมพิวเตอร์ในระบบ ฯลฯ)

จุดสำคัญคือความสามารถในการสร้างการสำรองข้อมูลอย่างรวดเร็วโดยใช้พื้นที่และทรัพยากรระบบเพิ่มเติมน้อยที่สุด

นี่ไม่เกี่ยวกับสแน็ปช็อตสำหรับการกู้คืนทั้งระบบอย่างรวดเร็ว แต่เกี่ยวกับไฟล์และฐานข้อมูลและประวัติการเปลี่ยนแปลง

พื้นหลัง:

VDS บนการจำลองเสมือน XEN;
ระบบปฏิบัติการ 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 และ Amazon S3 ไม่มีความแตกต่างสำหรับฉัน Yandex รองรับ Amazon S3 API จำนวนมาก ดังนั้นคุณจึงสามารถทำงานกับมันได้โดยใช้โซลูชันที่มีอยู่สำหรับการทำงานกับ S3 ในกรณีของฉัน นี่คือยูทิลิตี้การทำซ้ำ

ข้อได้เปรียบหลักของ Yandex คือการจ่ายเป็นรูเบิลหากมีข้อมูลจำนวนมากจะไม่มีการเชื่อมโยงกับอัตราแลกเปลี่ยน ในแง่ของความเร็ว ศูนย์ข้อมูลในยุโรปของ Amazon ทำงานได้เทียบเท่ากับศูนย์ข้อมูลของรัสเซียใน Yandex ตัวอย่างเช่น คุณสามารถใช้แฟรงค์เฟิร์ตได้ ก่อนหน้านี้ฉันใช้ Amazon S3 สำหรับงานที่คล้ายกัน ตอนนี้ฉันตัดสินใจลองใช้ Yandex

การตั้งค่า Yandex.Cloud

1. คุณต้องสร้างบัญชีการชำระเงินใน Yandex.Cloud ในการดำเนินการนี้ คุณต้องเข้าสู่ระบบ Yandex.Cloud ผ่านบัญชี Yandex ของคุณหรือสร้างบัญชีใหม่

2. สร้าง "คลาวด์"

3. ใน "คลาวด์" ให้สร้าง "แคตตาล็อก"

4. สำหรับ "แค็ตตาล็อก" ให้สร้าง "บัญชีบริการ"

5. สร้างคีย์สำหรับ "บัญชีบริการ"

6. เก็บกุญแจไว้ เพราะจะต้องใช้ในอนาคต

7. สำหรับ “Directory” ให้สร้าง “Bucket” ไฟล์ต่างๆ จะเข้าไปอยู่ในนั้น

8. ฉันแนะนำให้ตั้งค่าขีดจำกัดและเลือก “ห้องเย็น”

การตั้งค่าการสำรองข้อมูลตามกำหนดเวลาบนเซิร์ฟเวอร์

คู่มือนี้ครอบคลุมถึงทักษะการบริหารขั้นพื้นฐาน

1. ติดตั้งยูทิลิตี้การทำซ้ำบน VDS

yum install duplicity

2. สร้างโฟลเดอร์สำหรับดัมพ์ mysql ในกรณีของฉันคือ /backup_db ในรูท VDS

3. สร้างโฟลเดอร์สำหรับสคริปต์ทุบตี /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 เพื่อให้ผู้ใช้ root ทำงาน 2 ครั้งต่อวัน หรือตามความถี่ที่คุณต้องการ

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

การกู้คืนข้อมูลจาก Yandex.Cloud

1. สร้างโฟลเดอร์การกู้คืน /backup_restore

2. สร้างสคริปต์ทุบตีสำหรับการกู้คืน /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 เช่น Ubuntu หรือ Debian

ที่มา: will.com

การสำรองข้อมูล VDS แบบเพิ่มหน่วยด้วยไซต์บน 1C-Bitrix ใน Yandex.Cloud

Yandex.Cloud กับ Amazon S3

การตั้งค่า Yandex.Cloud

การตั้งค่าการสำรองข้อมูลตามกำหนดเวลาบนเซิร์ฟเวอร์

การกู้คืนข้อมูลจาก Yandex.Cloud

สรุป

เพิ่มความคิดเห็น ยกเลิกการตอบ