Бесплатная консультация юриста

+7 (800) 301-07-30

Реклама jurik.ru

При работе с системой управления сайтом 1С-Битрикс администраторы часто сталкиваются с ошибкой при попытке восстановления резервной копии через скрипт restore.php:

Доступны не все части многотомного архива. Общее число частей: 29 (или 4, 3, 78 и т.д.)

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

Понимание структуры многотомного бэкапа Bitrix

При создании резервной копии большого объема Битрикс автоматически разбивает её на части (тома), если размер превышает лимиты настроек PHP (upload_max_filesize, post_max_size) или настройки самого модуля резервного копирования.

Номенклатура файлов

Обычно набор файлов выглядит так:

YYYYMMDD_HHMMSS_full_xxxxxxxx.tar.gz — первая часть (или манифест/индекс).
YYYYMMDD_HHMMSS_full_xxxxxxxx.tar.gz.1, .2, .3 … .28, последующие тома.

Важно: Общее число частей в сообщении об ошибке (в вашем случае 29) включает в себя первый файл (без расширения номера или с номером 0/1) плюс 28 последующих файлов с расширениями .1 – .28.

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

Не все файлы загружены на сервер (Самая частая причина)

При переносе бэкапа по FTP/SFTP/SCP или через файловый менеджер хостинга:

Могли не загрузиться «хвостовые» части (например, с 20 по 28), если соединение прервалось.
Файловый менеджер хостинга мог не показать скрытые файлы или обрезать список.
При скачивании из облака (Яндекс.Диск, Google Drive, Б24.Облако) могли скачаться не все части (как в примере из интернета: «в админке пишет 20 частей, а нужно 78»).

Неверное именование файлов

Скрипт restore.php строго ожидает определенную маску именования. Если вы переименовывали файлы вручную (убирали дату, меняли расширения), скрипт их не найдет.

Проверьте регистр букв (на Linux .tar.gz.1 и .tar.gz.1 — разные файлы, хотя обычно расширения в нижнем регистре).
Проверьте, нет ли лишних пробелов или символов (1), _copy в конце имен.

Файлы разбросаны по разным папкам

Все части многотомного архива обязательно должны находиться в одной директории (обычно это корень сайта или папка /bitrix/backup/). Если часть лежит в корне, а часть в /upload/, восстановление не начнется.

Повреждение или нулевой размер одной из частей

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

Особенности скачивания из «Облака Битрикс24»

Если бэкап создавался в облачной версии Битрикс24 и скачивается через админку или API:

Иногда веб-интерфейс показывает неверное количество файлов.
Рекомендуется скачивать через официальный десктопный клиент «Битрикс24.Синхронизация» или по WebDAV, чтобы гарантированно получить все 29 частей.

Пошаговая диагностика и решение

Шаг 1. Инвентаризация файлов (Критически важно)

Подключитесь к серверу по SSH (или посмотрите через файловый менеджер) и выполните в папке с бэкапом:

ls -la full | wc -l
ls -la full | sort -V

Ожидаемый результат: Вы должны увидеть ровно 29 файлов.

Пример правильного набора для 29 частей:

20240101_120000_full_a1b2c3d4.tar.gz (часто это 1-я часть)
20240101_120000_full_a1b2c3d4.tar.gz.1
20240101_120000_full_a1b2c3d4.tar.gz.2
…
20240101_120000_full_a1b2c3d4.tar.gz.28 (последняя, 29-я часть)

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

Шаг 2. Проверка целостности (Контрольные суммы)

Если файлов 29, но ошибка остается, проверьте их размеры и хеши. На исходном сервере (где делался бэкап) выполните:

md5sum full > checksums.md5

Перенесите этот файл checksums.md5 на целевой сервер и проверьте:

md5sum -c checksums.md5

Любые ошибки FAILED указывают на повреждение конкретного тома при передаче. Его нужно перезалить.

Шаг 3. Проверка прав доступа и владельца

Скрипт restore.php запускается от имени пользователя веб-сервера (обычно bitrix, www-data, apache или nginx). Файлы бэкапа должны быть читаемы этим пользователем:

chown -R bitrix:bitrix /path/to/site/root/.tar.gz
chmod 644 /path/to/site/root/.tar.gz

Шаг 4. Ручная сборка архива (Альтернативный метод «Хирургия»)

