Эффективное резервное копирование в Amazon Web Services — рецепты. Резервное копирование на битриксе

Бекап сайта, портала Битрикс24 на сетевое хранилище Windows

Обухов Константин

26.02.2016

Вам приходилось сталкиваться с ситуацией, когда сайт или портал Битрикс24 недоступен, потому что на диске неожиданно закончилось место? Да, последний бэкап съел все место на диске в самый неподходящий момент. Это обычная история, особенно для Bitrix24 в коробке, когда корпоративный портал начинают активно использовать сотрудники компании. Здесь есть и еще один риск: если слетит диск, можно потерять и сам сайт/портал, и его бекапы. Поэтому сетевое хранилище бекапов — отличное решение. О том, как корректно настроить бекап вашего сайта на сетевое хранилище Windows вы узнаете в этой статье. Задавайте вопросы, делитесь записью в соцсетях.

Многие сайты и корпоративные порталы Bitrix24 работают на Виртуальной машине Битрикс. Это удобно и надежно: не надо долго и нудно настраивать окружение сервера, сразу все ПО настроено "из коробки". Как правило, хостится это богатство на VPS или VDS тарифах или в каком-нибудь корпоративном облаке/сервере без бекапов.

Дано:

Сайт или портал на Виртуальной машине Битрикс (версия 5.0 и выше).
Сетевое хранилище с постоянным ip-адресом 10.10.10.30 (локальная сеть) на ОС WIndows.
Папка Backup на сетевом хранилище, куда мы будем складывать бекапы Битрикс24-портала или сайта на Битрикс.

Задача:

Настроить регулярное резервное копирование файлов и БД сайта/Битрикс24.
Хранить резервные копии на сетевом хранилище.

Решение 1. Для начала вспомним, что Виртуальная машина Битрикс работает на основе CentOS. Поэтому первым делом необходимо убедится, что сетевое хранилище доступно по ip–адресу.

ping -c3 10.10.10.30 PING 10.10.10.30 (10.10.10.30): 56 data bytes 64 bytes from 10.10.10.30: icmp_seq=0 ttl=64 time=6.000 ms 64 bytes from 10.10.10.30: icmp_seq=1 ttl=64 time=3.593 ms 64 bytes from 10.10.10.30: icmp_seq=2 ttl=64 time=5.785 ms

Пинг проходит, хранилище доступно.

2. Теперь надо вспомнить, что изначально в CentOS нет возможности подключиться к Windows-системам. Для подключения этой функции необходимо под root установить пакет samba:

[root@server1 ~]# yum install samba

3. Теперь нам надо примонтировать внешнее хранилище как диск в Виртуальной машине Битрикс. 3.1 Создадим точку монитирования windows в папке mnt, эта папка будет соответствовать сетевому хранилищу

[root@server1 ~]# mkdir /mnt/windows

3.2 Запишем код подключения сетевого хранилища в настройки файловой системы CentOS, чтобы диск подключался автоматически при каждой загрузке ВМ Битрикс. Для этого редактируем под root файл /etc/fstab и добавляем вниз следующую строку:

//10.10.10.30/Backup /mnt/windows cifs defaults,uid=600,rw,suid,username=windowsuser,password=windowspassword 0 0

где:

//10.10.10.30/Backup - папка для хранения бекапов на сетевом хранилище с айпи-адресом 10.10.10.30, два слеша обязательные;
/mnt/windows - точка монитрования диска
uid - id пользователя CentOS, который должен стать владельцем примонитированного хранилища. Для виртуальных машин Битрикс это обычно id пользователя bitrix; узнать id вашего пользователя можно командой id -u bitrix

username,password - логин и пароль пользователя Active Directory, имеющего права записи на сетевое хранилище.

Остальные параметры можно оставить без изменения. Сохраняем изменения в файле /etc/fstab и выполняем команду перемонтирования дисков

[root@server1 ~]# mount -a

Внимание! Эта операция перемонитирует все диски файловой системе. Эту операцию не стоит делать в загруженное время. После этого выполняем команду df -h и видим наш диск среди других дисков системы:

[root@server1 ~]# df -h Filesystem Size Used Avail Use% Mounted on /dev/sda4 886G 430G 412G 52% /home/bitrix/www //10.10.10.30/Backup 1,0T 0,2T 0,8T 80% /mnt/windows

