Резервное копирование Docker

Что случилось и при чём здесь ваш сайт

В ночь с 7 на 8 октября 2026 года дата-центр Яндекса в Сасово был серьёзно повреждён атакой беспилотника, его работу полностью остановили. Утром 9 октября атаке подвергся дата-центр в Калуге, часть инфраструктуры там вышла из строя. В ночь на 11 октября пострадал третий объект, во Владимире. Это подтверждает сама компания в обращении «„Железное сердце“ Яндекса — что происходит с нашими дата-центрами». Сроки восстановления оборудования в Яндексе пока не называют.

Сбои вышли за пределы сервисов самого Яндекса. На мощностях Yandex Cloud работают тысячи сторонних компаний, и после остановки владимирской площадки сбои были у «Циана», «Магнита», Flowwow, DDX Fitness. «Додо Пицца» сообщила, что её сайт и приложение недоступны из-за «масштабной аварии у облачного провайдера». Канал Yandex Cloud Alerts написал клиентам прямо: «Оставшуюся конфигурацию ресурсов считаем неустойчивой. Режим работы платформы является аварийным — рекомендуем задействовать любые другие альтернативные планы по аварийному восстановлению» (Forbes).

По данным «Коммерсанта», Yandex Cloud договорилась с Selectel, K2Cloud и VK Cloud об ускоренном размещении клиентов, а в пользовательское соглашение сервисов Яндекса добавили пункт о форс-мажоре, где упомянуты и атаки БПЛА. Для владельца бизнеса вывод простой: если проект живёт у одного провайдера и у вас нет своей копии, переезд начнётся с вопроса «а что у нас вообще есть», и ответ придётся искать в аварийном режиме.

Хорошая новость в том, что сделать копию проекта, который работает в Docker, сейчас можно за один вечер. Большую часть рутины берёт на себя AI-агент: он смотрит, что запущено на сервере, раскладывает копии по папкам и скачивает их к вам на компьютер. Ниже пошаговая инструкция и готовый промпт.

Что именно нужно сохранить

Docker-проект состоит из нескольких слоёв, и копировать нужно каждый. Если сохранить только образы, после переезда вы получите пустое приложение без базы и загруженных файлов.

• Образы (images). Это код приложения с зависимостями. Если образы собираются в CI и лежат в registry, копия всё равно нужна: registry тоже может оказаться у пострадавшего провайдера.
• Тома и примонтированные папки (volumes, bind mounts). Здесь живут базы данных, загруженные пользователями файлы, кэш поиска. Это самое ценное и самое невосстановимое.
• Дампы баз данных. Копия файлов работающей PostgreSQL или MySQL может оказаться несогласованной, потому что база пишет в них прямо во время копирования. Логический дамп через pg_dump или mysqldump надёжнее.
• Описание запуска. Файлы docker-compose.yml, Dockerfile, настройки nginx или Traefik, задания cron, список открытых портов. Без них образы и данные придётся собирать в рабочую систему по памяти.
• Секреты. Файлы .env, ключи API, пароли к базам. О них ниже отдельно: в нашем промпте агенту запрещено их трогать, и это сделано намеренно.

Сюда же стоит добавить то, что живёт вне сервера: DNS-записи домена, SSL-сертификаты, если они не выпускаются автоматически, доступы к почте и платёжным сервисам. Агент их не скопирует, но список составить поможет.

Почему эту работу удобно отдать AI-агенту

Под AI-агентом здесь понимается программа вроде Claude Code, Codex или другого агента, который умеет выполнять команды в терминале и подключаться к серверу по SSH. Подробнее о том, как такие агенты устроены и чем отличаются от чат-бота, мы писали в материале «ИИ-агенты для бизнеса».

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

Агент делает ту же работу по шагам и показывает каждую команду до выполнения. Он составляет опись контейнеров, сам находит тома, предлагает способ дампа для каждой базы и пишет отчёт: что сохранено, какой размер, что осталось за рамками. Человеку остаётся читать команды и нажимать «разрешить». Для владельца бизнеса без команды DevOps это разница между «когда-нибудь сделаем» и «сделано сегодня».

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

Подготовка перед запуском

1. Место на компьютере. Посмотрите, сколько занимают данные на сервере (docker system df и размер папок с томами), и освободите на локальном диске хотя бы вдвое больше. Сжатие помогает, но базы и медиафайлы сжимаются по-разному.
2. Доступ по SSH-ключу. Агенту не нужно знать пароль от сервера. Подключение по ключу, который уже лежит у вас в ~/.ssh, безопаснее и не требует передавать секреты в чат.
3. Отдельный пользователь с минимальными правами, если есть такая возможность. Ему нужен доступ к Docker и к чтению папок с данными. Права на удаление и изменение системных настроек не нужны.
4. Режим подтверждения команд. В Claude Code и аналогах можно запретить выполнение без вашего согласия. Для работы с боевым сервером это обязательная настройка, а не перестраховка.
5. Время с низкой нагрузкой. Дамп большой базы и архивация томов нагружают диск. Лучше запускать вечером или ночью.

Готовый промпт для AI-агента

Этот промпт мы используем сами. Адрес сервера замените на свой:

Ничего не меняй , проанализируй мои работающие образы в docker на сервере user@server-ip, создай резервные копии каждый бекап в своей папке , и сохрани на мой компьютер локально, для последующего импорта на другой сервер , не трогай credentials, и не меняй данные , твоя задача только выполнить snapshot.

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

