Что умеет решение
Модуль автоматически отправляет штатные резервные копии 1С-Битрикс во внешние хранилища: Яндекс.Диск, Google Диск, S3-совместимые системы, а также FTP, FTPS и SFTP. Каждая передача проходит проверку целостности. Старые копии удаляются по заданным правилам, а любую резервную копию можно восстановить на сервере одной кнопкой.
Копия, хранящаяся только на том же хостинге, что и сайт, будет безвозвратно утеряна при сбое диска, взломе, блокировке аккаунта или ошибке хостинг-провайдера. Модуль решает эту проблему, размещая копии в удалённых хранилищах и гарантируя их успешную доставку.
Принцип работы
Настройка резервного копирования Битрикса выполняется стандартным способом: по расписанию или вручную.
Модуль отслеживает появление новых копий. О автоматических бэкапах он узнаёт от ядра Битрикса, а ручные копии определяет по моменту остановки изменения файлов.
Копия помещается в очередь и отправляется во все подключённые хранилища. При разрыве соединения передача возобновляется с того места, где она прервалась.
После завершения передачи модуль сверяет каждый том с оригиналом, удаляет устаревшие копии по правилам хранения и, при включённой опции, освобождает место на сайте.
Особенности хранилищ
Яндекс.Диск: доступ предоставляется только к папке приложения.
Google Диск: доступ предоставляется только к файлам, созданным модулем.
Модуль поддерживает загрузку резервных копий в облачные хранилища, совместимые с протоколом S3, включая Beget, Yandex Object Storage, Selectel, VK Cloud, Timeweb Cloud, Amazon S3, MinIO и другие сервисы. Также доступны протоколы FTP и FTPS с обязательной проверкой сертификатов, а также SFTP (SSH) с верификацией ключа сервера.
Возможно одновременное подключение нескольких хранилищ разных типов. При запуске через cron-задачу загрузка происходит параллельно: медленное хранилище не блокирует передачу данных в другие.
Для контроля целостности каждый том сверяется с оригиналом. В Яндекс.Диске и Google Диске используется проверка контрольных сумм SHA-256 или MD5, в S3 — MD5 каждой части и итоговая сумма. Для FTP и SFTP, где серверы не предоставляют контрольные суммы, сверяется размер файла.
Рядом с каждой копией создается файл с расширением .sha256. Его можно использовать для проверки целостности скачанной копии командой sha256sum -c даже без доступа к исходному сайту.
Файлы загружаются под временным именем и переименовываются в хранилище только после полного завершения передачи. Под финальным именем в облаке никогда не оказывается незавершенный файл.
При неудачной попытке передачи модуль использует надежную очередь с нарастающей задержкой. Если ошибка связана с авторизацией или нехваткой места, пауза составляет не менее часа, чтобы избежать перегрузки сервиса.
Большие резервные копии передаются частями с возможностью возобновления прерванной передачи. Интеграция с Яндекс.Диском, Google Диском, S3, FTP и SFTP работает как через агентов Битрикс, так и через планировщик cron, который обеспечивает более высокую скорость и рекомендуется к использованию.
Если хранилище не успевает принимать данные, модуль отправит предупреждение. Новая копия в очереди заменит более старые резервные копии, которые ещё не начали передачу.
Все действия модуля фиксируются в «Истории операций»: фиксируется объём переданных данных, адрес назначения, метод проверки и причины возникновения ошибок.
Правила хранения
Для каждого хранилища настраиваются критерии сохранения резервных копий:
- количество последних N копий;
- одна копия за день, неделю или месяц;
- копии, созданные менее N дней назад;
- общий объём не более N ГБ;
- минимальное количество N копий, сохраняемое при любых других правилах.
Правила применяются раздельно к полным копиям и к копиям только базы данных. Частые обновления базы данных не вытесняют полные резервные копии.
Важную копию можно закрепить, чтобы ни одно правило не удалило её. Самая свежая проверенная копия каждого типа также защищена от удаления.
При включении опции «Освобождать место» модуль автоматически удаляет самую старую копию, разрешённую правилами, при переполнении хранилища, и инициирует повторную передачу данных.
Модуль позволяет настраивать отправку резервных копий в облачные хранилища: Яндекс.Диск, Google Диск, S3, FTP и SFTP. Можно выбрать частоту передачи: каждую копию, не чаще одного раза в сутки или не чаще одного раза в неделю. Например, ежечасные снимки можно хранить на быстром S3, а на Яндекс.Диск отправлять только одну копию в день.
Освобождение места на хостинге
При включении этой опции копия удаляется с сервера после того, как все подключенные хранилища подтвердят её получение и проверку. Перед удалением модуль повторно проверяет наличие файлов в облаке. При необходимости можно оставить на сервере несколько последних копий для ускоренного восстановления.
Восстановление данных
Восстановление копии на сервере выполняется одной кнопкой. Модуль скачивает данные из хранилища в директорию /bitrix/backup/, проверяет каждый том и добавляет копию в стандартный список резервных копий Битрикс для штатного восстановления.
Для восстановления на новом сервере к каждой копии прилагается пошаговая инструкция. Для протоколов FTP, SFTP и S3 в ней содержится команда, позволяющая скачать все тома одной строкой.
Если сайт был восстановлен из старой копии или перенесен на чистый сервер, модуль автоматически находит в хранилищах снимки этого сайта по его уникальному идентификатору и возвращает их в список. Копии других сайтов, находящихся в той же папке, модуль не затрагивает.
Безопасность
Пароли, ключи доступа и токены хранятся в базе данных в зашифрованном виде с использованием алгоритма AES-256-GCM. Ключ шифрования расположен в отдельном файле, а не в базе данных. В журналах событий конфиденциальные данные скрываются.
Модуль обеспечивает загрузку резервных копий в облачные хранилища: Яндекс.Диск, Google Диск, S3, а также на FTP и SFTP-серверы. При работе с облачными дисками предоставляется минимальный набор прав: модуль может только загружать файлы, но не имеет возможности читать или удалять другие данные на диске.
Для безопасной передачи данных FTPS по умолчанию проверяет сертификат сервера. SFTP запоминает ключ сервера и прерывает передачу, если ключ изменился, чтобы предотвратить утечку пароля на подменённый сервер. Модуль удаляет только те файлы, которые были загружены им самим. Подключение двух разных хранилищ к одной папке невозможно.
Все операции в административной панели защищены проверкой сессии и прав доступа. Подключать и удалять хранилища может только администратор сайта. Модуль корректно работает с зашифрованными копиями Битрикса, передавая их без изменений; пароль от архива не требуется.
Важно понимать ограничения функционала. Модуль не создаёт резервные копии самостоятельно — эту задачу выполняет штатное резервное копирование Битрикса через раздел «Настройки → Инструменты → Резервное копирование». Также модуль не выполняет восстановление сайта напрямую — эту функцию выполняет стандартный скрипт restore.php. Задача модуля — вернуть копию на сервер и предоставить пошаговую инструкцию по восстановлению.
Статус «передана» означает, что файлы успешно дошли до хранилища в полном объёме и без искажений. Целостность архива проверяется на этапе его создания (опция Битрикса «Проверить целостность архива») и в ходе пробного восстановления.
Модуль требует PHP 8.2 или новее, главный модуль 24.0 или новее, кодировку UTF-8 и базу данных MySQL. Необходимы расширения PHP: curl, openssl (с поддержкой шифрования AES-256-GCM), json и hash. Для работы с протоколом SFTP требуется версия curl с поддержкой SFTP (библиотека libssh2), что доступно на большинстве хостингов; модуль автоматически проверяет эту возможность.
Использование планировщика задач (cron) настоятельно рекомендуется. Для Яндекс.Диска настройка cron обязательна, так как сервис принимает файлы только одним запросом без возможности докачки. Сам модуль не создает резервные копии; их генерирует штатное средство резервного копирования Битрикса (раздел «Настройки → Инструменты → Резервное копирование») в автоматическом или ручном режиме. Модуль лишь берет готовые архивы и передает их в облачные хранилища.
Без cron модуль выполняет передачу через агенты Битрикса короткими шагами, что подходит для Google Диска, S3, FTP и SFTP. Однако для Яндекс.Диска передача возможна исключительно из cron, так как агенты не могут обеспечить одномоментную отправку файла. Команда для настройки cron отображается в параметрах модуля. Если резервная копия создана вручную, ее передача может занимать длительное время.
Модуль не получает от ядра 1С-Битрикс уведомлений о завершении ручного создания резервной копии. В этом случае система ожидает, пока файлы копии перестанут изменяться; стандартный тайм-аут составляет 10 минут. Если вы уверены, что процесс создания копии завершен, нажмите кнопку «Копия завершена — взять сейчас» на странице «Резервные копии». Автоматические копии ядро подтверждает самостоятельно, и они передаются в хранилище немедленно.
Статус «передана» означает, что файлы полностью дошли до хранилища и совпали с оригиналом. Для Яндекс.Диска, Google Диска и S3 модуль сверяет контрольную сумму файла, которую предоставляет облачный сервис. Для протоколов FTP и SFTP контрольная сумма недоступна, поэтому там используется проверка по размеру файлов. Полную проверку целостности в любом хранилище обеспечивает файл .sha256, расположенный рядом с копией.
Можно ли удалять копии с хостинга после успешной передачи?
Да. Для этого включите опцию «Удалять копию с сайта после передачи». Удаление произойдет только после того, как все подключенные хранилища подтвердят прием и проверку данных. Перед удалением модуль повторно находит файлы копии в хранилище. На сайте можно оставить несколько последних копий.
Если вы также сохраняете копии в облако «1С-Битрикс», важно учитывать особенности синхронизации и проверки целостности данных в этой системе.
В настройках резервного копирования Битрикса не включайте опцию «Удалять локальные резервные копии после успешной передачи в облако». Эта функция удалит файл до того, как модуль успеет загрузить его во все указанные хранилища. Вместо этого настройте автоматическое удаление локальных файлов непосредственно в параметрах данного модуля.
Если место в облачном хранилище закончится, загрузка прервется с ошибкой о нехватке места. Модуль будет пытаться повторить передачу с интервалом не менее одного часа. Чтобы избежать таких задержек, настройте правила хранения. Также можно активировать функцию «Освобождать место для новой копии»: в этом случае модуль автоматически удалит самую старую копию, которую допускают установленные правила. При этом закрепленные копии и самая свежая копия каждого типа никогда не будут удалены.
Передача копий на Яндекс.Диск может происходить медленно из-за ограничений скорости приема файлов со стороны сервиса. С хостинга скорость часто составляет от 150 до 200 КБ/с, поэтому загрузка копии объемом 600 МБ может занять около часа. Если частота создания резервных копий превышает скорость приема, модуль выдаст предупреждение и будет передавать только самую свежую копию, игнорируя очередь старых файлов. Для частого создания резервных копий рекомендуется настроить передачу на Яндекс.Диск одной копии в сутки через параметр «Какие копии передавать», а остальные хранить в хранилище S3.
Процесс восстановления сайта описан в соответствующей документации.
Для восстановления откройте страницу «Резервные копии» и выберите раздел «Как восстановить». Если нужная копия отсутствует на сервере, нажмите кнопку для её возврата из облачного хранилища. После этого файл появится в списке Битрикса и будет доступен для стандартного восстановления. Для новых серверов на этой же странице размещена пошаговая инструкция с командами для скачивания архивов.
Если вы восстановили сайт из старой копии, модуль не потеряет информацию о новых бэкапах. Он автоматически проверяет хранилища раз в сутки или по нажатию кнопки «Сверить с хранилищами», находя копии своего сайта по уникальному идентификатору и добавляя их в список. Файлы, которые уже находятся в хранилище, повторно не загружаются.
Можно ли хранить бэкапы нескольких сайтов в одном хранилище? Да, при этом для каждого сайта должен быть выделен отдельный каталог (по умолчанию используется путь bitrix-backup/домен). Модуль удаляет только файлы, созданные им самим, и не воспринимает чужие копии как свои.
Модуль не видит остальные файлы на Яндекс.Диске или Google Диске. На Яндекс.Диске доступ ограничен только папкой приложения, а на Google Диске — только файлами, созданными этим модулем. Это техническое ограничение самих сервисов, а не функциональная особенность модуля.
Пароли и ключи доступа к хранилищам хранятся в защищённом виде внутри системы управления сайтом.
Данные сайта хранятся в базе в зашифрованном виде с использованием алгоритма AES-256-GCM. Ключ шифрования размещается в отдельном файле в директории /bitrix/php_interface. При переносе только базы данных без этого файла модуль запросит повторный ввод паролей для всех подключенных хранилищ.
Модуль корректно обрабатывает зашифрованные копии системы Битрикс, передавая их без изменений. Пароль от архива модулю не требуется и не хранится; его необходимо ввести вручную в файле restore.php в процессе восстановления.
При подключении через SFTP может возникнуть ошибка «ключ сервера не совпадает». Это означает, что сервер предъявил ключ, отличный от того, который был сохранен при первом подключении. Подобная ситуация типична после переезда или переустановки сервера, однако также может указывать на попытку подмены. Передача данных приостанавливается до подтверждения пароля. Рекомендуется уточнить ситуацию у хостинг-провайдера. Если смена ключа ожидаема, новый отпечаток ключа следует ввести в поле «Отпечаток ключа сервера».
General iT может взять на себя внедрение «Бэкап в облако: Яндекс.Диск, Google Диск, S3, FTP, SFTP», включая установку, настройку и проверку результата.