Диск успешно примонтирован, осталось 2 простых шага: включить резервное копирование в настройках виртуальной машины Битрикс и сделать скрипт перемещения файлов бекапа на сетевое хранилище.

4. Включить резервное копирование файлов и БД вашего сайта или портала Битрикс24 в Виртуальной машине Битрикс просто, это описано в учебном курсе. Заметим только, что бекап запускается по крону, поэтому необходимо запускать перемещение файлов бекапа на сетевое хранилище через 2-3 часа после запуска бекапа. Точный срок запуска скрипта перемещения файлов на хранилище Вам необходимо вычислить самостоятельно, он будет зависеть от размера вашего сайта.

5. Создадим bash-скрипт перемещения файлов бекапа на сетевое хранилище. Обычно Виртуальная машина Битрикс складывает готовый архив сайта в директорию /home/bitrix/backup/archive. Поэтому мы заходим в директорию /home/bitrix и создаем файл archive.sh следующего содержания:

#!/bin/bash sDirectory="/home/bitrix/backup/archive" snew="/mnt/windows" find $sDirectory -type f -maxdepth 1 -exec mv {} $snew \;

где в sDirectory указывется путь к папке, в которую ВМ Битрикс складывает сделанные архивы, snew - точка монитрования сетевого хранилищца в ВМ Битрикс. Файл перемещения архива готов, нам осталось добавить его запуск на крон. Добавляем в файл /etc/crontab следующую строку:

10 2 * * * bitrix /home/bitrix/archive.sh

и сохраняем изменения. Теперь скрипт перемещения архива будет запускаться каждую ночь в 2 часа 10 минут.

www.infospice.ru

Эффективное резервное копирование в Amazon Web Services — рецепты

Всем привет! Сегодня поговорим о техниках настройки резервного копирования файлов и MySQL/InnoDB/XtraDB в приложениях, развернутых в облаке, на примере Amazon Web Services. В ходе разработки облачного сервиса Битрикс24 мы попробовали несколько схем резервного копирования, наткнулись на некоторые подводные камни архитектуры амазона и ограничения софта — однако все постепенно разложилось по полочкам и зажужжало :-) Также внимательно рассмотрим вопрос инкрементального бэкапирования достаточно больших объемов данных (сотни гигабайт и больше), рейдов и конфигураций с InnoDB/XtraDB. Но прежде всего в деталях разберемся в технологиях хранения данных, предлагаемых нам амазоном.

Где живут данные виртуальных машин

Итак, начнем с того, что нам предлагает амазон для хранения данных виртуальных машин — виртуальные блочные устройства EBS. Такой диск запросто создается и подключается к серверу в 2 клика. Максимальный размер диска — 1ТБ. По умолчанию, есть ограничение на 5000 дисков и 20ТБ, но его увеличивают по первой просьбе. Предлагается еще технология локальных блочных устройств, данные на которых… исчезают вместе с сервером (а это запросто может произойти при аварийном завершении работы машины) — но я про нее не буду писать, т.к. мы с ней не экспериментировали.

Производительность EBS-дисков

Довольно сразу видно, что они — медленнее «железных». Насыщение устройства (%util, команда iostat) при объеме произвольного чтения в десяток-другой МБ/сек (по записи — еще меньше) — быстро приближается к 100%. Притормаживание отчетливо видно на популярных операциях типа копирования папок с диска на диск, распаковке архивов и т.д.

Рейд?

Чтобы адекватно начать работать с дисками амазона, проще всего «засунуть» их в софтварный рейд. Для баз данных мы используем рейд-10 на 8 EBS дисках как на ext4, так и xfs. Делается софтварный рейд довольно просто, работает долго и практически не ломается. Рейд может особенно пригодиться, если EBS-диск внезапно «вылетет». Тем не менее, для ряда задач мы не используем рейды — например для хранения бинарного лога MySQL, для бэкапов и др. А для хранения кэша nginx хорошо подошел raid0 на EBS-дисках, который устойчиво работает без сбоев примерно год.

Надежность EBS-дисков

