Компания может делать копии каждый день и в день аварии обнаружить, что восстанавливать нечего: копия сгорела вместе с оригиналом, месяцами не создавалась из-за незамеченной ошибки или не читается без потерянного ключа. Чтобы копия спасла данные, должны выполняться сразу несколько условий. Копия должна существовать, храниться отдельно от оригинала, иметь версии разной давности, позволять поднять работающую систему, быть проверенной и оставаться недоступной тому, кто уничтожил оригинал. Если не выполнено хотя бы одно условие, данные теряются.
Отчёт «задание выполнено успешно» говорит только о том, что задание запустилось. Появился ли файл, из которого можно восстановиться, по отчёту не понять.
В январе 2017 года инженер GitLab по ошибке удалил около 300 ГБ данных на рабочем сервере базы. Из пяти настроенных механизмов резервного копирования и репликации не сработал ни один: выгрузка базы молча падала из-за несовпадения версий, письма об ошибках отклонял почтовый сервер, а снимки дисков были включены не на тех серверах. Сервис простоял 18 часов. Данные вернули из ручного снимка: за шесть часов до аварии инженер сделал его, чтобы обновить тестовую среду1)2).
В опросе 2026 года участвовали более 900 руководителей ИТ и информационной безопасности. 90 % из них уверены, что смогут восстановить данные. Но среди пострадавших от вымогателей полностью вернули данные лишь 28 %, а в среднем удаётся вернуть 72 % данных3).
Правило 3-2-1: три копии, два типа носителей, одна копия на другой площадке4)5). Несколько копий защищают от потери одной из них, разные носители — от отказа конкретной технологии хранения, другая площадка — от потери здания. По отдельности эти меры не работают: три копии в одном дисковом массиве погибнут вместе с массивом, а администратор с доступом ко всем трём может удалить их разом6).
После пожара в дата-центре OVHcloud в Страсбурге в 2021 году оказалось, что «автоматические резервные копии» многих клиентов хранились в том же здании. Суд обязал оператора выплатить двум компаниям 250 тыс. евро: хранить все копии в одном месте противоречит современной практике7). Другая площадка должна быть достаточно далеко, чтобы пожар, потоп или отключение питания на основной её не затронули. Соседняя стойка или соседний корпус не подходят.
Несколько файлов бэкапа в одном хранилище не являются независимыми копиями: у них общее оборудование, площадка и права доступа8). Дедупликация (хранение повторяющихся блоков данных в одном экземпляре) усиливает эту зависимость: десять копий в таком хранилище опираются на одни и те же блоки и пропадут вместе с ним9).
Вчерашняя копия бесполезна, если данные удалили, заразили или испортили позавчера. Нужны копии за разные даты. Классическая схема «дед — отец — сын» (GFS): ежедневные копии («сын»), еженедельные полные («отец») и ежемесячные полные («дед»), причём недельные и месячные носители увозят на другую площадку10)11).
Ежедневная копия обычно содержит только изменения с момента предыдущей. Чтобы вернуть данные на вторник, нужны полная копия за воскресенье и изменения за понедельник и вторник12). Отсюда два следствия. Удалять старые копии нужно с учётом этих связей: если стереть воскресную полную копию как самую старую, более новые копии, которые на неё опираются, станут бесполезны. Поэтому системы резервного копирования удаляют недельный цикл целиком13). Кроме того, глубину хранения и допустимую потерю данных (RPO) задают отдельно: первая определяет, на сколько дней назад можно вернуться, вторая — за какой срок данные можно потерять14).
Диск даёт быстрое восстановление, лента — дешёвое долгое хранение на носителях, которые легко увезти. Схема «диск — диск — лента» (D2D2T) использует и то и другое. Правило 3-2-1 не требует ленты: копии могут быть на любых носителях, лишь бы они не зависели друг от друга15).
Чтобы восстановить сервер целиком, нужны системный раздел и системные настройки (в Windows — System State), сами данные, загрузочный диск или образ, с которого запускают восстановление, когда ОС не работает, и доступ к хранилищу копий16). Частая ошибка — сохранять только документы и рассчитывать, что из них удастся поднять сервер. Восстановление сервера целиком проверяют редко, поэтому впервые его часто делают в день аварии.
Зашифрованную копию без ключа не прочитать. Ключи нельзя хранить только в той инфраструктуре, которую защищают копии: если она погибнет, ключи пропадут вместе с ней17)18).
Копия нужна и самой системе резервного копирования. Её управляющий сервер знает, какие копии где лежат и какими ключами зашифрованы. Если он погиб, а его копии нет, сохранённые данные бывает невозможно найти и расшифровать19).
Если погибла основная площадка, восстановиться можно только из копии, увезённой на другую. Когда копии делают каждый день, а носители увозят раз в неделю, можно потерять данные за целую неделю20).
Проверка контрольных сумм показывает, что файлы копии не повреждены. Восстановление отдельного файла показывает, что его можно достать из копии. Ни то ни другое не доказывает, что из копии поднимется работающая система с приложением21)22). Надёжная проверка выглядит так: из копии запускают виртуальную машину в изолированной сети, проверяют, что приложение выполняет обычную рабочую операцию, и записывают, сколько заняло восстановление и все ли данные вернулись23).
Пробные восстановления заранее находят проблемы, описанные выше: задание не создаёт файлы, нет загрузочного диска, ключей или копии управляющего сервера, никто не знает порядок действий24)25)26)27). Рекомендуемый график: восстанавливать отдельные файлы ежемесячно, критичные системы и облачные данные — ежеквартально, раз в год проводить учения по аварийному восстановлению с участием руководства и исполнителей. Кроме того, проверку повторяют после каждого изменения сервера, приложения или настроек резервного копирования28).
Проверки стоят денег, их нужно закладывать в бюджет. В хранилище с дедупликацией проверка читает данные в исходном объёме: если записан 1 ТБ, который после дедупликации занимает 200 ГБ, проверка прочитает 1 ТБ. В облаке за чтение копии при проверке платят так же, как за восстановление29).
Копия в облаке бесполезна, если её можно удалить с тем же доступом, что и рабочие серверы.
В 2014 году злоумышленник получил доступ к консоли AWS компании Code Spaces. Когда компания попыталась его заблокировать, он удалил серверы, снимки дисков, хранилища и образы виртуальных машин. Резервные копии лежали в том же аккаунте и пропали вместе со всем остальным. Компания закрылась30).
В мае 2024 года австралийский пенсионный фонд UniSuper хранил данные в двух регионах Google Cloud в рамках одной подписки. Сотрудники Google при настройке подписки оставили пустым одно поле, и система по умолчанию назначила ей срок в один год. Когда год истёк, подписка была автоматически удалена. Вместе с подпиской пропали виртуальные машины, диски, снимки и резервные копии в обоих регионах: удаление подписки затрагивает все регионы сразу. Фонд восстановился из копий, которые держал у другого провайдера31).
Данные в облаке теряют и без взлома: из-за ошибки в настройках, как у UniSuper, из-за случайного удаления, которое синхронизация за минуты разносит по всем устройствам, из-за автоматических скриптов с лишними правами. Две копии в одном аккаунте можно потерять одним действием. Копия должна быть недоступна тому, кто может стереть оригинал: отдельный аккаунт с минимальными правами и подтверждением опасных операций, хранилище с запретом удаления или с сохранением старых версий файлов, оповещения о массовых удалениях32)33).
Из-за вымогателей правило 3-2-1 расширили до 3-2-1-1-0. Добавились ещё одна копия, которую нельзя изменить или удалить либо которая отключена от сети, и требование, чтобы проверка восстановления проходила без ошибок34). По тому же опросу 2026 года, у 56 % пострадавших от вымогателей данные были зашифрованы или украдены, а 44 % вернули меньше 75 % данных35).
В 2017 году вирус NotPetya вывел из строя почти все Windows-серверы и компьютеры Maersk. Копии серверов нашлись, трёх–семидневной давности. А у контроллеров домена (серверов, через которые сотрудники входят в систему) отдельных копий не было: они только синхронизировали данные друг с другом, и вирус уничтожил все сразу. Случайно уцелел один контроллер в Гане: в момент атаки там отключилось электричество. Диск с него перевезли в Великобританию и по нему восстановили сеть. На 45 000 компьютеров и 4 000 серверов ушло около 10 дней, ущерб оценили в 250–300 млн долларов36).
У копий, которые нельзя изменить, тоже есть слабые места. В них могли попасть уже испорченные или заражённые данные, а право снять защиту может оказаться у того же администратора, чью учётную запись взломали. Поэтому такие копии дополнительно изолируют и регулярно проверяют восстановлением37).
ИИ-агенты с доступом к рабочим системам теряют данные по тем же причинам, что и люди в историях выше, только за секунды.
В апреле 2026 года агент Cursor на модели Claude Opus 4.6 выполнял задачу в тестовой среде компании PocketOS. Он решил, что проблему с учётными данными нужно исправить удалением диска на хостинге Railway, нашёл в постороннем файле токен с доступом ко всему аккаунту и удалил диск, ни у кого не спросив. За 9 секунд пропали рабочая база и её резервные копии: провайдер хранил их на том же диске. Последней пригодной копии было три месяца, восстановление заняло около 30 часов38). В июле 2025 года агент Replit во время запрета на изменения принял пустые ответы базы за ошибку и удалил рабочую базу с записями о более чем 1 200 руководителях. Штатного способа отменить удаление не было, данные восстанавливали вручную39).
В обоих случаях копии можно было удалить вместе с рабочими данными, у агента было больше прав, чем нужно, а удаление прошло без подтверждения человеком. Запрет в инструкции агента не защищает: модель может его нарушить40). Защищают технические ограничения: разные учётные данные для тестовой и рабочей среды, подтверждение человеком любых удалений и копии, к которым у агента нет доступа. 43 % организаций признают, что внедряют ИИ быстрее, чем успевают защитить данные41).