Инкрементална резервна копија ВДС-а са сајтом на 1Ц-Битриксу у Иандек.Цлоуд

Требало је да правим резервне копије сајта на „2Ц-Битрикс: Управљање сајтом“ (датотеке и мискл база података) два пута дневно и чувам историју промена 1 дана.

Сајт се налази на ВДС-у који ради под оперативним системом ЦентОС 7 са инсталираним 1Ц-Битрик: Веб окружењем. Поред тога, направите резервну копију подешавања вашег ОС-а.

zahtevi:

• Учесталост - 2 пута дневно;
• Чувајте копије за последњих 90 дана;
• Могућност добијања појединачних датотека за одређени датум, ако је потребно;
• Резервна копија мора бити ускладиштена у дата центру који није ВДС;
• Могућност приступа резервној копији са било ког места (други сервер, локални рачунар, итд.).

Важна тачка је била могућност брзог креирања резервних копија уз минималну потрошњу додатног простора и системских ресурса.

Овде се не ради о снимку за брзо враћање целог система, већ о датотекама и бази података и историји промена.

Почетни подаци:

• ВДС на КСЕН виртуелизацији;
• ОС ЦентОС 7;
• 1Ц-Битрик: Веб окружење;
• Веб локација заснована на „1Ц-Битрик: Управљање сајтом“, стандардна верзија;
• Величина датотеке је 50 ГБ и расте;
• Величина базе података је 3 ГБ и она ће расти.

Одмах сам искључио стандардну резервну копију уграђену у 1Ц-Битрикс. Погодан је само за мале локације, јер:

• Сваки пут прави потпуну копију сајта, тако да ће свака копија заузимати исту количину простора као и датотеке, у мом случају то је 50 ГБ.
• Бацкуп се ради помоћу ПХП-а, што је немогуће са таквим обимима фајлова, преоптеретиће сервер и никада се неће завршити.
• И наравно, не може бити говора ни о каквим 90 дана када се чува пуна копија.

Решење које нуди хостерОво је резервни диск који се налази у истом дата центру као и VDS, али на другом серверу. Диску можете приступити путем FTP-а и користити сопствене скрипте или, ако је ISPManager инсталиран на VDS-у, преко његовог модула за резервне копије. Ова опција није погодна јер користи исти дата центар.

Од свега наведеног, најбољи избор за мене је инкрементална резервна копија помоћу моје сопствене скрипте у Иандек.Цлоуд (Објецт Стораге) или Амазон С3 (Амазон Симпле Стораге Сервице).

Ово захтева:

• роот приступ ВДС-у;
• инсталиран услужни програм за дупличност;
• налог у Иандек.Цлоуд.

Инкрементална резервна копија — метода у којој се архивирају само подаци који су промењени од последње резервне копије.

дуплицити — услужни програм за прављење резервних копија који користи рсинц алгоритме и може да ради са Амазон С3.

Иандек.Цлоуд против Амазон С3

У овом случају, за мене нема разлике између Иандек.Цлоуд и Амазон С3. Иандек подржава већину Амазон С3 АПИ-ја, тако да можете да радите са њим користећи решења која постоје за рад са С3. У мом случају, ово је услужни програм за дупличност.

Главна предност Иандек-а може бити плаћање у рубљама, ако има пуно података, неће бити везе са курсом. Што се тиче брзине, европски центри података компаније Амазон раде упоредиви са руским центрима података у Иандек-у, на пример, можете користити Франкфурт. Раније сам користио Амазон С3 за сличне задатке, али сада сам одлучио да испробам Иандек.

Подешавање Иандек.Цлоуд

1. Потребно је да направите налог за плаћање у Иандек.Цлоуд. Да бисте то урадили, потребно је да се пријавите на Иандек.Цлоуд преко свог Иандек налога или да направите нови.

2. Направите „облак“.


3. У „Облаку“ креирајте „Каталог“.


4. За „Каталог“ креирајте „Налог услуге“.


5. Креирајте кључеве за „Сервисни налог“.


6. Сачувајте кључеве, биће вам потребни у будућности.


7. За „Именик“ направите „Буцкет“, датотеке ће ићи у њега.


8. Препоручујем да поставите ограничење и изаберете „Хладно складиште“.

Подешавање планираних резервних копија на серверу

Овај водич претпоставља основне административне вештине.

1. Инсталирајте услужни програм за дупличност на ВДС

yum install duplicity

2. Направите фасциклу за мискл думпове, у мом случају то је /бацкуп_дб у корену ВДС-а

3. Направите фасциклу за басх скрипте /бацкуп_сцриптс и направите прву скрипту која ће извршити резервне копије /бацкуп_сцриптс/бацкуп.сх

Садржај скрипте:

#!`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. Покрените скрипту по први пут и проверите да ли се резултати морају појавити у „Буцкет“.

`which bash` /backup_scripts/backup.sh

5. Додајте скрипту у црон за роот корисника да се покреће 2 пута дневно, или са фреквенцијом која вам је потребна.

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

Опоравак података из Иандек.Цлоуд

1. Направите фасциклу за опоравак /бацкуп_ресторе

2. Направите басх скрипту за опоравак /бацкуп_сцриптс/ресторе.сх

Дајем најпопуларнији пример враћања одређене датотеке:

#!`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

У фасцикли /бацкуп_ресторе/ пронаћи ћете датотеку индек.пхп за коју је претходно направљена резервна копија.

Можете извршити финија подешавања која одговарају вашим потребама.

Минус дуплирање

дупличност има један недостатак - није могуће поставити ограничење коришћења канала. Са редовним каналом то не ствара проблем, али када користите канал заштићен од ДДоС-а са брзим пуњењем дневно, желео бих да могу да поставим ограничење од 1-2 мегабита.

Као закључак

Прављење резервне копије на Yandex.Cloud или Amazon S3 пружа независну копију подешавања вашег веб-сајта и оперативног система којој се може приступити са било ког другог сервера или локалног рачунара. Ова копија није видљива никоме. контролне табле хостинг, нити у администраторском панелу Битрикс-а, који пружа додатну безбедност.

У најгорем случају, можете саставити нови сервер и поставити локацију у било ком тренутку. Иако ће најпопуларнија функционалност бити могућност приступа датотеци за одређени датум.

Ову технику можете да користите са било којим ВДС или наменским серверима и сајтовима на било ком систему, а не само 1Ц-Битрикс. Оперативни систем такође може бити другачији од ЦентОС-а, као што је Убунту или Дебиан.

Извор: ввв.хабр.цом