Если честно, за полтора года работы с EBS-дисками амазона они не разу нас не подводили (никаких глупостей типа «бэдов», ошибок чтения и др.)… кроме случая, когда в Ирландский датацентр амазона ударила молния — тогда вылетело сразу по несколько дисков из рейд-10 :-) Однако, если внимательно прочитать что пишет амазон о надежности своих дисков, то понимаешь, что и рейд нужно делать и, разумеется, регулярные бэкапы:Amazon EBS volume data is replicated across multiple servers in an Availability Zone to prevent the loss of data from the failure of any single component. The durability of your volume depends both on the size of your volume and the percentage of the data that has changed since your last snapshot. As an example, volumes that operate with 20 GB or less of modified data since their most recent Amazon EBS snapshot can expect an annual failure rate (AFR) of between 0.1% – 0.5%, where failure refers to a complete loss of the volume. This compares with commodity hard disks that will typically fail with an AFR of around 4%, making EBS volumes 10 times more reliable than typical commodity disk drives. С другой стороны у нас в продакшене больше сотни нагруженных EBS-дисков и за полтора года софтварные рейды не разу не выбивали диски из-за IO-ошибок. На «железных» дисках, уверен, мы бы уже сменили не одно устройство, так что делайте выводы.

Доступные технологии резервного копирования

Когда данных относительно немного и они меняются не часто, можно поиграться с tar. Но представьте себе крупный интернет-магазин, который хранит бизнес-информацию как в БД, так и в файлах на диске: новые файлы появляются ежеминутно, а общий размер контента составляет сотни гигабайт. DRBD? Да, но не пробовали эту технологию в амазоне да и нередко слышу от коллег о ее неимоверных торможениях при возникновении ошибок.LVM и снепшоты в режиме copy-on-write — подобие этой технологии, только с дополнительными плюшками и предлагает нам амазон. Снепшоты блочного устройства можно делать столько раз, сколько необходимо. При этом:

В очередной снепшот диска EBS попадают ТОЛЬКО ИЗМЕНЕНИЯ. Причем это совершенно прозрачно и становится очевидным, когда смотришь ежемесячный счет на использование места на дисках. Даже если у тебя 100 снепшотов с диска 500ГБ, но данные менялись не часто — платишь за примерно 500-500ГБ, что конечно играет в пользу клиента.
Можно и нужно удалять снепшоты — для сохранения балланса между размером окна резервирования и стоимостью хранения данных. При этом, что вызывает восторг, можно удалять ЛЮБОЙ снепшот — амазон автоматически консолидирует данные нужным образом. И совершенно не болит голова на тему — где базовый снепшот, а где инкрементальный — неважно, удаляешь лишние из любой позиции (кто работал с Acronis — оценит удобство).
Снепшоты дисков сохраняются в S3. S3 — как все наверно уже знают, это хранилище объектов любого формата, реплицирующее данные минимум еще в 2 датацентра. Т.е. снепшот диска становится практически «неубиваемым» и сохранен надежнее винтчестера в запертой тумбочке под рабочим столом :-).
Снепшот диска делается практически мгновенно — затем в фоне данные передаются в S3 определенное время (иногда десятки минут — если амазон загружен).

Все это означает, что мы можем делать снепшоты огромной папки часто меняющегося контента на диске хоть раз в 5 минут — они будут надежно сохраняться в S3 и если нужно откатить 1ТБ изменяемых данных на 5 минут назад — мы это с легостью делаем так:

Создаем диск из сохраненного снепшота.
Подключаем диск к серверу.

Разумеется, технически невозможно мгновенно перелить 1ТБ данных из S3 в SAN где живут EBS-диски, поэтому хотя блочное устройство и становится доступным операционной системе, данные на него будут заливаться в фоне определенное время — поэтому возможно скорость работы с диском поначалу будет не очень высокой. Но, тем не менее — согласитесь, как удобно можно делать инкрементальнрый бэкап большого объема данных и откатывать их на любую точку, например, на неделю назад с шагом в 5 минут? :-) Кроме возможности создания снепшотов с EBS-дисков, можно отправлять файлы в S3 напрямую. Удобна в использовании утилита s3cmd — можно синхронизировать деревья файловой системы с облаком в обоих направлениях (передаются только изменения на базе расчета md5 на локальном диске и хранения md5 объекта внутри s3 в «ETag»). Пробовали решения на базе технологии FUSE — s3fs, но заметили подтормаживания и длительные зависания с ростом LA при ее интенсивном использовании.

Снепшот рейда

