Перейти к основному содержанию Перейти к навигации Перейти к нижнему колонтитулу

Резервное копирование и восстановление

Отправьте репозиторий во внешнее хранилище и восстановите его на новом сервере, когда потребуется.

Резервное копирование и восстановление

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

Смотреть урок

Три шага

Configure, push, restore

  1. Настройте провайдера хранилища.
  2. Отправьте резервную копию.
  3. Восстановите, когда потребуется.

Шаг 1: Настройка хранилища

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

rdc storage import rclone.conf

Импортируйте существующую конфигурацию rclone. rclone поддерживает S3, Backblaze, Google Drive, Dropbox и многое другое. Если вы уже используете rclone, тот же конфигурационный файл импортируется напрямую.

Поддерживаются S3, B2, Google Drive, Dropbox и многое другое. Проверьте, что подключено:

rdc storage list

Выведите список хранилищ, которые теперь известны CLI. Каждое из них является назначением для резервных копий.

Шаг 2: Отправка резервной копии

rdc repo push my-app --to my-storage

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

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

Просматривайте резервные копии в любое время:

rdc backup list --storage my-storage

Выведите список резервных копий, доступных в этом хранилище. Восстановление на новом сервере выполняется одной командой: командой repo pull.

Почему нет простоя?

Приложение продолжает работать, пока загружается резервная копия. Как это согласовано?

Та же логика, что и при форке. rdc сначала делает форк, потом загружает его. Форк фиксирует момент, а живое приложение продолжает работать. Никакого простоя, никаких несоответствий.

Шаг 3: Восстановление – по-настоящему

Резервные копии, которые вы никогда не восстанавливаете, – это надежды, а не резервные копии. Сначала переведите репозиторий в офлайн:

rdc repo down my-app --unmount

Сначала переведите repository в офлайн: остановите сервисы и отмонтируйте зашифрованный том с помощью команды repo down.

Вытащите резервную копию обратно из хранилища:

rdc repo pull my-app --from my-storage --force --yes

Загрузите бэкап обратно из хранилища с помощью команды repo pull. Образ скачивается и проверяется на целостность.

И смонтируйте снова – полностью восстановлено:

rdc repo up my-app --no-start

Смонтируйте repository снова, он полностью восстановлен. Та же команда pull работает на совершенно новой машине.

То же самое pull работает на совершенно новом сервере: настройте его, добавьте в rdc и запустите pull там:

rdc repo pull my-app@new-server --from my-storage
rdc repo up my-app@new-server

Те же данные, те же контейнеры, другая машина.

Быстрее: напрямую между машинами

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

rdc repo push my-app --to backup-server

Совет. Передачи между машинами после первой отправляют только изменившиеся блоки. Урок по дельта-передаче показывает это вживую.


Далее: Сеть и домены.