Incremental VDS backup na may site sa 1C-Bitrix sa Yandex.Cloud

Kinailangan kong i-backup ang site sa 2C-Bitrix: Site Management 1 beses sa isang araw (mga file at mysql database) at mag-imbak ng kasaysayan ng mga pagbabago sa loob ng 90 araw.

Ang site ay matatagpuan sa isang VDS na tumatakbo sa CentOS 7 na may naka-install na "1C-Bitrix: Web Environment". Bukod pa rito, gumawa ng backup na kopya ng mga setting ng OS.

Mga Kinakailangan:

• Dalas - 2 beses sa isang araw;
• Panatilihin ang mga kopya para sa huling 90 araw;
• Ang kakayahang makakuha ng mga indibidwal na file para sa isang tiyak na petsa, kung kinakailangan;
• Ang backup ay dapat na naka-imbak sa isang data center maliban sa VDS;
• Ang kakayahang ma-access ang backup mula sa kahit saan (isa pang server, lokal na computer, atbp.).

Ang isang mahalagang punto ay ang kakayahang mabilis na lumikha ng mga backup na may kaunting pagkonsumo ng karagdagang espasyo at mga mapagkukunan ng system.

Ito ay hindi tungkol sa isang snapshot para sa isang mabilis na pagpapanumbalik ng buong system, ngunit tungkol sa mga file at database at ang kasaysayan ng mga pagbabago.

Pinagmulan ng data:

• VDS sa XEN virtualization;
• OS CentOS 7;
• 1C-Bitrix: Web environment;
• Site batay sa "1C-Bitrix: Site Management", Standard na bersyon;
• Ang laki ng file ay 50 GB at lalago;
• Ang laki ng database ay 3 GB at lalago.

Karaniwang backup na binuo sa 1C-Bitrix - agad na hindi kasama. Ito ay angkop lamang para sa maliliit na site, dahil:

• Gumagawa ng kumpletong kopya ng site sa bawat oras, ayon sa pagkakabanggit, ang bawat kopya ay kukuha ng mas maraming espasyo habang kinukuha ko ang mga file, sa aking kaso ito ay 50 GB.
• Ginagawa ang pag-backup gamit ang PHP, na imposible sa ganitong dami ng mga file, mag-overload ito sa server at hinding-hindi matatapos.
• At siyempre, hindi maaaring pag-usapan ang anumang 90 araw kapag nag-iimbak ng isang buong kopya.

Ang solusyon na inaalok ng hoster ay isang backup na disk na matatagpuan sa parehong data center bilang VDS, ngunit sa ibang server. Maaari kang magtrabaho kasama ang disk sa pamamagitan ng FTP at gamitin ang iyong sariling mga script, o kung ang ISPManager ay naka-install sa VDS, pagkatapos ay sa pamamagitan ng backup na module nito. Hindi angkop ang opsyong ito dahil sa paggamit ng parehong data center.

Mula sa lahat ng nasa itaas, ang pinakamahusay na pagpipilian para sa akin ay isang incremental backup ayon sa sarili kong senaryo sa Yandex.Cloud (Object Storage) o Amazon S3 (Amazon Simple Storage Service).

Kailangan nito:

• root access sa VDS;
• naka-install na duplicity utility;
• account sa Yandex.Cloud.

incremental backup - isang paraan kung saan ang data lamang na nagbago mula noong huling backup ang naka-archive.

pagdaraya - isang backup na utility na gumagamit ng rsync algorithm at maaaring gumana sa Amazon S3.

Yandex.Cloud kumpara sa Amazon S3

Walang pagkakaiba sa pagitan ng Yandex.Cloud at Amazon S3 sa kasong ito para sa akin. Sinusuportahan ng Yandex ang pangunahing bahagi ng Amazon S3 API, kaya maaari mong gamitin ito gamit ang mga solusyon na magagamit para sa pagtatrabaho sa S3. Sa aking kaso, ito ang duplicity utility.