Если хотите получить на выходе ещё и инструкцию по восстановлению, добавьте к промпту вторую часть:

После копирования составь файл RESTORE.md: список контейнеров, образов и томов, размер каждого бэкапа, команды для восстановления на новом сервере. Перед каждой командой, которая что-то создаёт на сервере, спроси разрешения.

Что агент сделает на сервере: пошагово

Порядок может немного отличаться, но рабочая схема выглядит так. Команды приведены, чтобы вы понимали, что подтверждаете.

Опись. Агент смотрит запущенные контейнеры и их тома:

docker ps --format '{{.Names}}  {{.Image}}  {{.Status}}'
docker inspect имя_контейнера --format '{{json .Mounts}}'

Образы. Каждый образ сохраняется в архив командой docker save. Чтобы не занимать место на сервере, поток можно сразу передавать к себе на компьютер:

ssh user@server-ip "docker save имя_образа:тег" | gzip > backups/app/image.tar.gz

Обратите внимание на разницу между docker save и docker commit. Первая сохраняет образ как есть и ничего не создаёт на сервере. Вторая делает из работающего контейнера новый образ, то есть меняет состояние сервера, и по нашему промпту агент должен спросить разрешения. Если внутри контейнера что-то меняли вручную, без docker commit или docker export эти правки не сохранятся.

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

Базы данных. Для PostgreSQL дамп выполняется внутри контейнера базы:

ssh user@server-ip "docker exec имя_контейнера_бд pg_dump -U пользователь имя_базы" | gzip > backups/db/dump.sql.gz

Если для дампа нужен пароль, агент упрётся в запрет на credentials и остановится. Это правильное поведение: дамп запускаете вы сами, а агент подставляет остальное.

Конфигурация. Агент копирует docker-compose.yml, конфиги прокси и cron-задания, но пропускает .env и другие файлы с секретами.

Отчёт. В конце вы получаете папки вида backups/имя_проекта/, в каждой образ, архивы томов, дамп и описание. Агент перечисляет, что сохранено, и что пропущено и почему.

Секреты: почему агенту запрещено их трогать

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

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

Как проверить, что бэкап рабочий

Копия, которую ни разу не восстанавливали, остаётся надеждой. Минимальная проверка занимает полчаса:

1. Сравните размеры архивов с данными на сервере. Архив тома с базой на 20 гигабайт не может весить 3 мегабайта.
2. Проверьте целостность архивов: gzip -t для сжатых файлов, tar -tf для просмотра содержимого.
3. Поднимите проект на тестовой машине или дешёвом VPS: docker load для образов, восстановление томов, docker compose up -d. Откройте сайт, зайдите в админку, проверьте, что последние заказы или заявки на месте.
4. Запишите, сколько это заняло. Это и есть ваше реальное время восстановления, которое пригодится при разговоре о рисках.

Если на шаге 3 что-то не взлетело, лучше узнать это сейчас, а не в день аварии.

Переезд на другого хостинг-провайдера

Когда копия проверена, сам переезд сводится к повторению проверки на боевом сервере:

1. Арендуйте сервер у другого провайдера и установите Docker. Если вы используете Dokploy, установите его заранее, это упростит деплой.
2. Загрузите образы, восстановите тома и дампы баз.
3. Перенесите секреты отдельно, как описано выше.
4. Запустите проект и проверьте его по временному адресу.
5. Заранее, за сутки до переезда, уменьшите TTL у DNS-записей домена. Тогда после переключения A-записи на новый IP клиенты быстрее попадут на новый сервер.
6. Сделайте финальный дамп базы прямо перед переключением, чтобы не потерять заказы, пришедшие между копией и переездом.

Если проект зависит от управляемых сервисов облака, например от хранилища объектов или управляемой базы данных, их данные нужно выгрузить отдельно средствами самого облака. Docker-бэкап их не захватит.

Как сделать бэкап привычкой, а не разовой акцией

Разовая копия устаревает в день создания. После первого прогона имеет смысл автоматизировать процесс:

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

Это классическое правило «3-2-1»: три копии данных, на двух разных носителях, одна вне основной площадки. События октября показали, что «вне площадки» для облака означает «у другого провайдера», а не «в соседней зоне доступности того же облака».

Риски и ограничения

Подход с AI-агентом экономит время, но у него есть пределы, о которых стоит знать заранее.

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

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

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

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

Сроки и стоимость зависят от проекта: количества контейнеров, объёма данных, наличия CI и документации. Для небольшого сайта на одном сервере это ориентировочно вечер работы, для системы из нескольких серверов требуется отдельная оценка.

Чек-лист на сегодня

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

Привязка к одному поставщику бьёт и за пределами хостинга. Похожий случай с блокировкой аккаунта и срочным переносом пяти проектов мы описывали в материале «Claude Code заблокировал мой аккаунт», а для селлеров разбирали, как восстановить продажи после пожара на складе WB. Вывод везде один: запасной план дешевле, когда его готовят заранее.

Возьмём проект на постоянное обслуживание

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

Что входит, можно посмотреть на странице услуги «Поддержка сайтов». Если нужен переезд на новую инфраструктуру с автоматическим деплоем, подойдёт услуга «Деплой и инфраструктура». Оставьте заявку, и мы начнём с описи того, что у вас работает и где лежат данные.