Резервное копирование и восстановление
Ваше приложение работает в продакшене. Создайте резервную копию. rdc отправляет весь репозиторий (приложение, базу данных, файлы, конфигурации) во внешнее хранилище и восстанавливает его в любой момент. Программы-вымогатели, отказы оборудования, что угодно.
Смотреть урок
Три шага
- Настройте провайдера хранилища.
- Отправьте резервную копию.
- Восстановите, когда потребуется.
Шаг 1: Настройка хранилища
Вам понадобится файл конфигурации rclone. Если вы уже используете rclone, импортируйте его напрямую:
rdc config storage import --file rclone.confИмпортируйте существующую конфигурацию rclone. rclone поддерживает S3, Backblaze, Google Drive, Dropbox и многое другое. Если вы уже используете rclone, тот же конфигурационный файл импортируется напрямую.
Поддерживаются S3, B2, Google Drive, Dropbox и многое другое. Проверьте, что подключено:
rdc config storage listВыведите список хранилищ, которые теперь известны CLI. Каждое из них является назначением для резервных копий.
Шаг 2: Отправка резервной копии
rdc repo push --name my-app -m <machine-name> --to my-storageОтправьте полную резервную копию. Весь репозиторий загружается целиком, включая приложение, базу данных, файлы и конфигурацию. Поскольку репозиторий зашифрован в состоянии покоя, резервная копия также зашифрована, без необходимости управлять дополнительными ключами.
Весь репозиторий (приложение, база данных, файлы, всё) теперь сохранён. Поскольку репозиторий зашифрован, резервная копия тоже зашифрована. Никакого дополнительного управления ключами.
Просматривайте резервные копии в любое время:
rdc repo backup list --from my-storage -m <machine-name>Выведите список резервных копий, доступных в этом хранилище. Восстановление на новом сервере выполняется одной командой: командой repo pull.
Почему нет простоя?
Приложение продолжает работать, пока загружается резервная копия. Как это согласовано?
Та же логика, что и при форке. rdc сначала делает форк, потом загружает его. Форк фиксирует момент, а живое приложение продолжает работать. Никакого простоя, никаких несоответствий.
Шаг 3: Восстановление – по-настоящему
Резервные копии, которые вы никогда не восстанавливаете, – это надежды, а не резервные копии. Сначала переведите репозиторий в офлайн:
rdc repo down --name my-app --machine <machine-name> --unmountСначала переведите repository в офлайн: остановите сервисы и отмонтируйте зашифрованный том с помощью команды repo down.
Вытащите резервную копию обратно из хранилища:
rdc repo pull --name my-app --machine <machine-name> --from my-storage --force --yesЗагрузите бэкап обратно из хранилища с помощью команды repo pull. Образ скачивается и проверяется на целостность.
И смонтируйте снова – полностью восстановлено:
rdc repo mount --name my-app --machine <machine-name>Смонтируйте repository снова, он полностью восстановлен. Та же команда pull работает на совершенно новой машине.
То же самое pull работает на совершенно новом сервере: настройте его, добавьте в rdc и запустите pull там:
rdc repo pull --name my-app -m new-server --from my-storage
rdc repo up --name my-app -m new-serverТе же данные, те же контейнеры, другая машина.
Быстрее: напрямую между машинами
Можно также передавать данные напрямую между машинами, без облачного хранилища:
rdc repo push --name my-app -m my-server --to-machine backup-serverСовет. Передачи между машинами после первой отправляют только изменившиеся блоки. Урок по дельта-передаче показывает это вживую.
Далее: Сеть и домены.