Как я писал выше, EBS-диски показывают адекватную производительность, если их объединить в рейд0, рейд10. А как бэкапить рейд? Делать снепшот каждого диска по очереди? :-) Понимаем, что нельзя и амазон тут нам ничего не предлагает. Добрые люди написали удобную утилиту — ec2-consistent-snapshot. Можно использовать ее, а можно в скриптах повторить ее логику.

Используем файловую систему, поддерживающую «фризинг» — т.е. понимающую, что с нее сейчас делается снепшот на уровне блочного устройства и необходимо сбросить буферы, закоммитить транзакции и временно остановить изменения блоков. Такую команду (xfs_freeze) до недавнего времени понимала XFS, однако в «последних» дистрибутивах linux появилась возможность «фризить» и другие распространенные файловые системы: ext3/ext4, xfs, jfs, reiserfs.
Сбрасываем изменения и кратковременно запрещаем запись в ФС: «fsfreeze -f mountpoint»
Делаем снепшоты каждого диска рейда: AWS API call CreateSnapshot.
Разрешаем запись в ФС: «fsfreeze -u mountpoint»

Если у вас xfs — можно использовать команду xfs_freeze. Для подключения сохраненного рейда лучше написать скрипт, подключающий диски к машине и запускающий из них софтварный рейд. Сохраненный в снепшоты вышеуказанным способом рейд прекрасно поднимается не проигрывая журнал файловой системы — используем в разных местах в продакшене. Итак, мы научились делать снепшот рейдов в s3 с любым объемом данных с частотой хоть раз в 5 минут и восстанавливать данные с них. Подобные вещи, уверен, многим пригодятся на различных проектах в облаке.

Снепшот машины целиком

Иногда удобнее не париться отдельно с каждым рейдом, а сделать снепшот всех дисков машины одной командой. Можно сделать снепшот в 2 режимах: с остановом машины и без останова. В последнем случае нас логично предупреждают о возможной «порче» данных на дисках/рейдах:When taking a snapshot of a file system, we recommend unmounting it first. This ensures the file system metadata is in a consistent state, that the 'mounted indicator' is cleared, and that all applications using that file system are stopped and in a consistent state. Some file systems, such as xfs, can freeze and unfreeze activity so a snapshot can be made without unmounting. После создания снепшота машины появляется объект AMI (Amazon Machine Image), имеющий ссылки на сохраненные снепшоты каждого своего диска. Можно одной командой запустить из этого объекта сервер со всеми дисками/рейдами — AWS API call RunInstances. Почувствовали мощь технологии? Рабочие сервера можно не только бэкапить целиком, но и поднимать из бэкапа ЦЕЛИКОМ со всеми рейдами одной командой! Данная технология сэкономила нам десятки часов системного администрирования при аварии амазона в августе прошлого года — мы подняли машины из снепшотов и развернули конфигурацию в другом датацентре. Однако есть серьезный подводный камень — команда CreateImage совершенно непрозрачна и неясно, сколько времени она снимает снепшоты со всех дисков сервера — секунду или 10 секунд? Методом научного тыка был подобран интервал — 5 секунд, позволяющий снимать целостные образы машины с рейдами. Предупреждаю — тщательно протестируйте скрипт перед запуском в продакшн — однако перед «вкусностью» технологии создания полного бэкапа машины, согласитесь, трудно устоять :-)

Инкрементальный бэкап MySQL

Напомню нашу задачу — бэкапить проект с посещаемостью в миллионы хитов в сутки и сотнями гигабайт довольно часто меняющегося контента (самый тяжелый контент вынесен в s3 и скачивается отдельно). Повторю известные разумные подходы к бэкапу MySQL:

Логический бэкап со slave. В этом случае мы не замедляем работу основного сервера, однако… рискуем забэкапить «случайно» рассинхронизированные данные (поэтому нужно следить за синхронностью, например с помощью pt-table-checksum).
Бинарный снепшот с помощью LVM с боевого сервера/слейва, либо — копируем блоки на DRBD-диск на резервной машине.
Инкрементальный бинарный бэкап с боевого сервера или slave с помощью xtrabackup или аналогичным платным инструментом.

