Инкрементално архивиране на 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).

Това изисква:

• root достъп до VDS;
• инсталирана помощна програма за дублиране;
• акаунт в Yandex.Cloud.

инкрементално архивиране - метод, при който се архивират само данни, които са променени след последното архивиране.

лицемерие - помощна програма за архивиране, която използва rsync алгоритми и може да работи с Amazon S3.

Yandex.Cloud срещу Amazon S3

За мен в този случай няма разлика между Yandex.Cloud и Amazon S3. Yandex поддържа основната част от API на Amazon S3, така че можете да работите с него, като използвате решенията, които са налични за работа с S3. В моя случай това е помощната програма за дублиране.

Основното предимство на Yandex може да бъде плащането в рубли, ако има много данни, тогава няма да има връзка към курса. По отношение на скоростта европейските центрове за данни на Amazon работят съизмеримо с руските в Yandex, например можете да използвате Франкфурт. Преди използвах Amazon 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 скриптове /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. Направете bash скрипт за възстановяване /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, който преди е бил включен в архива.

Можете да правите по-фини корекции според вашите нужди.

минус двуличие

Duplicity има един недостатък - няма начин да зададете ограничение за използване на канала. При нормален канал това не създава проблем, но при защитен от DDoS канал с таксуване на скорост на ден бих искал да мога да задам лимит от 1-2 мегабита.

Като заключение

Архивирането в Yandex.Cloud или Amazon S3 предоставя независимо копие на настройките на сайта и операционната система, които могат да бъдат достъпни от всеки друг сървър или локален компютър. В същото време това копие не се вижда нито в контролния панел на хостинга, нито в админ панела на Bitrix, което осигурява допълнителна сигурност.

В най-неблагоприятния изход можете да изградите нов сървър и да разположите сайта за всяка дата. Въпреки че най-търсената функционалност ще бъде възможността за достъп до файла за определена дата.

Можете да използвате тази техника с всеки VDS или специализиран сървър и сайт на всякакви двигатели, не само 1C-Bitrix. Операционната система може да бъде и различна от CentOS, като Ubuntu или Debian.

Източник: www.habr.com