Где 1С-Битрикс хранит резервные копии и как их найти

Резервная копия в 1С-Битрикс — это не один файл, а набор архивов, которые система раскладывает по разным местам в зависимости от настроек. Администратор, впервые столкнувшийся с восстановлением сайта, часто не может найти бэкап просто потому, что ищет не в том каталоге: копия может лежать в стандартной папке сайта, в произвольной директории на сервере, в облачном хранилище «1С-Битрикс» или на стороннем сервисе вроде Яндекс.Диска.

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

Стандартное расположение: папка /bitrix/backup/

При создании резервной копии штатными средствами системы файлы по умолчанию сохраняются в каталог /bitrix/backup/ относительно корня сайта. Если сайт установлен, например, в /var/www/html, полный путь будет /var/www/html/bitrix/backup/. Внутри лежат архивы с расширением .tar.gz и именами вида backup_2026_full_....tar.gz, а при большом объёме — многотомные архивы с суффиксами .1, .2 и так далее.

Кроме архива в этой папке могут находиться служебные файлы: дамп базы данных .sql (если копирование выполнялось с раздельным сохранением), файлы журнала и временные файлы, оставшиеся после прерванного процесса. Временные файлы большого размера — признак того, что создание копии оборвалось, и такой архив для восстановления непригоден.

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

Самый быстрый способ узнать, где лежат копии и существуют ли они вообще, — открыть в административной панели раздел «Настройки → Инструменты → Резервное копирование → Список резервных копий». Таблица показывает имя файла, размер, дату создания и место хранения: локально или в облаке. Отсюда же можно скачать архив, восстановить сайт или удалить устаревшую копию.

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

1. 1
   Авторизуйтесь в административном разделе с правами главного администратора
2. 2
   Перейдите: Настройки → Инструменты → Резервное копирование
3. 3
   Откройте вкладку «Список резервных копий» и проверьте колонку с расположением
4. 4
   Для локальной копии нажмите «Скачать» или подключитесь к серверу и проверьте /bitrix/backup/
5. 5
   Для облачной копии проверьте срок хранения и доступность лицензионного ключа

Нестандартные пути хранения на сервере

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

Если сервер администрировал кто-то до вас и документации нет, найти архивы помогает поиск по файловой системе. Подключитесь по SSH и выполните поиск по характерным именам файлов.

find / -name "backup_*.tar.gz*" -type f 2>/dev/null | head -50

Дополнительно проверьте задания планировщика: crontab -l для пользователей системы и содержимое /etc/cron.d/. Если бэкап делался сторонним скриптом (например, через mysqldump и tar напрямую), путь к результату будет указан именно в таком скрипте, а не в настройках Битрикса.

Облачное хранилище 1С-Битрикс и внешние сервисы

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

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

Как проверить целостность и пригодность копии

Наличие файла в папке ещё не означает, что из него можно восстановиться. Минимальная проверка — попытаться открыть архив: tar -tzf имя_файла.tar.gz должен вывести список содержимого без ошибок. Для многотомных архивов проверяйте все части, их количество должно соответствовать нумерации.

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

Типичные ошибки и риски

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

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

FAQ