Чтобы иметь возможность быстро откатить крупный интернет магазин на 5-10 минут назад в случае катастрофического удаления данных в БД (ошибочный запрос, убивающий данные в нескольких таблицах заказов — с кем еще не было? :-) ) — кажется, что подойдет только 3 вариант. Однако, как оказалось, бинарный инкрементальный бэкап при создании оказывает немалую нагрузку на и без того слабенькие EBS-диски, но и чтобы наложить инкременты на базовый бинарный бэкап при восстановлении может уйти… несколько часов! Я не рассматривают тут сценарии восстановления из логического бэкапа с предварительным редактированием бинарного лога MySQL — это все равно быстро не сделать. И тут нам снова помогает амазон. Делается инкрементальный бэкап MySQL так:

Сбрасываем буферы MySQL/InnoDB/XtraDB на диск: «FLUSH TABLES WITH READ LOCK»
Сбрасываем изменения и кратковременно запрещаем запись в ФС: «fsfreeze -f mountpoint»
Делаем снепшот всех дисков машины: CreateImage. См. выше про подводные камни. Если есть опасения, делаем снепшоты каждого диска рейда с БД: AWS API call CreateSnapshot.
Разрешаем запись в ФС: «fsfreeze -u mountpoint»
Снимаем глобальную локировку всех таблиц во всех базах данных: «UNLOCK TABLES».

Теперь у нас появился объект AMI с горячим бэкапом MySQL и мы сделали максимум возможного, чтобы он запустился из бэкапа как можно быстрее. Таким образом, оказалось довольного просто делать инкрементальный бэкап сервера MySQL в S3 с частотой хоть раз в 5 минут и возможностью его быстрого ввода в продакшн. Если сервер используется в репликации, то он восстановит ее как правило без особых проблем, если вы не забыли в настройках задать консервативные настройки репликации (ну или ее можно довольно быстро вернуть в работу вручную):sync_binlog = 1innodb_flush_log_at_trx_commit = 1sync_master_info = 1sync_relay_log = 1sync_relay_log_info = 1

Как заскриптовать действия с амазоном?

Для системного администратора имеются удобные утилиты, дергающие REST-методы АПИ амазона. Скачивается несколько утилит, для каждого используемого веб-сервиса, и вызовы к утилитам скриптуются в bash. Вот пример скрипта, меняющего у сервера «железо»:#!/bin/bash #Change cluster node hw type #Which node to change hardware? NODE_INSTANCE_ID=$1 #To which hw-type to change? #Some 64-bit hw types: t1.micro (1 core, 613M), m1.large (2 cores, 7.5G), m1.xlarge (4 cores, 15G), #m2.xlarge (2 cores, 17G), c1.xlarge (8 cores, 7G) NODE_TARGET_TYPE='c1.xlarge' #To which reserved elastic ip to bind node? NODE_ELASTIC_IP=$2 ec2-stop-instances $NODE_INSTANCE_ID while ec2-describe-instances $NODE_INSTANCE_ID | grep -q stopping do sleep 5 echo 'Waiting' done ec2-modify-instance-attribute --instance-type $NODE_TARGET_TYPE $NODE_INSTANCE_ID ec2-start-instances $NODE_INSTANCE_ID ec2-associate-address $NODE_ELASTIC_IP -i $NODE_INSTANCE_ID Для разработчиков имеются библиотеки на разных языках для работы с API амазона. Вот библиотечка для работы из PHP — AWS SDK for PHP. Как видим, заскриптовать работу с объектами амазона — просто.

Итоги

На конкретных примерах, разбавленных теоретической базой популярных практик и подсоленных эффективными инструментами API амазона мы научились:

инкрементально бэкапить и восстанавливать большие объемы данных с EBS-дисков и рейдов амазона в S3 и обратно
бэкапить и восстанавливать машины амазона целиком
инкрементально бэкапить и быстро вводить в строй сервера MySQL с данными, хранящимися на рейдах EBS-дисков
обсудили несколько подводных камней
посмотрели как просто заскриптовать основные действия

В одной из следующих статей расскажу как эффективно управлять трафиком и балансировать нагрузку между кластерами и датацентрами амазона. На практике мы активно используем перечисленные в статье технологии, эксперементируем, открыты и готовы делиться опытом и искать простые и эффективные решения возникающих задач, используя инструменты мира open source. Приглашаю всех зарегистрироваться на нашем облачном сервисе «Битрикс24» и посмотреть что у нас получилось. Также приглашаю желающих на БЕСПЛАТНЫЙ семинар, посвященный веб-кластерам и высоким нагрузкам, который пройдет в конференц-зале компании «1С» 22 мая. Всем удачи в построении масштабируемых и отказоустойчивых систем!

