Нусхаи афзояндаи VDS бо сайт дар 1C-Bitrix дар Yandex.Cloud

Мне было необходимо делать 2 раза в сутки бэкап сайта на «1С-Битрикс: Управление сайтом» (файлов и базы mysql) и хранить историю изменений за 90 дней.

Сайт расположен на VDS под управлением ОС CentOS 7 с установленным «1С-Битрикс: Веб-окружение». Дополнительно делать резервную копию настроек ОС.

Талабот:

  • Частота — 2 раза в сутки;
  • Хранить копии за последние 90 дней;
  • Возможностью достать отдельные файлы за определенную дату, при необходимости;
  • Бэкап должен храниться в отличном от VDS дата-центре;
  • Возможность получить доступ к бэкапу из любого места (другой сервер, локальный компьютер и т.д.).

Важным моментом являлась возможность быстро создавать бэкапы с минимальным потреблением дополнительного места и ресурсов системы.

Ин на дар бораи аксбардорӣ барои зуд барқарор кардани тамоми система, балки дар бораи файлҳо ва пойгоҳи додаҳо ва таърихи тағирот.

Маълумоти аввалия:

  • VDS дар виртуализатсияи XEN;
  • OS CentOS 7;
  • 1С-Битрикс: Веб-окружение;
  • Вебсайт дар асоси "1C-Bitrix: Идоракунии сайт", Версияи стандартӣ;
  • Андозаи файл 50 ГБ аст ва афзоиш хоҳад ёфт;
  • Андозаи пойгоҳи додаҳо 3 ГБ аст ва афзоиш хоҳад ёфт.

Стандартное резервное копирование встроенное в 1С-Битрикс — исключил сразу. Оно подойдет только небольшим сайтам, т.к.:

  • Он ҳар дафъа нусхаи пурраи сайтро месозад, аз ин рӯ ҳар як нусха ҳамон миқдор фосилаеро ишғол мекунад, ки файлҳоро ишғол мекунанд, дар ҳолати ман он 50 ГБ аст.
  • Резервное копирование делается средствами PHP, что с такими объемами файлов — невозможно, оно перегрузит сервер и не закончится никогда.
  • И конечно же ни о каких 90 днях речи идти не может при хранении полной копии.

Решение которое предлагает хостер, это диск для бэкапов находящийся в том же дата-центре, где и VDS, но на другом сервере. С диском можно работать по FTP и использовать свои сценарии, либо если на VDS установлен ISPManager, то через его модуль резервного копирования. Данный вариант не подходит из-за использования того же дата-центра.

Из всего вышесказанного оптимальным для меня выбором является инкрементальный бэкап по собственному сценарию в Яндекс.Облако (Object Storage) или Amazon S3 (Amazon Simple Storage Service).

Ин талаб мекунад:

  • root доступ к VDS;
  • установленная утилита duplicity;
  • аккаунта в Яндекс.Облаке.

Инкрементальный бэкап — усуле, ки дар он танҳо маълумоте, ки пас аз нусхабардории охирин тағир ёфтааст, бойгонӣ карда мешавад.

такрорӣ — бэкап утилита использующая rsync алгоритмы и умеющая работать с Amazon S3.

Яндекс.Облако vs Amazon S3

Разницы между Яндекс.Облаком и Amazon S3 в данном случае для меня нет. Яндекс поддерживает основную часть API Amazon S3, поэтому с ним можно работать используя решения, которые есть для работы с S3. В моём случае это утилита duplicity.

Бартарии асосии Яндекс метавонад пардохт бо рубл бошад, агар маълумот зиёд бошад, ба қурби асъор пайваст намешавад. Аз нуқтаи назари суръат, марказҳои додаҳои аврупоии Amazon дар муқоиса бо марказҳои додаҳои русии Яндекс кор мекунанд; масалан, шумо метавонед Франкфуртро истифода баред. Ман қаблан Amazon S3-ро барои вазифаҳои шабеҳ истифода мекардам, ҳоло ман қарор додам, ки Яндексро санҷам.

