Версионирование файлов: больше никогда не теряйте изменения

Версионирование файлов сохраняет каждую ревизию, что позволяет откатываться от случайных перезаписей, удалений и повреждений шифровальщиком. Включите его на уровне платформы — S3 Versioning, Azure Blob Versioning, Google Cloud Storage Object Versioning, история версий Dropbox, основные и вспомогательные версии SharePoint — и дополните lifecycle-правилами, удаляющими старые версии через 30–180 дней. Без версионирования один rm -rf или сбойный клиент синхронизации способен уничтожить годы работы за секунды, а «облачный бэкап», на который вы рассчитывали, окажется лишь синхронизированной копией ущерба.

Что платформенное версионирование делает на практике

Когда версионирование включено, перезапись не заменяет объект — она создаёт новую версию с новым VersionId. Старые байты остаются на диске и доступны по этому ID. Удаление становится «маркером удаления», а не уничтожением; предыдущие версии остаются восстанавливаемыми до тех пор, пока вы явно их не очистите.

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

Стоимость хранения всех версий

Версии потребляют хранилище, а хранилище стоит денег. Бакет с 10 ТБ файлов при активном редактировании может накопить 30–50 ТБ версий за год. Решение — lifecycle-правила, удаляющие неактуальные версии через заданный период или перемещающие их на более дешёвые уровни.

Практичная lifecycle-политика для S3:

Неактуальные версии: переход в S3 Standard-IA через 7 дней
Неактуальные версии: переход в Glacier Flexible Retrieval через 30 дней
Неактуальные версии: удаление через 180 дней
Маркеры удаления без неактуальных версий: удаление через 1 день

Для Azure и GCS аналоги используют условия blobVersion age или Noncurrent. Посчитайте стоимость: 10 ТБ версий в S3 Standard — $230/мес; в Glacier Flexible — $36/мес. Переход на уровни стоит нескольких минут правки YAML.

Основные и вспомогательные версии

Документно-ориентированные системы — SharePoint, Google Workspace, Notion — различают основные (опубликованные) и вспомогательные (черновые) версии. Черновики накапливаются между контрольными точками; основные версии представляют стабильное состояние, которое кто-то согласовал. Для договоров, политик и технических заданий это различие золото — можно публично поделиться ссылкой «основная версия 3», продолжая редактировать черновик v3.1, v3.2 в приватном режиме.

Используйте основные версии как точку отсчёта для внешних участников. Блокируйте их разрешением только для чтения или рабочими процессами согласования, чтобы никто случайно не перезаписал опубликованное состояние. Функция «Требовать утверждения контента» в SharePoint — один клик; настройка процесса согласования в Google Drive — 2 минуты.

Контроль версий для кода против документов

Git великолепно работает для текста (исходный код, markdown, .tf-файлы), потому что diff значим на уровне строк. Для бинарных файлов он работает плохо: .psd-файл на 50 МБ, зафиксированный дважды, удваивает размер репозитория, а git diff не помогает. Git LFS (Large File Storage) перемещает бинарные файлы в отдельное хранилище и держит указатели в репозитории — разумно для художественных ресурсов, плохо для общих документов.

Для .docx, .xlsx, .pptx и .pdf используйте встроенное версионирование облачной платформы, а не Git. SharePoint, Drive и Dropbox нативно хранят дельты для каждой версии и отображают временную шкалу, в которой бизнес-пользователи могут ориентироваться. Для смешанного контента (код плюс PDF плюс дизайн-файлы) некоторые команды используют DVC или LakeFS как Git-подобные слои данных поверх объектного хранилища — стоит изучить для ML- и data-команд.

Хранение, привязанное к регуляторным срокам

Нормативные акты устанавливают, как долго должны храниться версии:

152-ФЗ о персональных данных: хранить не дольше, чем необходимо для заявленной цели; при достижении цели — уничтожение
НК РФ: финансовые документы — минимум 5 лет; счета-фактуры — 4 года
Трудовой кодекс РФ: кадровые документы — 75 лет для приказов о приёме/увольнении
402-ФЗ о бухгалтерском учёте: первичные документы — минимум 5 лет
Архивное законодательство: документы постоянного хранения не удаляются

Тегируйте чувствительные файлы, чтобы lifecycle-правила соблюдали регуляторные минимумы и максимумы. Тег S3 типа retention-class: nk-5y может управлять переходами lifecycle, сроками Object Lock и итоговым удалением. Используйте S3 Object Lock в режиме Compliance для иммутабельных регуляторных копий — даже root-пользователи не могут удалить в течение срока хранения, что именно и требуют WORM-правила.

Защита от шифровальщиков через версии

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

Среднее время дремоты шифровальщика — около 11 дней для компаний среднего размера. Минимальный срок хранения версий — 30 дней; 90 дней надёжнее. Дополняйте версионирование защитой от удаления (S3 MFA Delete, мягкое удаление Azure с отдельным администратором), чтобы злоумышленник, скомпрометировавший один аккаунт, не смог очистить историю версий. Тестируйте восстановление ежеквартально — имитируйте удаление тестовой папки и замеряйте время восстановления.

Соглашения об именовании для общих версий

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

Presigned URL к конкретному VersionId (S3: ?versionId=...) — действителен максимум 7 дней, неизменен
Копия утверждённой версии в отдельный бакет /published/ с версией в имени файла (dogovor-v3.0-2026-12-15.pdf)
PDF-экспорт-снапшот, чтобы последующие правки не затронули переданную копию

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

Мониторинг и алертинг событий версионирования

История версий полезна только если вы замечаете, когда она вам нужна. CloudTrail (AWS), Activity Log (Azure) и Cloud Audit Logs (GCP) логируют каждое событие версионирования. Алертируйте на необычные темпы удаления — 10 000 вызовов DeleteObject за час, скорее всего, не пользователь наводит порядок.

Создайте простой дашборд, показывающий количество версий по бакетам, общий объём версий и отношение маркеров удаления. Бакет, где маркеры удаления внезапно превышают активные объекты — сигнал бедствия: либо произошло массовое удаление, либо lifecycle-хранение вот-вот удалит то, что вы планировали сохранить. Еженедельные email-сводки лучше, чем ожидание квартального аудита.

Runbook восстановления

Задокументируйте процесс восстановления до того, как он понадобится. Хороший runbook охватывает:

Как вывести список версий (aws s3api list-object-versions, az storage blob list --include v)
Как восстановить конкретный VersionId как текущую версию (S3: копирование с --version-id)
Как массово восстановить весь prefix до точки во времени (скрипты с фильтрами по временным меткам)
Как восстановить удалённые объекты (удаление маркеров удаления)
Кто имеет разрешение делать каждое из них (обычно не тот, кто вызвал потерю)

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

Попробуйте на hexatransfer.com — бесплатно, без регистрации, до 10 ГБ.