Восстановить сайт из резервной копии битрикс и Как развернуть резервную копию, созданную с помощью веб-среды VMBitrix v7.3?

Создание резервных копий – одно из преимуществ Битрикс перед другими CRM. Эта функция доступна во всех редакциях продукта. Бэкап можно делать на сервер или в облако. В статье разбираются оба варианта.

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

Когда бэкап необходим

Прежде всего следует отметить, что вызывает утрату данных:

• Поломка ПК.
• Ошибка функционирования ПО.
• Хищение физического носителя с программой и базой данных.
• Вредоносное ПО: вредоносный софт может серьезно повредить работу системы. Антивирусные программы не всегда могут поймать и обезвредить вирусы.
• Человеческий фактор: часто сотрудники могут случайно удалить рабочие файлы.

Своевременный бэкап Битрикс24 – это своего рода страховка данных от потери вследствие ошибок в работе ПО, хищения программы и базы данных, вирусов, и простого человеческого фактора. К тому же, восстановление резервной копии помогает сэкономить время, чтобы вернуть сайт в привычное русло работы.

Как восстановить Битрикс в облаке

Облачная версия портала автоматически делает ежедневный бэкап. Восстановление потерянных данных доступно только для платных тарифов «Стандартный» и «Профессиональный» с помощью техподдержки Битрикс24. Если до обращения в техподдержку прошло больше недели, файлы восстановить невозможно.

При утрате данных в облаке техподдержка получает обращение, а затем следует выбрать один из двух способов бэкапа.
Первый способ: создание и отправка CSV-файла с нужным временным периодом и выбранными элементами портала.

После получения файла администратор аккаунта делает импорт данных в CRM.

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

Этим способом можно воспользоваться для восстановления контактов, заявок, заказов.

Полный бэкап возвращает портал к резерву выбранной даты. Он необходим, когда удалены товары или поля.

После того, как выбран способ восстановления, администратор делает запрос в поддержку Битрикс24 с указанием даты утраты данных. Затем менеджеры поддержки сообщают о наличествующих резервных копиях. Затем следует согласовать даты и варианты отката программы.

Как восстановить Битрикс через приложения

Стандартное восстановление резервной копии Битрикс24 подразумевает обращение в техподдержку. Откат к последней версии занимает больше суток. Восстановить данные можно самостоятельно через приложения вроде CRM Backups 24 или Backup+. Приложения для восстановления доступны в Битрикс24.Маркет Плюс.

В приложении можно настроить автоматическое и ручное сохранение данных о компаниях, контактах и заявках с выбранной периодичностью. Число бэкапов в сутки и сроки их хранения зависят от тарифа приложения.

Ручное резервное копирование

Сперва нужно сделать копию Битрикс портала и дамп базы данных:

1. Копирование файлов. Сначала нужно создать копию базового каталога установки Битрикс24 /home/bitrix/www. Вот несколько примеров:

а) простое копирование:

cp -R /home/bitrix/www/* /backup/bitrix/www/

* здесь копируется содержимое файлов каталога /home/bitrix/www в папку /backup/bitrix/www.

б) синхронизация файлов через rsync:

rsync -avv /home/bitrix/www/ /backup/bitrix/www/>

* здесь поддерживается актуальное состояние каталога /home/bitrix/www. Для хранения папки назначен путь /backup/bitrix/www.

в) создание архива:

tar -zcvf /backup/bitrix/archive.tar.gz /home/bitrix/www

* для создания архива файла используется команда archive.tar.gz, где находится каталог /home/bitrix/www в сжатом виде.

2. Создание дампа базы данных. Наименование базы данных:

cat /home/bitrix/www/bitrix/php_interface/dbconn.php | grep DBName7

* /home/bitrix — место установки каталога Битрикс.

В этом примере строка вернула имя для базы bitrix_52. Команда для создания дампа будет:

mysqldump -uroot -p bitrix_52 > /backup/bitrix/mysql.sql

• пользователь команды root должен ввести пароль (после установки веб-окружения битрикс24 пароль для суперпользователя сохранен в файле /root/.my.cnf).
3. 3. Создание резервной копии использует следующий скрипт:

1. #!/bin/sh
2. PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
3.
4. fdate=`date +%Y-%m-%d`
5. my_user='backup'
6. my_password='backup123!'
7. my_base='bitrix_52'
8. path_backup='/backup/bitrix'
9.
10. mysqldump -u$my_user -p$my_password $my_base | gzip > $path_backup/mysql/my_$fdate.sql.zip
11. tar -zcf $path_backup/archive/ar_$fdate.tar.gz /home/bitrix/www 
 

• fdate — текущая дата, подставляется в мяи файлов бэкапа.
• my_user — пользователь для подключения к СУБД.
• my_password — пароль для подключения к СУБД.
• my_base — имя базы данных.
• path_backup — путь к месту хранения резервных копий.

По этому скрипту создаются архивы файлов и дамп базы данных.

Восстановление

Восстановить Битрикс после удаления можно через веб-интерфейс и командную строку Linux.

Бэкапы хранятся в каталоге <путь установки битрикс>/www/bitrix/backup.

Здесь таковым является /home/bitrix/www/bitrix/backup, куда переносятся все файлы бэкапов.

В перечне следует найти бэкап, перенесенную на сервер, кликнуть по иконке меню слева от него и выбрать Восстановить:

Клик по кнопке ДАЛЕЕ запустит процесс восстановления:

Мастер предложит ввести информацию для восстановления базы данных после распаковки файлов – по умолчанию подставляются значения из файла dbconn.php:

Старт восстановления базы данных:


Mysql query error: (1298) Unknown or incorrect time zone

При открытии восстановленного портала возникает ошибка.

Причина: система не может найти в базе используемый часовой пояс во время выполнения команды SET GLOBAL time_zone в MySQL.

Решение: для загрузки данных о часовых поясах в СУБД выполняется команда:

Warning: Unable to load '/usr/share/zoneinfo/iso3166.tab' as time zone. Skipping it. 
Warning: Unable to load '/usr/share/zoneinfo/leapseconds' as time zone. Skipping it. 
Warning: Unable to load '/usr/share/zoneinfo/tzdata.zi' as time zone. Skipping it. 
Warning: Unable to load '/usr/share/zoneinfo/zone.tab' as time zone. Skipping it. 
Warning: Unable to load '/usr/share/zoneinfo/zone1970.tab' as time zone. Skipping it. 
 

Не обращаем на них внимания.

По выполнении команды проблема не должна более возникать.

Вывод

Восстановление резервной копии Битрикс24 – это просто, удобно и бесплатно. Бэкап можно выполнить в несколько кликов из Административной системы.

Для уверенности в результате можно обратиться к профессиональным разработчикам.

Резервное копирование — процесс создания резервной копии, которая предназначена для восстановления данных в случае технических сбоев, повреждения данных или их утраты.

В статье рассмотрим процесс создания резервных копий данных на примере компании Eternalhost. На этом хостинге настроено инкрементное копирование – это метод сохранения информации, при котором архивируются только измененные с момента последнего полного бэкапа данные. 

В рассмотренном случае использовался виртуальный хостинг с панелью ISPmanager 6. 

Начало работы

Создание резервных копий происходит автоматически, резервные копии сохраняются на сервера Eternalhost и доступны для работы с ними. Также пользователь может создать одну полную резервную копию вручную. 

Для работы с резервными копиями пользователю нужно перейти в и в разделе «Инструменты» выбрать «Резервные копии».

Каждая резервная копия состоит из трех разделов: Базы данных, Почта и Файлы. Для восстановления одного из этих разделов нужно сделать следующее:

1. Во вкладке «Резервные копии» выбрать нужную дату копии, кликнув на нее. Нажать «Данные».

2. Кликнуть на нужный раздел  (Базы данных, Почта или Файлы) два раза.

3. Выбрать данные, которые нужно восстановить.

4. Нажать «Восстановить».

При восстановлении все существующие в резервной копии файлы будут автоматически заменены. Файлы, которые отсутствуют в копии, будут сохранены без изменений.

Новая резервная копия

Пользователь может сделать резервную копию самостоятельно, для этого ему нужно нажать «Новый». Система в то же время сделает копию  и скачает ее на компьютер пользователя.

Созданная версия будет содержать полную копию всех данных. Она будет подсвечиваться значком «Резервная копия создана пользователем».

Импорт резервной копии

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

1.  Нажать «Загрузить копию». Выбрать тип источника.
   
   
2. Выбрать тип источника и резервную копию (файл) для импорта.
   
3. Загруженная копия будет иметь статус «Резервная копия создана пользователем».

Скачать резервную копию

1. Перейти в раздел «Инструменты» «Резервные копии».

Настройка собственного хранилища резервных копий

По умолчанию резервные копии сохраняются на сервера Eternalhost. Однако, каждый клиент может настроить резервное копирование на стороннем сервере или в облаке. Для этого нужно сделать следующее:

1. Во вкладке «Резервные копии» перейти в «Настройки».
   
2.  В настройках резервного копирования поставить галочку напротив «Настроить собственное хранилище».
   
3. Выбрать тип хранилища из предложенных вариантов. Задавать пароль для резервной копии необязательно. Он используется для шифрования архива. Если поле не заполнено, данные шифроваться не будут.
   
4. В зависимости от выбора типа хранилища нужно задать данные ресурса, на котором будет храниться резервная копия.

Популярные ресурсы для хранения резервных копий

Dropbox

Код доступа

Для получения кода нужно перейти по ссылке, указанной над полем «Путь до бэкапов».  

Если не выполнен вход в аккаунт Dropbox, система попросит осуществить его, чтобы совершить привязку к ISPsystem. Затем появится сообщение «ISPsystem хочет получить доступ к своей папке Приложения › ISPsystem в вашем Dropbox». Здесь нужно нажать «Можно».

«Путь до бэкапов» (заполнять необязательно)

В аккаунте пользователя будут созданы папки «Приложения» и «ISPsystem», в которые будет сохраняться бэкап сайта.

Google Drive

Для выгрузки резервных копий вам потребуется создать

Код доступа

Для получения кода нужно перейти по ссылке, указанной над полем «Путь до бэкапов». 

«Путь до бэкапов» (заполнять необязательно)

Резервные копии будут сохраняться в папку, соответствующую имени пользователя на хостинге.

Amazon S3

Для выгрузки резервных копий вам потребуется создать аккаунт Amazon S3. Регистрация требует прикрепление банковской карты и подтверждение ее активности.  

Обязательные для заполнения поля:

Для получения кода и пароля нужно перейти по ссылке, указанной в соответствующем поле.

Яндекс.Диск

На данный момент Яндекс заблокировал приложение ISPmanager, поэтому резервное копирование на Яндекс.Диск сейчас невозможно.

FTP

Потребуется сторонний сервер с настроенным протоколом FTP.

Обязательные для заполнения поля:

• Порт FTP (по умолчанию 21);
• Путь к резервным копиям;

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

SFTP (over SSH)

Потребуется сторонний сервер с настроенным протоколом SFTP. 

Обязательные для заполнения поля:

• Порт SSH (по умолчанию 22);
• Путь к резервным копиям;
• Авторизация на сервере.

При выборе «по паролю», будет предложено ввести:

При выборе «по ключу SSH», будет предложено ввести:

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

Когда вы разрабатываете веб-сайт, есть один важный шаг: настройка резервного копирования на Битриксе. К счастью, создание надлежащей резервной копии — относительно простая задача. Для этого нужно решить следующие вопросы:

В этой статье компания Alto расскажет: 

• Как избежать системного краха сайта. 
• Как сделать резервную копию сайта на 1С-Битрикс.
• Как восстановить сайт на 1С-Битрикс.

Как избежать системного краха сайта

Первоначально владельцу нужно разработать политику создания резервных копий:

• сроки или периодичность;
• количество архивов датируемых разной датой.

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

  Соблюдать график резервного копирования сайта на Битрикс легко, достаточно настроить систему копирования на автоматическое создание архивов. Такой подход снижает потребность в персонале, потому что дампы будут сниматься без участия сотрудников. Восстановление также работает «по нажатию одной кнопки».

  Полностью рассчитывать на автоматику не стоит, особенно, в периоды обновления контента. Средств защиты от системных сбоев с абсолютной гарантией не существует, поэтому делать резервную копию своего сайта нужно обязательно. То же относится и к другим продуктам 1С типа CRM Битрикс24.

  Во втором случае резервное копирование в Битрикс лучше осуществлять вручную и сразу скачивать архивы на локальный накопитель. Например, при подключении к серверу через FTP. Тогда даже при полном крахе сайта получится восстановить работу почти без простоев (типовой ресурс разворачивается за 10-40 минут). Такое особенно интересно, если по тарифу хостинг-провайдера не удается делать более 2-3 архивных копий.

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

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

  Резервные копии на стороне хостинг-провайдера

  

  На виртуальном хостинге независимо от провайдера обычно работает система резервирования без вмешательства пользователя. Созданные копии отображаются в личном кабинете, там же имеются кнопки для восстановления, ручного архивирования сайта. На размещение файла «по умолчанию» используется пространство, выделенное под сайт, поэтому на сервере лежит не более 2-3 последних дампов, включающих полную копию ресурса (и парочка только с изменениями).

  Резервное копирование средствами платформы 1С-Битрикс

  У провайдеров есть возможность создавать и управлять резервными копиями. Несмотря на это надежнее в месте с этим использовать встроенные средства архивации. Это бывает удобно, когда нужно дать доступ сотруднику только к панели администратора CMS.

  Такой подход позволит управлять количеством резервных копий, объемом независимо от лимитов тарифного плана провайдера виртуального хостинга.

  

  Возможности встроенного инструмента для создания бэкапов в 1С-Битрикс:

  Если размер несжатых данных превышает 1 Гбайт, система разобьет дамп резервной копии на две и более частей. Можно сделать резервную копию сайта Битрикс с размещением на локальном или облачном хранилище. Главное, разделить места хранения для повышения сохранности ресурса, но с учетом удобства обратного копирования. При обнаружении неполадок нужно иметь возможность быстро исправить их развертыванием даже «очень старой» копией.

  Сохранение архива в «локальную» папку

  Существует три способа сделать копию сайта Битрикс:

  В первом случае достаточно выбрать пункт меню «Резервное копирование», расположенный по пути – Настройки> Инструменты. Вот здесь впервые пользователь сталкивается с условиями компании 1С-Битрикс по предоставлению дискового пространства.

  

  Основные моменты для локальных резервных копий сайта:

  Так, на «Старте» и «Стандарте» выделяется всего 2 Гбайт, для «Малого бизнеса» лимит увеличен до 4 Гбайт, для «Бизнеса» до 10 Гбайт. На тарифе «Энтерпрайз» пространство под бэкапы ничем не ограничено. Выбрать место расположения архива можно после включения режима «экспертных настроек», он доступен в закладке «Параметры» и активируется галочкой в соответствующем пункте. Там же указывают, какие файлы исключить из резервирования.

  

  Правила применения масок исключения:

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

  

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

  Сохранение резервной копии в облачном хранилище

  При выборе в качестве места хранения «облака», предоставляемого разработчиком, понадобится установить модуль «Облачные хранилища (Clouds)» или убедиться в его наличии. То же относится к «облакам» сторонних разработчиков. Перед первым резервированием желательно уточнить, есть ли подключение с сервисом. В первом случае также понадобится легитимный коммерческий ключ и установленный модуль «Облако 1С-Битрикс (Bitrixcloud)».

  

  Последнее зависит от встроенного алгоритма – файл всегда сначала создается локально и только затем переносится в «облако». При временных сбоях дамп можно найти по стандартному пути, в каталоге /bitrix/backup. После восстановления связи, когда система все-таки сможет скопировать сайт Битрикс в хранилище, тот будет автоматически удален. Физически хранилище «1С-Битрикс» расположено на сторонних серверах Amazon S3, поэтому приходится учитывать риски сбоев.

  Особенности резервирования при многосайтовости

  Сохранять в архиве можно любое количество сайтов, достаточно отметить нужные в перечне. Но со стороны администратора понадобится определенный перечень действий, чтобы сэкономить место на локальном накопителе или в «облаке». Например, нужно учитывать, что база данных копируется полностью, включая содержимое сайтов, которые не отмечены. Поэтому нет смысла создавать раздельные копии, они только займут «лишнее место».

  Есть еще особенности:

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

  Восстановление сайта на 1С-Битрикс

  

Заходим в админку Битрикс и нажимаем на настройки.

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

При лицензии сервер даёт 2 ГБ, то есть, можно сохранить всего 2-3 раза. Чтобы сделать несколько копий, лучше использовать сохранение на компьютере. 

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

При необходимости перейдите в «экспертные настройки», в «параметры». Там можно отрегулировать сохранение данных с сайта. 

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

Ждём, пока закончится загрузка резервной копии. Она может быть всего 20 минут, если проект небольшой и весит несколько ГБ. Все зависит от размера и количества данных.  

Для переноса резервной копии сайта на другой хостинг нужно поместить в папку нового сайта скрипт для восстановления. Скачиваем файл >/restore.php.

В корневую папку сайта поместим скачанный скрипт для восстановления. Для этого перейдем в архив сайта на компьютере. 
 

Локальная копия готова, время создания — несколько минут, дальше мы можем перейти в список. Перемещаемся по папкам: bxsite — bitrix — backup. Копируем все файлы, кроме index.php. Вставляем в папке bxrestored.

Затем в строке браузера проверяем скрипт для восстановления. Набираем bxrestored.loc/. В выпадающем списке нажимаем на restore.php и галочкой отмечаем «Архив загружен в корневую папку сайта». 

Файлы для восстановления базы данных готовы!

Скачивание архива через FTP

Выше вариант скачивания именно на базе системы Битрикс. Резервное копирование также можно сделать через FTP-клиента. Для этого:

• Через FTP-клиента подключаемся к сайту. Так как через Битрикс или сам хостинг были созданы резервные копии, переходим к папке backup;

• Здесь есть уже созданные архивы резервных копий. Если созданных резервных копий много, то можно посмотреть по дате самую свежую из них; 

• Выбираем нужную базу данных и просто скачиваем эти файлы себе на компьютер. Но перед скачиванием обязательно проверьте свободное место на своём хостинге под новый сайт. 

• Расшифровка резервных копий может быть только по лицензионному ключу и паролю. Ни в коем случае не теряйте их. Даже сотрудники Битрикса не смогут помочь, если нет пароля. 

  Где найти созданные копии в системе Битрикс? 

  После успешного создания резервная копия сайта будет расположена в списке резервных копий. Для этого нужно нажать на «Настройки», и в меню инструментов выбрать «Список резервных копий». 

  

  Нюансы при переносе данных в Битрикс

  Для снижения ошибок при резервном копировании, нужно учитывать особенности работы с системой:

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

• Чтобы не занимать свободное место, из выгрузки нужно удалить папки /bitrix/backup/ и /bitrix/cache/. 

• После запуска процесса восстановления нужно дождаться завершения процесса. При параллельном восстановлении часть файлов может не отобразиться и занять больше времени при переносе.

• Если сервер слабый, то ждите ошибок 502 и 504. В этом случае нужно рассмотреть другие варианты хостингов.

• Формат *.tar.gz предназначен для распаковки файлом restore.php. Никакой другой архиватор не подойдёт, так как есть риск потерять часть данных с этого резервной копии. Модификации с rar, zip, 7z также повредят файлы.

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

Чтобы с самого начала не сталкиваться с ошибками при переносе данных, нужно протестировать новый сервер на соответствие с настройками Битрикс. Делать это нужно через скрипт, который расположен на сервер-тесте. Этот скрипт постоянно обновляется, учитываются новые ошибки и обновления системы. 

• Скачиваем файл restore.php и переходим по ссылке вашего домена + restore.php.

• После скачивания система запросит данные для восстановления базы и файлов.

• Начнется выгрузка сайта. После этого можно удалить архив с копией и скриптами. Восстановление завершено. 

Ручной перенос данных через систему rsync

Если сайт, который нужно перенести на новый сервер, имеет размер несколько сотен ГБ и много мелких файлов, то автоматическое копирование на сервер нецелесообразно. В этом случае нужно перейти на автоматический перенос и минимизировать ошибки, лучше перейти на ручную проверку. Это можно сделать через систему rsync, так как:

• можно вручную найти мелкие ошибки и изменения в переносе данных, чтобы сразу их исправлять; 

• при таком переносе не нужно будет закрывать публичную часть сайта, а значит, вся работа будет проходить бесперебойно;

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

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

При автоматическом резервном копировании VMBitrix — фалы с backup-архивом помещаюстя в деректорию сервера /home/bitrix/backup/archive/www_backup_sitemanager_15.04.2019_8akRLwVX.tar.gz

1. Копируем резервную копию в корневую директорию сайта:
cp -R /home/bitrix/backup/archive/www_backup_sitemanager_15.04.2019_8akRLwVX.tar.gz /home/bitrix/www/www_backup_sitemanager_15.04.2019_8akRLwVX.tar.gz

2. Переходим в дирeкторию сайта с архивом
cd /home/bitrix/www/

3. Распаковываем архив, воcтонавливаем файловую систему сайта.
tar xzvvf www_backup_sitemanager_15.04.2019_8akRLwVX.tar.gz ./

4. Воcтонавливаем MySQL — Базу данных.
Дамп базы данных при резервном копировании средствами VMbitrix — размещается в директории /home/bitrix/ в виде двух файлов — с окончанием *.sql и *_after_connect.sql.
Так же данные файлы находятся в самом архиве в директории /home/bitrix/ — от корня архива, при необходимости их можно извлечь от туда.

Если база данных не нарушена — для восстановления достаточно дать команду на восстановление из файла *_after_connect.sql:
mysql sitemanager
< home/bitrix/mysql_dump_sitemanager_15.04.2019_8akRLwVX_after_connect.sql

При необходимости полного восстановления базы данных необходимо последовательно дать команду на восстановление двух фалов:
mysql sitemanager < home/bitrix/mysql_dump_sitemanager_15.04.2019_8akRLwVX.sql
mysql sitemanager < home/bitrix/mysql_dump_sitemanager_15.04.2019_8akRLwVX_after_connect.sql

5. При необходимости развернуть резервную копию на другом сервере, с установленным Веб окружением потребуется изменить пароль для пользователя базы. Для одного сайта в Битрикс веб окружением создастся база данных — sitemanager, с пользователем bitrix0.
Пароль для пользователя bitrix0 при установке веб окружения генерируется автоматически, и соответственно не будет совпадать со старым паролем в конфигурационных файлах Битрикс. Посмотреть старый пароль можно в конфигурационных фалах Битрикс:
/home/bitrix/www/bitrix/.settings.php или /home/bitrix/www/bitrix/php_interface/dbconn.php

Приступая к животрепещущей теме резервного копирования на «Битрикс», прежде всего хотелось бы поблагодарить разработчиков, реализовавших автоматическое резервное копирование в облачное хранилище в версии 12.0.8 и более поздних. В ранних версиях эта возможность не предусматривалась и резервное копирование сайта требовало непосредственного управления администратора или же довольно сложных ухищрений для автоматизации процесса своими силами. Мы обязательно вернемся к этому замечательному функционалу в будущем, а сейчас обсудим некоторые детали восстановления резервной копии сайта.

1. Совместимость формата *.tar.gz

Формат архива резервной копии *.tar.gz предназначен для распаковки файлом restore.php и корректно распаковывается только с его помощью. Распаковывать другими архиваторами целесообразно только для познавательных нужд или получения отдельных файлов скриптов и изображений, по какой-то причине утерянных. Делать собственные сборки и модификации резервной копии при помощи архиваторов rar, zip, 7z нецелесообразно, такой архив не будет распакован файлом restore.php.

2. Пошаговое восстановление резервной копии

А) Подготовьте окружение и архив

Б) Запустите восстановление

В) Действия на Первом шаге

Restore – перейдите ко Второму шагу

Г) Действия на Втором шаге

——————————-
Спасибо за внимание!
Читайте свежий выпуск «Кладовки программиста» каждый день!

Назад в раздел

Резервная копия сайта — это подушка безопасности, которая необходима любому проекту. В случае любого форс-мажора, внутреннего или внешнего, она позволяет мгновенно вернуться к рабочей версии проекта. И это касается не только взлома, внешней атаки на сайт или случайного заражения вирусом, но и неправильного обновления ПО, сбоев в работе системы или ошибки администратора. Сохраненный на всякий случай бэкап станет для вас спасением даже в случае, если проект мгновенно лишится инфраструктуры.

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

Как устроена резервная копия сайта

Ваш проект со всеми настройками, базами данных и административными ресурсами хранится либо на вашей собственной инфраструктуре, либо на серверах у вашего хостера. В обоих случаях нужно подумать о том, чтобы бэкап не пропал вместе с основной системой. Если у вас своя серверная, то для хранения резерва лучше воспользоваться услугами облачного провайдера. Если же вы хоститесь у проверенного хостера, то поинтересуйтесь у него услугой облачного бэкапа. Если он её предлагает, то у него проблема распределённого хранения бэкапа уже решена. Впрочем, воспользовавшись его услугами вы можете сохранять резерв куда-нибудь ещё: на отдельный компьютер или жёсткий диск, в файлообменник или на запасной сервер. Создание 2-3 бэкапов одновременно означает высший уровень защиты.

Однако это и увеличит количество мороки с резервными копиями. Хранить ведь нужно не один бэкап, а, скажем, все бэкапы за месяц. Многие вирусы работают не сразу, и после заражение может пройти несколько дней или даже 1-2 недели. Какой тогда будет смысл в бэкапе, если самая ранняя копия проекта уже будет содержать вирус?

Все наши клиенты, например, по умолчанию получают обязательные еженедельные бэкапы, а при подключении услуги BaaS получают также объёмное хранилище с шифрованием и дедупликацией данных. А вот постоянное создание бэкапа со своей стороны будет иметь смысл только в случае, если в вашей организации есть кому этим заниматься и достаточно экспертизы, чтобы автоматизировать процесс — иначе возможны очень неприятные ошибки.

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

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

• Бэкап сайта должен происходить ежедневно.
• Вам понадобится архив бэкапов глубиной в один месяц.
• Отдельно лучше создать дополнительный архив глубиной в квартал, в котором будут храниться недельные копии, а также по ещё одной копии на месяц за весь последний год.
   

Эти правила звучат по крайней мере разорительно, но на самом деле большинство проектов не так много весят, и вам хватит 300-500 гигабайтов на хранение вообще всего. В случае если перестраховка вам не близка, то можете игнорировать описанное выше и просто записывайте бэкапы на неделю и храните еженедельный архив за месяц — это будет лучше, чем ничего.

Обратите внимание! Всегда делайте внеплановую резервную копию сайта перед обновлением системы. Например, если вы решите обновить 1С Битрикс, то резервную копию сделайте сразу перед обновлением.

Несколько самых распространённых ошибок резервного копирования

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

Самая частая – сохранение бэкапа без проверки. Существование резервной копии ещё не гарантирует, что из неё можно будет восстановить сайт! Создание бэкапа, как правило, достаточно долгий процесс, и усложнять его дополнительным временем на проверку никто не хочет. Но это необходимо! Если в самый нужный момент бэкап окажется повреждённым, то вина ляжет на плечи нерадивого бэкапера.

Не реже бывает такое, что при ручном создании бэкапов для них не остаётся достаточно места. Создание резервной копии оканчивается ошибкой, его придётся делать заново — или пропустить, увеличив возможность потерять критически важные данные.

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

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

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

Восстановление по SSH-доступу — приём для опытных пользователей и системных администраторов, он подразумевает умение работать в командной строке. Как правило, он и не нужен – панели или FTP-клиента достаточно, но иногда и такая необходимость может возникнуть. В Windows подключитесь к серверу с помощью утилиты Putty, а в Mac’е используйте для этого программу «Терминал», после чего можно использовать те же команды, что и для Windows. Чтобы открыть файловый менеджер, введите команду mc, в его левой панели найдите резервную копию, а в правой (между вкладками можно переключаться на Tab) — папку сайта doc. Переименуем последнюю в doc_old (зажмите Shift и F6, в открывшемся окошке введите новое название и щелкайте ОК).

Чтобы переместить резерв на сервер, используйте F6 для перемещения либо F5 для копирования.

Выводы

Резервная копия сайта — это обязательная мера безопасности любого онлайн-проекта независимо от его размера. Если у вас есть собственная инфраструктура, то неплохо иметь бэкап на сторонней (например, у надёжного облачного хостера), а если вы работаете в облаке, то обязательно проверьте, предоставляет ли ваш провайдер услугу BaaS. По возможности заведите дополнительный архив для бэкапов, но с надёжным хостером это не обязательно.