Три терабайта данных эксперимента и запрет выкладывать их в облако

MAATRIX

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

Почему облако здесь действительно не вариант

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

Для чувствительных категорий — генетический материал, снимки, данные об участниках, привязанные к идентифицируемым лицам, любые данные, где действует институциональное соглашение о конфиденциальности с третьей стороной — этого достаточно, чтобы grant-condition или IRB/этический комитет прямо запретили именно «публичный облачный сервис» как класс инфраструктуры. Формулировка запрета в вашем документе может быть разной, поэтому первый практический шаг — не гадать, а перечитать точную формулировку: запрещено ли «облако» как таковое, «передача за пределы юрисдикции», «обработка третьей стороной» или конкретный перечень сервисов. От этой формулировки будет зависеть, какой вариант инфраструктуры вам подходит.

Важно отделить эмоциональную реакцию «нельзя в облако — значит, всё сложно» от практической: запрет обычно бьёт по конкретной модели — мультитенантному сервису, где вы не управляете нижним уровнем инфраструктуры и подписываете пользовательское соглашение провайдера на обработку данных. Это не запрет на использование серверов вообще.

Что не тянет ноутбук и лабораторный NAS

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

• Объём. Штатный SSD ноутбука редко превышает 1-2 ТБ, а держать на нём единственную копию критичных данных — риск потери при любой аппаратной проблеме.
• Скорость и стабильность. Перекачка терабайтов данных с прибора через общий Wi-Fi лаборатории или по цепочке флешек занимает часы и создаёт лишние промежуточные копии, за которыми потом никто не следит.
• Общий доступ. NAS кафедры используют несколько групп одновременно — при таком совместном хранении сложно гарантировать, что к вашим данным не имеют доступа люди, для которых это прямо не предусмотрено протоколом исследования.
• Резервирование. Домашнее и лабораторное оборудование редко имеет продуманную схему бэкапа: один диск — одна копия, и при отказе накопителя данные эксперимента, который физически не повторить, теряются безвозвратно.
• Рост. Если эксперимент продолжается, а данные копятся — три терабайта довольно быстро становятся пятью или десятью, и апгрейд диска в настольном компьютере не решает проблему на годы вперёд.

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

Свой сервер — это не «облако»: в чём разница по существу

Здесь стоит проговорить прямо: «облако» в смысле grant-условий и институциональной политики — это, как правило, публичный мультитенантный сервис (объектное хранилище, SaaS-платформа для совместной работы, готовый managed-продукт), где данные обрабатываются программным стеком провайдера и подчиняются его пользовательскому соглашению. Арендованный выделенный сервер или VPS, на котором вы сами разворачиваете операционную систему, сами настраиваете хранилище, шифрование и правила доступа — технически и юридически другая история: провайдер сдаёт вам железо и канал связи, но не читает, не обрабатывает и не индексирует ваши данные, потому что у него просто нет доступа к содержимому диска на уровне приложения.

Это принципиальное отличие часто прямо отражено в грантовой или институциональной документации: запрет обычно формулируется как «public cloud service», «third-party data processing» или «передача данных стороннему сервису обработки», а не как «использование арендованных серверных мощностей под собственным управлением исследователя». Тем не менее это не повод действовать по своей интерпретации — прежде чем разворачивать инфраструктуру, стоит показать точную формулировку запрета своему офису по работе с грантами, специалисту по информационной безопасности института или секретарю этического комитета и получить письменное подтверждение, что аренда сервера под полным контролем исследователя укладывается в условия. Это займёт один-два email, но снимает риск на годы вперёд — переспрашивать дешевле, чем потом объяснять комитету постфактум.

Хорошая практика — держать под рукой краткую техническую справку для такого запроса: кто арендует сервер (институт или лично исследователь по гранту), кто имеет root-доступ, где физически расположен дата-центр, как зашифрованы данные и кто хранит ключи. Разница между собственной инфраструктурой и облаком подробнее разобрана в статье «Облако против своего железа» — полезно для того же разговора с комитетом, если требуется объяснить модель на пальцах.

Как спроектировать хранилище под объём и рост

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

Разумная раскладка для сервера с данными эксперимента:

/data/raw/        — сырые данные с прибора, только чтение после записи
/data/processed/  — результаты обработки, версионируются отдельно
/data/scratch/     — временные файлы обработки, можно чистить
/data/backup-stage/ — буфер перед отправкой в резервное хранилище

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

lsblk
mkfs.ext4 /dev/sdb1
mkdir -p /data/raw
mount /dev/sdb1 /data/raw
chattr +i /data/raw/experiment-2026-08  # запрет на изменение после записи, снимается вручную при необходимости

Если данные состоят из большого числа файлов среднего размера (снимки, результаты секвенирования, показания датчиков), объектное хранилище поверх своего сервера — MinIO или аналог — часто удобнее плоской файловой системы: проще версионировать, проще выдавать точечный доступ по ключам соавторам, проще писать скрипты обработки через S3-совместимый API без переписывания путей. Развернуть такое хранилище на собственном сервере, оставаясь вне публичного облака, разобрано в статье «S3-совместимое хранилище у себя» — та же логика, что у коммерческого объектного хранилища, но полностью под вашим контролем и без стороннего провайдера-обработчика.

Для контроля свободного места и роста стоит сразу поставить простой мониторинг — не обязательно сложную систему, достаточно cron-задачи с уведомлением при приближении к порогу:

df -h /data | awk 'NR==2{print $5}'

Шифрование, доступ и журнал событий

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

Базовая настройка — шифрование раздела с данными через LUKS:

cryptsetup luksFormat /dev/sdb1
cryptsetup luksOpen /dev/sdb1 data_encrypted
mkfs.ext4 /dev/mapper/data_encrypted
mount /dev/mapper/data_encrypted /data/raw

Ключ шифрования не должен лежать рядом с зашифрованным разделом «на всякий случай» — храните его отдельно (менеджер паролей института, аппаратный токен, зашифрованный файл вне сервера) и убедитесь, что при перезагрузке сервера потребуется ручной ввод ключа или подключение к отдельному key-серверу, а не автоматическая расшифровка при старте. О том, что именно шифрование диска защищает, а от чего не спасает — отдельный честный разбор в статье «Шифрование дисков: что защищает», стоит прочитать перед тем, как объяснять комитету, что именно вы настроили.

Доступ к серверу стоит ограничить SSH-ключами без пароля, отдельной учётной записью для каждого участника команды и явным списком, кому разрешён доступ к каталогу с данными:

groupadd exp-data
chgrp -R exp-data /data/raw
chmod -R 750 /data/raw
usermod -aG exp-data researcher_ivanov

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

apt install auditd
auditctl -w /data/raw -p rwxa -k experiment_data_access
ausearch -k experiment_data_access

Это не бюрократия ради бюрократии: при отчёте по гранту или проверке комитетом наличие журнала доступа снимает вопросы гораздо быстрее, чем словесные заверения.

Резервные копии данных, которые нельзя повторить

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

Резервную копию нужно делать на отдельный физический носитель или отдельный сервер — но снова не в публичное облако, если условия это запрещают. Рабочая схема: второй арендованный сервер (в другом дата-центре того же или другого провайдера) под тем же контролем исследователя или института, куда данные реплицируются в зашифрованном виде через инструмент вроде borgbackup или restic:

borg init --encryption=repokey-blake2 ssh://backup-server/./exp-2026-backup
borg create --stats --progress \
  ssh://backup-server/./exp-2026-backup::raw-{now:%Y-%m-%d} \
  /data/raw

Ключевые правила для такой схемы:

• бэкап шифруется отдельным ключом, который тоже не хранится на исходном сервере;
• версионирование включено, чтобы можно было откатиться к состоянию до случайной перезаписи файла;
• восстановление проверяется вручную хотя бы раз в несколько месяцев — бэкап, который ни разу не разворачивали обратно, нельзя считать рабочим;
• резервный сервер физически и юридически отделён от основного (другой дата-центр, отдельные учётные данные), чтобы одна авария не унесла обе копии разом.

Таблица для сравнения двух распространённых вариантов резервной схемы:

Комбинация «сервер плюс офлайн-носитель» на практике закрывает больше сценариев отказа, чем любой вариант по отдельности.

Частые вопросы