# Ephemeral и persistent disk у GPU VM: проверка перед удалением

Как отличить ephemeral и persistent disk у GPU VM: тип устройства, действие Stop и Delete, DeleteOnTermination и контрольная проверка файла.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/cloud-gpu-ephemeral-vs-persistent-checklist/
Language: ru

Ephemeral-диск рассчитан на временные данные, а persistent-ресурс имеет отдельные правила сохранения. Но одно слово persistent не гарантирует переживание любого удаления. Перед завершением GPU VM выясните тип устройства, связь с экземпляром и настройки операции, затем проверьте восстановление контрольного файла.

## Опишите жизненный цикл конкретного диска

[Документация AWS instance store](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html) описывает временное блочное хранение, связанное с ресурсом экземпляра. [Правила EBS при termination](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/preserving-volumes-on-termination.html) показывают другой механизм: судьба тома определяется его атрибутом удаления.

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

## Не доверяйте только имени каталога

Linux-путь показывает место в файловой системе, но не условия облачной услуги. Папка `/data` может находиться на временном диске, постоянном томе или обычной части загрузочного устройства. Даже знакомое `/workspace` у контейнерных площадок может соответствовать разным ресурсам.

Сверьте путь с устройством и ID в панели. Запишите назначение каталога, тип ресурса и ожидаемую судьбу при Stop, Restart и Delete. Эти сведения должны быть доступны вне самой VM, иначе после удаления восстановить связь по памяти будет трудно.

## Учебный эксперимент с контрольным файлом

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

| Действие | Что нужно подтвердить |
| --- | --- |
| Перезапуск приложения | Файл лежит на диске, а не только в памяти |
| Перезагрузка VM | Правильное монтирование после старта |
| Остановка | Сохранность по правилам выбранного диска |
| Удаление экземпляра | Отдельное существование нужного ресурса |
| Новый экземпляр | Рабочий способ чтения или восстановления |

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

## Разделите ценность данных

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

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

Раз в некоторое время повторяйте проверку восстановления на небольшом наборе. Изменение образа, пути монтирования или прав пользователя способно сделать прежнюю инструкцию неверной. В отчёте укажите дату последнего успешного чтения и ответственную среду. Это превращает резервирование в проверяемый процесс, а не в постоянную уверенность на основании единственного старого теста.

## Сохраните доказательства восстановления

В отчёте укажите ID диска, путь, выполненную операцию и результат чтения из следующей среды. Это конкретнее, чем общая отметка «persistent настроен». После проверки обновите инструкцию запуска и завершения GPU-пилота.

Для примеров используйте [три типа Runpod storage](/ru/journal/runpod-container-volume-network-disk/) и [EBS после удаления EC2](/ru/journal/aws-gpu-ebs-after-termination/). Это поможет сразу обсудить судьбу данных при смене вычислительной среды.