В этом материале
Сохранность определяется типом облачного ресурса и операцией, а не тем, что файл виден в текущей сессии.
Ephemeral-диск рассчитан на временные данные, а persistent-ресурс имеет отдельные правила сохранения. Но одно слово persistent не гарантирует переживание любого удаления. Перед завершением GPU VM выясните тип устройства, связь с экземпляром и настройки операции, затем проверьте восстановление контрольного файла.
Опишите жизненный цикл конкретного диска
Документация AWS instance store описывает временное блочное хранение, связанное с ресурсом экземпляра. Правила EBS при termination показывают другой механизм: судьба тома определяется его атрибутом удаления.
Следовательно, вопрос «есть ли диск» слишком общий. Нужно знать, какое облачное устройство обслуживает каталог, переживает ли оно остановку и что происходит при удалении VM. Один и тот же файл может быть доступен в текущем процессе и исчезнуть после следующего административного действия.
Не доверяйте только имени каталога
Linux-путь показывает место в файловой системе, но не условия облачной услуги. Папка /data может находиться на временном диске, постоянном томе или обычной части загрузочного устройства. Даже знакомое /workspace у контейнерных площадок может соответствовать разным ресурсам.
Сверьте путь с устройством и ID в панели. Запишите назначение каталога, тип ресурса и ожидаемую судьбу при Stop, Restart и Delete. Эти сведения должны быть доступны вне самой VM, иначе после удаления восстановить связь по памяти будет трудно.
Учебный эксперимент с контрольным файлом
Создайте небольшой файл со случайной строкой и сохраните его контрольную сумму отдельно. На учебном ресурсе выполните документированную операцию, которая нужна проекту, затем проверьте файл. Не начинайте такой опыт с единственной копии рабочих результатов.
| Действие | Что нужно подтвердить |
|---|---|
| Перезапуск приложения | Файл лежит на диске, а не только в памяти |
| Перезагрузка VM | Правильное монтирование после старта |
| Остановка | Сохранность по правилам выбранного диска |
| Удаление экземпляра | Отдельное существование нужного ресурса |
| Новый экземпляр | Рабочий способ чтения или восстановления |
Таблица задаёт вопросы, а не универсальные ответы для всех провайдеров. Для каждого шага нужен документированный механизм продукта.
Разделите ценность данных
Публичный кэш модели, собственная разметка и временные логи имеют разную стоимость восстановления. Первый можно загрузить снова, но это займёт время. Разметка может существовать только у команды. Решение о копиях принимайте по ценности и восстановимости, а не исключительно по размеру папки.
Для незаменимых данных назначьте отдельную резервную копию и проверку чтения. Сохранённый облачный том не заменяет эту процедуру автоматически. Также продумайте доступ после ухода участника и ответственность за баланс: техническая долговечность без управляемого владельца не обеспечивает продолжение проекта.
Раз в некоторое время повторяйте проверку восстановления на небольшом наборе. Изменение образа, пути монтирования или прав пользователя способно сделать прежнюю инструкцию неверной. В отчёте укажите дату последнего успешного чтения и ответственную среду. Это превращает резервирование в проверяемый процесс, а не в постоянную уверенность на основании единственного старого теста.
Сохраните доказательства восстановления
В отчёте укажите ID диска, путь, выполненную операцию и результат чтения из следующей среды. Это конкретнее, чем общая отметка «persistent настроен». После проверки обновите инструкцию запуска и завершения GPU-пилота.
Для примеров используйте три типа Runpod storage и EBS после удаления EC2. Это поможет сразу обсудить судьбу данных при смене вычислительной среды.