habr.com

Резервное копирование сайта на Bitrix .NET Forge CMS v1.0: веб интерфейс

25.05.2012

Нашей давней мечтой было предоставить возможность себе, нашим клиентам, а если повезёт, то и всем желающим инструмент, аналогичный инструментарию резервного копирования в 1С-Битрикс: Управление Сайтом. Не то чтобы нам не давали спокойно жить лавры первооткрывателей и мы хотели прославиться, просто пережив на собственной шкуре серьёзную техническую аварию хостера, когда мы потеряли полгода истории крупного новостного ресурса, мы слишком сильно захотели присоединиться к тем администраторам, которые уже делают резервные копии.

Процесс проектирования, выделения финансов и времени затянулся, мы столкнулись с немалым количеством трудностей, которые уже описывали во вводной статье. И вот теперь мы официально презентуем первую стабильную версию решения для резервного копирования сайтов на Bitrix .Net Forge CMS!

В настоящий момент решение требует ручной установки на проект (описание процесса приведено дальше в этой статье).

Установка решения бекапирования

Для установки решения по резервному копированию необходимо установить на сайт пакет скриптов Coffeediz_NF_backup (). В содержимое пакета входят:

/bitrix/admin/backup.aspx
/bitrix/admin/backup.aspx.cs

Все скрипты находятся уже в соответствующих папках. Для установки решения необходимо распаковать архив и просто скопировать все папки в корень сайта (файлы будут скопированы в одноимённые папки, не затрагивая «соседей» по директории).

После этого скрипт для резервного копирвоания сайту будет доступен по адресу http://имя_сайта/bitrix/admin/backup.aspx

Доступ к скрипту восстановления по умолчанию имеют все пользователи, имеющие доступ к папке /bitrix/admin/, для более тонкой настройки вы можете воспользоваться настройками доступа к файлу /bitrix/admin/backup.aspx в файловой системе сайта (например через административный интерфейс Bitrix .NET Forge CMS), установив доступ только главному определённой роли пользователей сайта.

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

Работа решения по резервному копированию сайтов Bitrix .NET Forge CMS

панель бекапирования (с файлами бекапов)

Панель в настоящий момент позволяет осуществить резервное копирование:

Всегда копируя ядро продукта (рассматривая основные сценарии резервного копирования в предыдущей статье мы пришли к выводу, что это является необходимым для большинства пользователей)
Возможность включить или не включать в бекап публичную часть сайта (подходит для сценария с переносом ядра проекта для быстрого разворачивания «заготовок» сайтов со всеми модулями разработчика без дополнительных настроек)
Возможность исключить файлы больше определённого размера из архива
Возможность исключить файлы или директории по маске (возможно использование данного пункта для исключения файлов ядра в тех редких ситуациях, когда в этом нет необходимости, а так же для исключения других ненужных кастомных файлов и/или папок)
Возможность не сжимать медиа-файлы (рекомендуется использовать, если вы опасаетесь повреждения этих файлов, но намереваетесь упаковывать архив для уменьшения его веса)
Возможность включить или не включать в резервную копию базы данных (например если вам необходимо скопировать только файловую структуру проекта)
Возможность задания длительности шага и интервала между шагами резервного копирования (рекомендуется к использованию на виртуальных хостингах и серверах с ограниченными системными ресурсами, на которых в противном случае работа скрипта может вызывать ошибку ответа сервера)
Возможность отключить компрессию архива (резервная копия будет занимать больше места, однако работа скрипта пройдёт быстрее и окажет меньшую нагрузку на сервер)
Проверка целостности архива – рекомендуется не отключать данную опцию, позволяющую быть максимально уверенным в работоспособности полученной резервной копии.

Работа скрипта иллюстрируется прогресс-баром:

Наличие данного атрибута на экране говорит о том, что процесс создания резервной копии не завершён и нельзя закрывать страницу. После исчезновения прогресс-бара с экрана вы увидите новую резервную копию в списке, она будет иметь имя папки сайта с добавлением даты и времени создания резервной копии, чтобы вы могли спокойно хранить на внешнем носителе или хранилище несколько резервных копий разных сайтов.