Настройка Яндекс.Облака

1. Шумо бояд дар Yandex.Cloud ҳисоби пардохт эҷод кунед. Барои ин, шумо бояд ба Yandex.Cloud тавассути ҳисоби Yandex-и худ ворид шавед ё ҳисоби нав эҷод кунед.

2. Создать «Облако».
Нусхаи афзояндаи VDS бо сайт дар 1C-Bitrix дар Yandex.Cloud

3. В «Облаке» создать «Каталог».
Нусхаи афзояндаи VDS бо сайт дар 1C-Bitrix дар Yandex.Cloud

4. Для «Каталога» создать «Сервисный аккаунт».
Нусхаи афзояндаи VDS бо сайт дар 1C-Bitrix дар Yandex.Cloud

5. Барои "Ҳисоби хидматӣ" калидҳо эҷод кунед.
Нусхаи афзояндаи VDS бо сайт дар 1C-Bitrix дар Yandex.Cloud

6. Ключи сохранить, они нужны будут в дальнейшем.
Нусхаи афзояндаи VDS бо сайт дар 1C-Bitrix дар Yandex.Cloud

7. Для «Каталога» создать «Бакет», в него будут попадать файлы.
Нусхаи афзояндаи VDS бо сайт дар 1C-Bitrix дар Yandex.Cloud

8. Ман тавсия медиҳам, ки маҳдудият муқаррар карда, "Нигоҳдории сард" -ро интихоб кунед.
Нусхаи афзояндаи VDS бо сайт дар 1C-Bitrix дар Yandex.Cloud

Насб кардани нусхаҳои эҳтиётии ба нақша гирифташуда дар сервер

Ин дастур малакаҳои асосии маъмуриро дарбар мегирад.

1. Установить на VDS утилиту duplicity

yum install duplicity

2. Барои партовҳои mysql ҷузвдон эҷод кунед, дар ҳолати ман он /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. Бори аввал скриптро иҷро кунед ва натиҷаро тафтиш кунед, файлҳо бояд дар "Сатил" пайдо шаванд.

`which bash` /backup_scripts/backup.sh

Нусхаи афзояндаи VDS бо сайт дар 1C-Bitrix дар Yandex.Cloud

5. Ба cron скрипт илова кунед, то корбари решавӣ дар як рӯз 2 маротиба ё бо басомади лозима кор кунад.

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

Барқарор кардани маълумот аз Yandex.Cloud

1. Сделать папку для восстановления /backup_restore

2. Барои барқарорсозӣ /backup_scripts/restore.sh скрипти bash созед

Ман мисоли маъмултарини барқарор кардани файли мушаххасро медиҳам:

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

У duplicity есть один минус — нет возможности задать лимит использования канала. С обычным каналом это не создает проблемы, а с при использовании канала с защитой от DDoS с тарификацией по скорости в сутки, я бы хотел иметь возможность установить ограничение в 1-2 мегабита.

Хамчун хулоса

Нусхаи эҳтиётӣ дар Yandex.Cloud ё Amazon S3 нусхаи мустақили сайт ва танзимоти ОС-ро таъмин мекунад, ки онҳоро аз ҳама гуна сервер ё компютери маҳаллӣ дастрас кардан мумкин аст. Ғайр аз он, ин нусха дар панели идоракунии хостинг ё дар панели администратори Bitrix, ки амнияти иловагиро таъмин мекунад, намоён нест.

При самом печальном исходе можно собрать новый сервер и развернуть сайт за любую дату. Хотя наиболее востребованным функционалом будет возможность обратиться к файлу за определённую дату.

Использовать данную методику можно с любыми VDS или Dedicated серверами и сайтами на любых движках, не только 1С-Битрикс. ОС также может быть отличная от CentOS, например Ubuntu или Debian.

Манбаъ: will.com

Илова Эзоҳ