Если restore.php капризничает, но все 29 частей на месте и целы, можно собрать единый архив вручную через консоль (SSH) и распаковать его, а затем запустить restore.php на уже распакованных файлах (указав путь к папке с файлами, а не к архиву).

Для Linux (bash):

# 1. Собираем единый tar.gz (cat сохраняет порядок частей)
cat 20240101_120000_full_a1b2c3d4.tar.gz 20240101_120000_full_a1b2c3d4.tar.gz.{1..28} > full_backup.tar.gz

tar -xzvf full_backup.tar.gz

Для Windows (PowerShell):
# Сборка
Get-ChildItem -Filter "full_a1b2c3d4.tar.gz" | Sort-Object Name | ForEach-Object { Get-Content $_ -Raw } | Set-Content "full_backup.tar;gz" -Encoding Byte

tar -xzvf full_backup.tar.gz
  Внимание: При ручной сборке критически важно соблюдать порядок склеивания файлов (по алфавиту/нумерации). Первым всегда идет файл без номера или с .0/.1, последним — с максимальным номером (.28 для 29 частей).
 
 Специфические сценарии из практики
 Сценарий: «Видит только одну часть»
 Вы кладете файлы в корень, а restore.php пишет, что видит 1 часть из 29.
  Причина: Вы положили только файл ...tar.gz (первую часть), а файлы ...tar.gz.1 ... ...tar.gz.28 лежат в другой папке или не загружены.
 Лечение: Соберите все 29 файлов в одной папке.
 
 Сценарий: «В облаке 20 частей, а нужно 78 (или 29)»
 Это классическая проблема облачного бэкапа Битрикс24.
  Причина: Веб-интерфейс облака или API отдает неполный список файлов (пагинация, баг индексатора).
 Лечение: Используйте WebDAV клиент (WinSCP, Cyberduck, RaiDrive, «Битрикс24.Синхронизация») для монтирования облака как сетевого диска и копируйте файлы оттуда. Только так гарантированно скачаются все тома.
 
 Сценарий: Ошибка на этапе «Проверка архива» после нажатия «Далее»
 Если скрипт нашел 29 частей, но при проверке выдает ошибку CRC или «Unexpected end of archive»:
  Одна из частей (часто последняя, .28) загрузилась не полностью (обрыв связи).
 Сравните размер последней части с эталоном на источнике. Если она меньше — перезалейте.
 
 Профилактика на будущее
  Настройте размер тома в настройках бэкапа. В настройках модуля «Резервное копирование» (Настройки -> Настройки продукта -> Резервное копирование) можно увеличить «Максимальный размер файла бэкапа» (например, до 2048 Мб или 5120 Мб), если позволяет хостинг. Это уменьшит число частей с 29 до 3-5, снижая риск потери.
 Используйте rsync/scp для переноса. Они поддерживают докачку и контроль целостности — rsync -avzP source/ user@server:/path/.
 Проверяйте бэкап сразу после создания. Скрипт restore.php имеет режим «Только проверка» (Test backup). Запускайте его на продакшене раз в месяц.
 Храните контрольные суммы. При создании бэкапа генерируйте md5sum или sha256sum для всех частей и кладите файл сумм в ту же папку.
  Резюме: Чек-лист для ошибки «Общее число частей: 29»
    Проверка  Действие  
 
   Количество файлов  В папке должно быть ровно 29 файлов с одинаковым префиксом имени.  
  Нумерация  Файлы: name.tar.gz (или .0), .1, .2 ... .28. Без пропусков.  
  Размер последней части  Не должен быть 0 байт. Сравните с оригиналом.  
  Папка  Все 29 файлов в одной директории (корень сайта или /bitrix/backup).  
  Права доступа  Владелец — пользователь сайта (bitrix/www-data), права 644.  
  Источник (Облако)  Скачивайте через WebDAV/Клиент синхронизации, а не через веб-морду.  
  Альтернатива  Склейте вручную через cat (Linux) / Get-Content -Encoding Byte (PS) и распакуйте tar -xzvf.  
 
 
 Следуя этому алгоритму, вы с высокой вероятностью решите проблему с нехваткой частей многотомного архива и успешно восстановите сайт; Если после всех проверок файлов на месте 29 штук, они целые, права выданы, а restore.php всё равно ошибается, попробуйте метод ручной сборки архива через консоль, он наиболее надежен для больших объемов.