Так же для резервной копии указываются размер и дата последнего изменения. Последний параметр должен соответствовать дате и времени в названии файла (с точностью до минуты), противное говорит о возможном изменении резервной копии (например злоумышленником), что может привести к неработоспособности файла бекапа!

Некопируемые решением области

Для предотвращения бесконтрольного разрастания файлов бекапа из резервной копии исключается директория с создаваемыми бекапами - /backup/.

ВАЖНО! Так же в настоящей версии решения следует обратить внимание на тот факт, что вырезается не содержимое директории, а директория целиком, хотя её наличие является критически важным для работоспособности скрипта по резервному копированию. После восстановления необходимо самостоятельно создать директорию /backup/ или повторно установить полный комплект скриптов решения.

Для предотвращения переноса неактуальной информации и уменьшения размера резервных копий не переносится кеш сайта.

Кеш будет автоматически создан при штатной работе сайта при первом же обращении пользователя к странице, что может привести к незначительному замедлению работы отдельных страниц сайта при первом обращении к ним пользователей и возрастанию нагрузки на сервер после восстановления из резервной копии.

Восстановление сайта из резервной копии

Для восстановления из резервной копии необходимо воспользоваться набором утилит RestoreTool. Содержимое архива необходимо распаковать и скопировать в корень сайта.

Файл web.config является не обязательным, однако без корректного файла скрипт восстановления не будет работать (проблема может быть актуальна при переносе на «пустой» хостинг или сервер).

Помимо набора скриптов для восстановления в корень сайта необходимо скопировать резервную копию из которой будет восстановлен сайт!

ВНИМАНИЕ! В настоящий момент работа скрипта не предусматривает возможности выбора файла резервной копии, поэтому не копируйте на сайт 2 и более резервных копий во избежание восстановления из неактуальной или нерабочей копии.

Скрипт имеет возможность отключения восстановления резервной копии Базы данных (снимите галочку, если вы хотите восстановить только файловую систему или ваша резервная копия не содержит БД).

Восстановление MS SQL Базы данных

Восстановление баз данных MS SQL имеет ряд особенностей, которые в частности ограничивают функциональность инструмента и накладывают ряд особенностей:

Для корректного восстановления БД необходимо указать адрес сервера Баз Данных (уточняется у хостера, системного администратора, либо самостоятельно).
Каталог – Имя Базы данных, которая будет создана. В настоящий момент скрипт восстановления не может восстановить сайт в имеющуюся базу данных, если она не является исходной. Т.е. если вы восстанавливаете старую версию сайта, то вам будет достаточно указать название старой БД, однако если вы создаёте сайт на новом хостинге или восстанавливаете сайт «рядом» со старым, то вам не удастся сделать это даже в условно «пустую» БД – необходимо предоставить скрипту возможность создать БД самостоятельно!
Логин – имя пользователя базы данных. В случае восстановления на сервер с отсутствующей БД (см. предыдущий пункт) пользователь должен иметь права администратора сервера БД (или по крайней мере возможность создания баз данных). После восстановления БД вы можете ограничить права пользователя на сервере на работу только с конкретной базой данных, либо исправить строку подключения БД (в web.confog) поставив в качестве пользователя того юзера, который обладает меньшими, но достаточными правами.
Пароль пользователя БД под которым будет выполнено восстановление БД.
Возможно введение возможности разбиение больших архивов (свыше 1ГБ) на части для упрощения транспортировки.

Обращаем ваше внимание на то, что логин и пароль пользователя БД (а так же адрес сервера и имя БД) могут отличаться от тех, которые использовались ранее на сервере, где была сделана резервная копия, если вы восстанавливаете сайт с созданием базы данных (например при переезде проекта на другой сервер).

После заполнения реквизитов рекомендуется проверить подключение к серверу. В этом случае проверяется только адрес БД, логин и пароль администратора сервера БД (если вы укажете реквизиты пользователя БД, не имеющего прав на создание БД, то проверка пройдёт неуспешно).

После успешного заполнения всех реквизитов восстановления БД (или при снятой галочке «восстановить Базу данных») нажмите кнопку «Восстановить» и дождитесь сообщения об успешном восстановлении сайта.

ВАЖНО! Не закрывайте страницу восстановления до окончания восстановления во избежание неполного восстановления системы, которое приведёт.

После восстановления сайта из бекапа