Ang pangunahing bentahe ng Yandex ay maaaring pagbabayad sa rubles, kung mayroong maraming data, pagkatapos ay walang link sa kurso. Sa mga tuntunin ng bilis, ang mga European data center ng Amazon ay gumagana nang naaayon sa mga Ruso sa Yandex, halimbawa, maaari mong gamitin ang Frankfurt. Ginamit ko dati ang Amazon S3 para sa mga katulad na gawain, ngayon ay nagpasya akong subukan ang Yandex.

Pagse-set up ng Yandex.Cloud

1. Kailangan mong lumikha ng account sa pagsingil sa Yandex.Cloud. Upang gawin ito, kailangan mong mag-log in sa Yandex.Cloud sa pamamagitan ng iyong Yandex account o lumikha ng bago.

2. Lumikha ng Cloud.


3. Sa "Cloud" lumikha ng isang "Catalog".


4. Para sa "Catalogue" lumikha ng "Serbisyo account".


5. Para sa "Serbisyo account" gumawa ng mga susi.


6. I-save ang mga susi, kakailanganin mo ang mga ito sa hinaharap.


7. Para sa "Catalog" lumikha ng isang "Bucket", ang mga file ay mahuhulog dito.


8. Inirerekomenda kong magtakda ng limitasyon at piliin ang "Cold Storage".

Pagse-set up ng mga naka-iskedyul na backup sa server

Ipinagpapalagay ng gabay na ito ang mga pangunahing kasanayan sa pangangasiwa.

1. I-install ang duplicity utility sa VDS

yum install duplicity

2. Lumikha ng isang folder para sa mysql dumps, sa aking kaso ito ay /backup_db sa ugat ng VDS

3. Lumikha ng isang folder para sa mga script ng bash /backup_scripts at gawin ang unang script na magba-backup /backup_scripts/backup.sh

Nilalaman ng script:

#!`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. Patakbuhin ang script sa unang pagkakataon at suriin ang resulta, dapat lumabas ang mga file sa Bucket.

`which bash` /backup_scripts/backup.sh

5. Magdagdag ng script sa cron para sa root user na maisakatuparan 2 beses sa isang araw, o nang madalas hangga't kailangan mo.

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

Pagbawi ng data mula sa Yandex.Cloud

1. Gumawa ng restore folder /backup_restore

2. Gumawa ng bash restore script /backup_scripts/restore.sh

Ibinibigay ko ang pinaka-hinihiling na halimbawa ng pagbawi ng isang partikular na file:

#!`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. Patakbuhin ang script at hintayin ang resulta.

`which bash` /backup_scripts/backup.sh

Sa folder na /backup_restore/ makikita mo ang index.php file na dating kasama sa backup.

Maaari kang gumawa ng mas pinong mga pagsasaayos upang umangkop sa iyong mga pangangailangan.

minus duplicity

May isang disbentaha ang duplicity - walang paraan upang magtakda ng limitasyon sa paggamit ng channel. Sa isang normal na channel, hindi ito gumagawa ng problema, ngunit sa isang channel na protektado ng DDoS na may bilis bawat araw na pagsingil, gusto kong makapagtakda ng limitasyon na 1-2 megabits.

Bilang konklusyon

Ang pag-back up sa Yandex.Cloud o Amazon S3 ay nagbibigay ng independiyenteng kopya ng site at mga setting ng OS na maaaring ma-access mula sa anumang iba pang server o lokal na computer. Kasabay nito, ang kopyang ito ay hindi makikita sa control panel ng pagho-host o sa Bitrix admin panel, na nagbibigay ng karagdagang seguridad.

Sa pinaka-kapus-palad na kinalabasan, maaari kang bumuo ng isang bagong server at i-deploy ang site para sa anumang petsa. Bagama't ang pinaka-hinihiling na functionality ay ang kakayahang ma-access ang file para sa isang partikular na petsa.

Maaari mong gamitin ang diskarteng ito sa anumang VDS o Dedicated server at site sa anumang engine, hindi lamang sa 1C-Bitrix. Ang OS ay maaari ding iba sa CentOS, gaya ng Ubuntu o Debian.

Pinagmulan: www.habr.com