Инструкции по восстановлению нет: разворачиваем чужой бэкап вслепую

MAATRIX

У вас есть файл — 40 гигабайт, называется backup_2026.tar.gz, и больше вы о нём ничего не знаете. Никакого README, никакого письма от прежнего админа с инструкцией «сначала разворачиваем это, потом накатываем то». Просто архив, который лежит на диске или в S3-бакете, и задача — поднять из него рабочий сервис, желательно до того, как кто-то наверху спросит, почему сайт всё ещё не работает. Разворачивать бэкап вслепую — это не про «распаковать и запустить», а про методичное опознание того, что перед вами, и проверку каждого шага в среде, где ошибка ничего не стоит. Если вы вообще ещё не решили, с чего начинать разбор доставшегося вам сервера, есть смысл сначала прочитать методологию обследования незнакомой машины — здесь же разбираем конкретно сам процесс восстановления из бэкапа.

Сначала — не трогайте прод

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

Причины конкретные:

• Незнакомый дамп базы может содержать команды DROP DATABASE или --clean в начале файла — накатите его поверх существующей базы, и вы потеряете то немногое, что ещё работало.
• Архив файлов может распаковаться с правами и владельцем, которые не совпадают с текущими — и то, что работало, перестанет запускаться из-за Permission denied.
• Снапшот диска или контейнера может тянуть за собой конфиги с чужими путями, портами и секретами, которые начнут конфликтовать с тем, что уже поднято.

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

Определяем, что вообще внутри

Прежде чем запускать любую команду восстановления, нужно понять: перед вами дамп базы данных, архив файловой системы, снапшот диска/образа или бэкап конкретного приложения (с собственным форматом, как у Borg, Restic или Duplicati). Это определяет весь дальнейший план, и угадать по расширению файла получается не всегда.

Первый шаг — посмотреть на файл, не распаковывая:

file backup_2026.tar.gz
# gzip compressed data, from Unix, original size modulo 2^32 12884901888

tar -tzvf backup_2026.tar.gz | head -50

Список файлов внутри архива обычно сразу выдаёт тип бэкапа:

• Файлы вида *.sql, *.sql.gz, *.dump — текстовый или бинарный дамп базы данных (pg_dump, mysqldump).
• Структура var/lib/postgresql/... или var/lib/mysql/... целиком — это не логический дамп, а физическая копия каталога данных СУБД, восстанавливается совсем иначе.
• Обычная файловая структура (etc/, home/, var/www/) — архив файловой системы или её части.
• Файлы .vmdk, .qcow2, .raw, .img — образ диска или снапшот виртуальной машины (разница между образом целиком и бэкапом отдельных файлов — тема отдельного разбора о выборе формата для виртуалок, если вы ещё не определились, как будете бэкапить дальше уже сами).
• Каталоги с именами-хешами и файлом index или manifest — это, скорее всего, репозиторий специализированного инструмента бэкапов (Borg, Restic, Kopia), и распаковывать его вручную бессмысленно — нужен именно этот инструмент.

Если файл — бинарный дамп СУБД, полезно посмотреть заголовок:

head -c 200 backup_2026.dump | strings | head -5
# PostgreSQL custom database dump всегда начинается с сигнатуры PGDMP

Для дампов PostgreSQL в формате custom (pg_dump -Fc) сигнатура PGDMP в первых байтах — надёжный признак. Для MySQL текстовый дамп обычно начинается с комментариев -- MySQL dump и указания версии сервера, из которого он снят — это первая зацепка для следующего шага.

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

Ищем версию ПО, для которого сделан бэкап

Восстановление дампа от одной версии СУБД на другой — источник половины проблем при работе с чужими бэкапами. PostgreSQL и MySQL меняют внутренний формат данных, системные каталоги и иногда синтаксис между мажорными версиями, и дамп, снятый pg_dump 14-й версии, не всегда без проблем ложится в кластер 17-й — а физическая копия каталога данных (не логический дамп) между разными мажорными версиями не совместима вообще.

Что смотреть, чтобы определить версию:

# В текстовом дампе MySQL версия обычно есть прямо в шапке файла
zcat backup.sql.gz | head -20 | grep -i "server version\|mysql dump"

# В дампе PostgreSQL (custom format) версию покажет сам pg_restore
pg_restore -l backup.dump | head -5

# Если рядом есть любые конфиги или логи — версия ПО часто там же
find . -iname "*.conf" -o -iname "*.yml" -o -iname "*.env" | xargs grep -il "version" 2>/dev/null