Первое и самое важное – удалите файлы резервной копии и решения по восстановлению из корня сайта. Файл web.config удалять уже не требуется – он заменяется в процессе восстановления корректным файлом, который содержит строку подключения к базе данных. Без корректно заполненного web.config сайт работать не будет! Однако вам следует понимать, что наличие в корне сайта файлов бекапа и скрипта восстановления – потенциальная угроза – если злоумышленник узнает об их наличии, то сможет попробовать воспользоваться процедурой повторного восстановления из резервной копии, что может привести к потере работоспособности сайта (например, если файловая система и БД окажутся несовместимыми) или вы просто откатитесь к старой версии сайта и потеряете все изменения, внесённые с момент самостоятельного восстановления. Не стоит компрометировать свой сайт без нужды.

Второе, что мы рекомендуем сделать – ограничить права пользователя БД, используемого на сайте для подключения к MS SQL Server (средствами сервера), либо замена его на пользователя с меньшими правами (необходимо внести соответствующие изменения в строку подключения БД в web.config).

Для корректной работы инструмента создания резервной копии на вновь восстановленном сайте необходимо вручную создать папку /backup/ в корне или произвести повторную установку всего решения для создания резервных копий сайта на Bitrix .Net Forge CMS от кофе-Дизайн студии.

Планы по развитию решения по резервному копированию сайтов на Bitrix .NET Forge CMS

Добавление возможности восстановления БД в существующую пустую базу (необходимо для виртуальных хостингов, либо сервера без возможности получения пользователя с правами на создание базы)
Добавление возможности выбора файла резервной копии из списка находящихся на сервере (возможно в будущем так же добавится возможность загрузки файла бекапа с удалённого сервера или локального компьютера, однако сейчас подобная возможность кажется не самой востребованной.
Добавление агентов резервного копирования, которые бы по установленным настройкам создавали резервную копию продукта периодически.
Возможно добавление соли в имя файла резервной копии, чтобы усложнить потенциальному злоумышленники работу по поиску и скачиванию чужих резервных копий (следует понимать, что копия, содержащая БД и конфигурационные файлы может серьёзно скажется на потенциальной уязвимости проекта к атакам.
Возможно добавление возможности шифрования файлов бекапа по паролю или даже паре логин\пароль (в наиболее отдалённом будущем и наименее вероятно на данный момент)
Создание мастера установки решения и упрощение интерфейса

В настоящий момент решение распространяется бесплатно и вы можете скачать его самостоятельно или получить по запросу. Обращаем ваше внимание на то, что мы распространяем решение по резервному копированию сайтов на 1С-Битрикс .NET Forge CMS бесплатно, но просим не распространять самостоятельно. На данный момент это сделано в силу значительных планов по развитию решения.

В наших планах пока не стоит платное распространение решения.

Мы готовы предоставить наше решение компании 1С-Битрикс для включения в продукт в том или ином виде, если это будет интересно представителям компании.

Если у вас есть вопросы – обращайтесь к нашим представителям через форму обратной связи, по почте или на форуме – мы постараемся максимально оперативно ответить на все вопросы и поставить в разработку все ваши конструктивные пожелания. Возможно приобретение технической поддержки и приоритетной разработки тех или иных ваших пожеланий на договорной основе. Небольшая помощь (в том числе оформление решение в меню проекта, дополнение инструкций страницы решения и тп) осуществляется бесплатно по запросу, однако необходимо предоставление доступа к сайту.

Так же в настоящий момент приглашаются для тестирования партнёры в области веб-разработки и хостинга для тестирования решения в различных условиях и конфигурациях сервером, хостингов и облачных систем.

Самостоятельная установка решения без информирования команды разработки Кофе-Дизайн ведёт к отказу в техническом обслуживании и предоставлении доступа к обновлениям решения.

Так же по запросу предоставляются готовые демо-проекты сайтов проекта НЕТ.кофедизайн.РФ на основе решения по резервному копированию сайтов на Bitrix .NET Forge CMS (для формирования пакета может потребоваться время, если пакет не сформирован заранее).

Мы выражаем надежду на то, что наше решение будет полезно сообществу и будем рады любой конструктивной критике, помощи, отзывам и поддержке!

Отдельное спасибо всем, принявшим участие в разработке, тестировании, финансировании и конструктивном обсуждении решения!

xn--80ahcjeib4ac4d.xn--p1ai