Персистентные тома и snapshots в Dockup
Персистентные тома и snapshots в Dockup: выбор путей монтирования, проверка использования, создание и планирование snapshots, безопасное восстановление и защита долговечных данных.
Персистентные тома и snapshots решают две разные задачи. Том сохраняет файлы при замене контейнера и deployment. Snapshot фиксирует состояние тома в определённый момент времени, чтобы позже его можно было проверить, сохранить или восстановить.
Файловая система контейнера заменяема. Всё, что должно пережить deployment — загруженные файлы, сгенерированные медиафайлы, индексы, артефакты пакетов или файлы, которыми управляет приложение, — нужно размещать в явно заданном персистентном расположении.
Какие данные приложения следует хранить в персистентном хранилище?
Используйте том, если приложение владеет файлами, которые нельзя недорого или безопасно воссоздать из другого источника.
| Данные | Том? | Лучшая альтернатива, если доступна |
|---|---|---|
| Пользовательские загрузки | Да | Object storage, если он предусмотрен архитектурой |
| Сгенерированные thumbnails | Возможно | Повторно создать из оригиналов |
| Search index | Возможно | Пересобрать из исходной базы данных |
| Build artifacts | Обычно нет | Пересобрать во время deployment |
| Логи приложения | Обычно нет | Runtime log system |
| Каталог данных PostgreSQL | Не как app volume | Managed PostgreSQL |
| Временный cache | Нет | Redis или ephemeral storage |
| Локальная production DB на SQLite | Рискованно | Managed database для поддержки concurrency и backup |
У тома должен быть один однозначный владелец и один mount path. Если два не связанных друг с другом процесса записывают данные в один каталог, восстановление и анализ прав доступа усложняются.
Перед добавлением хранилища оцените исходный размер, темп роста, требования к сроку хранения и цель восстановления. Диск тарифицируется относительно баланса плана поминутно, поэтому неиспользуемая ёмкость и неконтролируемый рост файлов имеют стоимость.
Как создать и проверить том Dockup?
Выведите список существующих томов для конкретного сервиса:
dockup volume list production/web --json
Добавьте том, указав имя, абсолютный путь внутри контейнера и размер в гигабайтах:
dockup volume add production/web \
--name uploads \
--path /app/uploads \
--size 20 \
--json
Приложение должно записывать данные в /app/uploads. Запись в /uploads или другой локальный каталог не перенаправляет данные в mount автоматически.
После deployment убедитесь, что приложение записывает данные по указанному абсолютному mount path, а не в заменяемую файловую систему контейнера.
Проверьте фактическое использование диска с помощью полученного ID тома:
dockup volume usage <volumeId> production/web --json
Сопоставьте фактическое использование с выделенным размером и метриками приложения. Настройте оповещения до того, как файловая система заполнится: переполненный том может привести к частичной записи, сбоям загрузки файлов или падению приложения.
Проверьте требования к владельцу файлов. Runtime user контейнера должен иметь возможность читать и записывать данные в mount path без предоставления более широких прав, чем необходимо.
Как snapshots томов защищают данные?
Snapshot, созданный по запросу, фиксирует содержимое тома:
dockup volume snapshot <volumeId> production/web --json
Выведите список доступных snapshots:
dockup volume snapshots <volumeId> production/web --json
Snapshots читают том в режиме read-only и не требуют, чтобы приложение записывало данные в специальный каталог snapshot. Они полезны перед рискованной миграцией файлов, массовой перезаписью медиафайлов или изменением приложения, которое преобразует сохранённые данные.
Snapshot тома не обеспечивает автоматическую согласованность на уровне приложения. Если приложение активно записывает несколько связанных файлов, snapshot может зафиксировать их в немного разные моменты времени. Для managed database используйте систему резервного копирования managed database, а не создавайте snapshot её исходного каталога данных.
Определите, в каких случаях приложение должно быть приостановлено. Перед созданием важного snapshot может быть уместна короткая пауза обслуживания или записи. Сохраните ID snapshot, причину создания и ожидаемую точку восстановления.
Как планировать хранение snapshots?
Выбирайте время создания и срок хранения snapshots исходя из требований к восстановлению, а не по привычке. Создавайте snapshot по запросу перед каждой рискованной миграцией файлов, очисткой или изменением формата и сохраняйте полученный ID snapshot.
dockup volume snapshot <volumeId> production/web --json
dockup volume snapshots <volumeId> production/web --json
| Требование к восстановлению | Практика работы со snapshots | Ограничение |
|---|---|---|
| Отмена миграции файлов | Создать snapshot непосредственно перед изменением | Не включает последующие записи |
| Сохранение исторических состояний | Хранить подписанные recovery points в соответствии с политикой | Срок хранения требует регулярного пересмотра |
| Защита часто изменяемых данных | Добавить backup на уровне приложения, соответствующий типу данных | Snapshot на определённый момент времени не обеспечивает непрерывную защиту |
| Архив для выполнения нормативных требований | Использовать отдельный workflow архивирования | Операционных snapshots может быть недостаточно для соблюдения политики |
Проверяйте, что ожидаемые snapshots действительно существуют. Записанная политика хранения не доказывает, что пригодная для восстановления точка была создана.
Как безопасно восстановить snapshot тома?
Восстановление заменяет текущее содержимое тома и перезапускает контейнер:
dockup volume restore \
<volumeId> \
<snapshotId> \
production/web \
--json
Это disruptive-операция, изменяющая состояние системы. Перед восстановлением:
- Подтвердите точные service, volume ID и snapshot ID.
- Объясните, какие текущие файлы будут заменены.
- По возможности остановите новые записи или ограничьте их.
- Создайте свежий snapshot текущего состояния, если оно может понадобиться.
- Зафиксируйте совместимость приложения и схемы.
- Получите явное approval для production.
- Спланируйте проверку после восстановления.
После восстановления проверьте состояние контейнера и работу приложения:
dockup status production/web --json
dockup logs production/web --json
Проверьте репрезентативные файлы, права доступа, индексы и ссылки приложения. Успешное выполнение команды восстановления подтверждает, что snapshot был применён, но не доказывает, что каждая запись приложения ссылается на существующий файл.
В модели защитных ограничений для AI agent в production восстановление должно выполняться только после approval, даже если это операция восстановления.
Как тома должны вести себя во время deployment и rollback?
Deployment заменяет контейнеры приложения, а смонтированный том сохраняется. Благодаря этому новый image видит существующие файлы, но возникает требование совместимости.
Новая версия приложения не должна необратимо преобразовывать сохранённые файлы до того, как будет подтверждена работоспособность release. Если она изменяет форматы файлов или структуру каталогов, по возможности используйте resumable-миграцию с обратной совместимостью.
Rollback приложения повторно запускает предыдущий deployment:
dockup deployments production/web -n 20 --json
dockup rollback <deploymentId> production/web --json
Том не откатывается автоматически вместе с image. Старое приложение может не уметь читать файлы, преобразованные новой версией. Сочетайте rollback image с восстановлением snapshot только в тех случаях, когда необходимы обе операции и для них получено approval.
Важно разделять эти действия:
| Действие восстановления | Изменяет image? | Изменяет данные тома? |
|---|---|---|
| Deployment новой версии | Да | Нет, если только приложение не выполняет миграцию |
| Rollback deployment | Да | Нет |
| Восстановление snapshot | Нет | Да |
| Восстановление и rollback | Да | Да |
Процесс deployment без простоя защищает переключение трафика, но не гарантирует совместимость форматов данных.
Что должно входить в операционный runbook для персистентного хранилища?
Назначьте владельца для каждого production-тома. Runbook должен содержать:
- Целевой сервис и ID тома.
- Mount path и ожидаемого runtime user.
- Выделенный размер и порог оповещения.
- Описание данных и возможность их пересоздания.
- Расписание snapshots и срок хранения.
- Последний проверенный snapshot.
- Политику approval для восстановления.
- Шаги проверки приложения.
- Примечания о совместимости image и данных.
- Политику роста и удаления.
Регулярно проверяйте использование:
dockup volume usage <volumeId> production/web --json
CPU, RAM и диск тарифицируются поминутно. Free plan предоставляет стартовый кредит $10, а рекомендуемый Pro plan стоит $20 в месяц и включает $20 usage credit.
Проверка восстановления snapshot
Не ждите инцидента, чтобы выяснить, что никто не знает, какой snapshot выбрать. Проведите контролируемую проверку на non-production-сервисе или одобренной копии:
- Создайте легко узнаваемые тестовые файлы.
- Создайте snapshot.
- Измените файлы.
- Восстановите snapshot.
- Проверьте содержимое и права доступа.
- Убедитесь, что контейнер перезапустился.
- Зафиксируйте продолжительность и точки отказа.
Проверка восстановления превращает персистентные тома и snapshots из формального пункта в протестированную возможность восстановления.
О начальном проектировании сервиса см. в материале От Git-репозитория до production. Подробности команд приведены в справочнике Dockup CLI.
Определите цели восстановления для файловых данных
Recovery point objective показывает, какой объём последних данных бизнес может потерять. Recovery time objective показывает, сколько времени может занять восстановление. Ежедневный snapshot с хранением семи копий может подойти для внутреннего media cache, но не для продукта с пользовательскими загрузками, который гарантирует сохранность данных почти в реальном времени.
Задокументируйте оба значения и проверьте фактическую продолжительность восстановления. На recovery time влияют скорость создания snapshot, объём данных, перезапуск контейнера, проверка файлов и переиндексация приложения.
Контролируйте удаление и рост файлов
Персистентное хранилище может заполниться, если приложение никогда не удаляет временные или заменённые файлы. Добавьте retention policy на уровне приложения и различайте логическое удаление и немедленное физическое удаление. Короткий период восстановления может оправдывать отсрочку окончательного удаления.
Перед массовой очисткой:
- Измерьте текущее использование тома.
- Сформируйте список файлов-кандидатов на удаление.
- Создайте snapshot.
- Выполните очистку ограниченными пакетами.
- Проверьте ссылки приложения.
- Подтвердите ожидаемое освобождение места.
Так персистентные тома и snapshots получают профилактическую роль, а не только роль инструмента реагирования на инциденты.
Проверяйте inventory snapshots
Регулярно проверяйте ID snapshots, время создания, срок хранения и последнюю успешную проверку восстановления. Настроенная job без свежего пригодного snapshot — это не система восстановления.
Назначьте полномочия на восстановление
Определите, кто может одобрить восстановление в production и кто выполняет проверку после восстановления. Разделение approval и выполнения снижает вероятность того, что спешка приведёт к пропуску проверки цели и snapshot.
Начните с проверяемого deployment
Создайте один non-production-том, сделайте snapshot, измените тестовый файл и завершите проверку восстановления, прежде чем сохранять в системе незаменимые production-данные.
Начните бесплатно на app.dockup.ai. Free plan стоит $0 в месяц, включает стартовый кредит $10 и поддерживает один workspace, три базы данных и три deployment.
FAQ
Сохраняется ли том Dockup после deployment?
Да. Том остаётся персистентным при замене контейнеров сервиса, если приложение продолжает использовать настроенный mount path.
Подходит ли snapshot тома для резервного копирования PostgreSQL?
Нет. Hot snapshot каталога данных базы может быть несогласованным с точки зрения транзакций. Для managed database предпочтительна встроенная система резервного копирования managed database.
Что происходит при восстановлении snapshot тома?
Текущее содержимое тома заменяется выбранным snapshot, а контейнер перезапускается, поэтому операцию следует предварительно одобрить и проверить.
Можно ли настроить расписание snapshots тома в Dockup?
Да. Команда расписания тома поддерживает ежедневные snapshots с указанием количества хранимых копий, а расписание можно явно отключить.
Откатывается ли том вместе с rollback приложения?
Нет. История deployment приложения и история snapshots тома разделены. Сочетайте их только в том случае, если этого требует план восстановления.