Інкрементальний бекап VDS з сайтом на 1С-Бітрікс в Яндекс.Хмара

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

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

вимоги:

• Частота - 2 рази на добу;
• Зберігати копії протягом останніх 90 днів;
• Можливістю дістати окремі файли за певну дату, за потреби;
• Бекап повинен зберігатися у відмінному від VDS дата-центрі;
• Можливість отримати доступ до бекапу з будь-якого місця (інший сервер, локальний комп'ютер тощо).

Важливим моментом була можливість швидко створювати бекапи з мінімальним споживанням додаткового місця та ресурсів системи.

Йдеться не про снапшот для швидкого відновлення всієї системи, а саме про файли та базу та історію зміни.

Вихідні дані:

• VDS на віртуалізації XEN;
• ОС CentOS 7;
• 1С-Бітрікс: Веб-оточення;
• Сайт на базі "1С-Бітрікс: Управління сайтом", версія Стандарт;
• Розмір файлів - 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. Необхідно створити платіжний обліковий запис в Яндекс.Хмарі. Для цього потрібно авторизуватися в Яндекс.Хмарі через свій обліковий запис Яндекса або створити новий.

2. Створити "Хмара".


3. В "Хмарі" створити "Каталог".


4. Для "Каталогу" створити "Сервісний обліковий запис".


5. Для «Сервісного облікового запису» створити ключі.


6. Ключі зберегти, вони будуть потрібні надалі.


7. Для "Каталогу" створити "Бакет", до нього потраплятимуть файли.


8. Рекомендую задати ліміт і вибрати Холодне сховище.

Налаштування резервного копіювання за розкладом на сервері

Даний посібник передбачає наявність базових навичок адміністрування.

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

5. Додати скрипт в cron для користувача root на виконання 2 рази на день або з потрібною вам частотою.

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

Відновлення даних з Яндекс.Хмари

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

Duplicity має один мінус — немає можливості задати ліміт використання каналу. З звичайним каналом це не створює проблеми, а з використанням каналу із захистом від DDoS з тарифікацією по швидкості на добу, я б хотів мати можливість встановити обмеження в 1-2 мегабіти.

Як висновок

Резервування в Яндекс.Хмарі або Amazon S3 дає незалежну копію сайту та налаштувань ОС, до якої можна звернутися з будь-якого іншого сервера або локального комп'ютера. При цьому копія не видно ні в панелі управління хостингом, ні в адмінці бітрикса, що дає додаткову безпеку.

За найсумнішого результату можна зібрати новий сервер і розгорнути сайт за будь-яку дату. Хоча найбільш потрібним функціоналом буде можливість звернутися до файлу за певну дату.

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

Джерело: habr.com