Если версию нигде найти не удаётся, практичный путь — поднять последнюю доступную стабильную версию СУБД в тестовой среде и попробовать восстановление там. Логические дампы (pg_dump, mysqldump) в большинстве случаев накатываются на более новую версию без проблем — разработчики целенаправленно держат обратную совместимость дамп-формата. А вот попытка поднять физическую копию каталога данных на другой мажорной версии почти всегда заканчивается отказом сервера стартовать — тут версии должны совпадать точно, и если бэкап именно такой, придётся искать нужную версию СУБД отдельно (в Debian/Ubuntu — через архивные репозитории или собранный вручную пакет).

То же самое касается версии самого приложения, если бэкап — это данные какого-то сервиса (CMS, трекер, панель управления). Схема базы данных на диске привязана к версии приложения, которое её создало: миграции применяются последовательно, и попытка запустить свежую версию приложения поверх бэкапа данных пятилетней давности почти гарантированно упадёт на middleware, который ожидает столбец, ещё не добавленный в старой схеме.

Пробное восстановление в изоляции

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

Порядок для дампа базы данных:

# PostgreSQL: создаём чистую тестовую базу, ничего не трогаем в существующих
createdb -O testuser test_restore
pg_restore -d test_restore --no-owner --no-privileges backup.dump

# MySQL/MariaDB: аналогично — отдельная тестовая база
mysql -u root -p -e "CREATE DATABASE test_restore CHARACTER SET utf8mb4;"
mysql -u root -p test_restore < backup.sql

Флаг --no-owner --no-privileges для pg_restore намеренно убирает из дампа привязку к ролям и правам оригинального сервера — на чужом бэкапе эти роли почти наверняка не совпадают с вашими, и без флага восстановление будет падать на каждой команде ALTER OWNER.

Для файлового архива — распаковка во временный каталог с проверкой прав:

mkdir /tmp/restore_test
tar -xzf backup_2026.tar.gz -C /tmp/restore_test
ls -la /tmp/restore_test   # смотрим владельца и права файлов до переноса

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

# qcow2-образ можно смонтировать через qemu-nbd, не запуская всю виртуалку
modprobe nbd
qemu-nbd --connect=/dev/nbd0 backup.qcow2
mount /dev/nbd0p1 /mnt/restore_test

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

Типичные ловушки

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

Несовпадение версий ПО. Уже разобрано выше отдельно, но стоит повторить: это причина номер один для отказов при восстановлении, особенно для физических копий данных СУБД. Если возможности определить версию нет — начинайте с последней стабильной, логические дампы почти всегда накатываются на неё без ошибок.

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

# Для Node.js/Python-приложений часто помогает грубый grep по исходникам
grep -rn "process.env\.\|os.environ\[" . --include="*.js" --include="*.py" | \
  grep -oP "(?:env\.|environ\[.)\K[A-Z_]+" | sort -u

Список найденных переменных — это чек-лист того, что придётся восстановить или подобрать заново: строки подключения к базе, ключи API внешних сервисов, секреты для подписи сессий. Часть из них можно взять из самого бэкапа (если в архиве случайно оказался старый .env.example или конфиг с реальными значениями), часть придётся выпускать заново — и это нормально, если сервис умеет работать с новыми ключами без потери данных.

Права доступа и владелец файлов. Архив, распакованный от root, отдаёт файлам владельца root:root, даже если исходно ими владел www-data или системный пользователь конкретного приложения. Сервис стартует под непривилегированным пользователем и упирается в Permission denied на собственных же данных:

# После распаковки — привести владельца к тому, под кем реально работает сервис
chown -R www-data:www-data /var/www/restored_app
find /var/www/restored_app -type d -exec chmod 755 {} \;
find /var/www/restored_app -type f -exec chmod 644 {} \;

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

Кодировка и локаль базы данных. Для MySQL и PostgreSQL несовпадение кодировки исходной и целевой базы иногда проявляется не сразу, а на первых записях с не-латинскими символами — данные восстанавливаются, но кириллица превращается в вопросительные знаки или ошибку invalid byte sequence. Проверяйте кодировку исходного дампа заранее, а не постфактум по жалобам пользователей.

Отсутствующие расширения и зависимости базы. Дамп PostgreSQL может ссылаться на расширения (postgis, pg_trgm, uuid-ossp), которые не установлены в целевом кластере по умолчанию. pg_restore в этом случае выдаст предупреждение, а не фатальную ошибку, и часть данных или индексов просто не восстановится — важно читать вывод команды целиком, а не только код возврата.

От тестового восстановления к боевому

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

Практичный порядок:

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

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

Частые вопросы