# Завершение GPU-пилота: как зафиксировать очистку рабочих каталогов

Как зафиксировать очистку рабочих данных после GPU-пилота: границы каталогов и томов, перечень проверок, доступы и ограничения подтверждения.

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

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

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

## Определите границу данных

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

[Docker объясняет жизненный цикл томов](https://docs.docker.com/engine/storage/volumes/): данные тома существуют отдельно от контейнера. Поэтому завершение или удаление контейнера не следует считать автоматическим подтверждением очистки всей рабочей среды. Сначала нужно выяснить фактические точки хранения.

## Используйте матрицу завершения

Ниже пример структуры акта проверки. Это не инструкция по выполнению разрушительных команд.

| Объект | Решение до завершения | Что фиксировать после |
| --- | --- | --- |
| Исходные документы | Вернуть или очистить | Перечень и ответственного |
| Результаты обработки | Передать владельцу | Место передачи и подтверждение |
| Временный том | Удалить по согласованию | Идентификатор и статус проверки |
| Журнал диагностики | Сохранить ограниченный набор | Состав и срок хранения |
| Резервная копия | Применить отдельное правило | Место и принятое решение |
| Ключ оператора | Отозвать доступ | Учётную запись и время |

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

## Проверьте доступ отдельно от файлов

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

[Руководство OpenSSH sshd](https://man.openbsd.org/sshd) описывает авторизацию через ключи и её параметры. В рабочем отчёте полезно отметить изменение разрешённых ключей, завершение согласованных сеансов и проверку доступа владельцем. Не нужно включать частные ключи в подтверждающие материалы.

## Не обещайте больше проверенного

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

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

## Подготовьте возврат сервера

К акту приложите [правила безопасности оборудования](/ru/journal/hardware-security/) и исходный [чеклист пилота](/ru/journal/pilot-checklist/). Сопоставление начала и окончания помогает убедиться, что временные права и рабочие места хранения действительно учтены.