ProHoster > блог > адміністраванне > Інкрыментальны бэкап VDS з сайтам на 1С-Бітрыкс у Яндэкс.Хмара

Інкрыментальны бэкап 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. Стварыць «Хмара».
Інкрыментальны бэкап VDS з сайтам на 1С-Бітрыкс у Яндэкс.Хмара

3. У «Аблокі» стварыць «Каталог».
Інкрыментальны бэкап VDS з сайтам на 1С-Бітрыкс у Яндэкс.Хмара

4. Для "Каталогу" стварыць "Сэрвісны акаўнт".
Інкрыментальны бэкап VDS з сайтам на 1С-Бітрыкс у Яндэкс.Хмара

5. Для "Сэрвіснага акаўнта" стварыць ключы.
Інкрыментальны бэкап VDS з сайтам на 1С-Бітрыкс у Яндэкс.Хмара

6. Ключы захаваць, яны патрэбны будуць у далейшым.
Інкрыментальны бэкап VDS з сайтам на 1С-Бітрыкс у Яндэкс.Хмара

7. Для "Каталога" стварыць "Бакет", у яго будуць трапляць файлы.
Інкрыментальны бэкап VDS з сайтам на 1С-Бітрыкс у Яндэкс.Хмара

8. Рэкамендую задаць ліміт і абраць «Халоднае сховішча».
Інкрыментальны бэкап VDS з сайтам на 1С-Бітрыкс у Яндэкс.Хмара

Настройка рэзервовага капіявання па раскладзе на серверы

Дадзенае кіраўніцтва мяркуе наяўнасць базавых навыкаў адміністравання.

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 з сайтам на 1С-Бітрыкс у Яндэкс.Хмара

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

Дадаць каментар