Компания может делать копии каждый день и в день аварии обнаружить, что восстанавливать нечего: копия сгорела вместе с оригиналом, месяцами не создавалась из-за незамеченной ошибки или не читается без потерянного ключа. Чтобы копия спасла данные, должны выполняться сразу несколько условий. Копия должна существовать, храниться отдельно от оригинала, иметь версии разной давности, позволять поднять работающую систему, быть проверенной и оставаться недоступной тому, кто уничтожил оригинал. Если не выполнено хотя бы одно условие, данные теряются.
Отчёт «задание выполнено успешно» говорит только о том, что задание запустилось. Появился ли файл, из которого можно восстановиться, по отчёту не понять.
В январе 2017 года инженер GitLab по ошибке удалил около 300 ГБ данных на рабочем сервере базы. Из пяти настроенных механизмов резервного копирования и репликации не сработал ни один: выгрузка базы молча падала из-за несовпадения версий, письма об ошибках отклонял почтовый сервер, а снимки дисков были включены не на тех серверах. Сервис простоял 18 часов. Данные вернули из ручного снимка: за шесть часов до аварии инженер сделал его, чтобы обновить тестовую среду1)2). Несколько копий защищают от потери одной из них, разные носители — от отказа конкретной технологии хранения, другая площадка — от потери здания. По отдельности эти меры не работают: три копии в одном дисковом массиве погибнут вместе с массивом, а администратор с доступом ко всем трём может удалить их разом3).
После пожара в дата-центре OVHcloud в Страсбурге в 2021 году оказалось, что «автоматические резервные копии» многих клиентов хранились в том же здании. Суд обязал оператора выплатить двум компаниям 250 тыс. евро: хранить все копии в одном месте противоречит современной практике4). Дедупликация (хранение повторяющихся блоков данных в одном экземпляре) усиливает эту зависимость: десять копий в таком хранилище опираются на одни и те же блоки и пропадут вместе с ним5).
Вчерашняя копия бесполезна, если данные удалили, заразили или испортили позавчера. Нужны копии за разные даты. Классическая схема «дед — отец — сын» (GFS): ежедневные копии («сын»), еженедельные полные («отец») и ежемесячные полные («дед»), причём недельные и месячные носители увозят на другую площадку6)7).
Ежедневная копия обычно содержит только изменения с момента предыдущей. Чтобы вернуть данные на вторник, нужны полная копия за воскресенье и изменения за понедельник и вторник8). Отсюда два следствия. Удалять старые копии нужно с учётом этих связей: если стереть воскресную полную копию как самую старую, более новые копии, которые на неё опираются, станут бесполезны. Поэтому системы резервного копирования удаляют недельный цикл целиком9). Кроме того, глубину хранения и допустимую потерю данных (RPO) задают отдельно: первая определяет, на сколько дней назад можно вернуться, вторая — за какой срок данные можно потерять10).
Диск даёт быстрое восстановление, лента — дешёвое долгое хранение на носителях, которые легко увезти. Схема «диск — диск — лента» (D2D2T) использует и то и другое. Правило 3-2-1 не требует ленты: копии могут быть на любых носителях, лишь бы они не зависели друг от друга11).
Чтобы восстановить сервер целиком, нужны системный раздел и системные настройки (в Windows — System State), сами данные, загрузочный диск или образ, с которого запускают восстановление, когда ОС не работает, и доступ к хранилищу копий12). Частая ошибка — сохранять только документы и рассчитывать, что из них удастся поднять сервер. Восстановление сервера целиком проверяют редко, поэтому впервые его часто делают в день аварии.
Зашифрованную копию без ключа не прочитать. Ключи нельзя хранить только в той инфраструктуре, которую защищают копии: если она погибнет, ключи пропадут вместе с ней13)14).
Копия нужна и самой системе резервного копирования. Её управляющий сервер знает, какие копии где лежат и какими ключами зашифрованы. Если он погиб, а его копии нет, сохранённые данные бывает невозможно найти и расшифровать15).
Если погибла основная площадка, восстановиться можно только из копии, увезённой на другую. Когда копии делают каждый день, а носители увозят раз в неделю, можно потерять данные за целую неделю16).
Проверка контрольных сумм показывает, что файлы копии не повреждены. Восстановление отдельного файла показывает, что его можно достать из копии. Ни то ни другое не доказывает, что из копии поднимется работающая система с приложением17)18). Надёжная проверка выглядит так: из копии запускают виртуальную машину в изолированной сети, проверяют, что приложение выполняет обычную рабочую операцию, и записывают, сколько заняло восстановление и все ли данные вернулись19).
Пробные восстановления заранее находят проблемы, описанные выше: задание не создаёт файлы, нет загрузочного диска, ключей или копии управляющего сервера, никто не знает порядок действий20)21). Рекомендуемый график: восстанавливать отдельные файлы ежемесячно, критичные системы и облачные данные — ежеквартально, раз в год проводить учения по аварийному восстановлению с участием руководства и исполнителей. Кроме того, проверку повторяют после каждого изменения сервера, приложения или настроек резервного копирования22).
Копия в облаке бесполезна, если её можно удалить с тем же доступом, что и рабочие серверы.
В 2014 году злоумышленник получил доступ к консоли AWS компании Code Spaces. Когда компания попыталась его заблокировать, он удалил серверы, снимки дисков, хранилища и образы виртуальных машин. Резервные копии лежали в том же аккаунте и пропали вместе со всем остальным. Компания закрылась23).
Данные в облаке теряют и без взлома: из-за ошибки в настройках, как у UniSuper, из-за случайного удаления, которое синхронизация за минуты разносит по всем устройствам, из-за автоматических скриптов с лишними правами. Две копии в одном аккаунте можно потерять одним действием. Копия должна быть недоступна тому, кто может стереть оригинал: отдельный аккаунт с минимальными правами и подтверждением опасных операций, хранилище с запретом удаления или с сохранением старых версий файлов, оповещения о массовых удалениях24).
Из-за вымогателей правило 3-2-1 расширили до 3-2-1-1-0. Добавились ещё одна копия, которую нельзя изменить или удалить либо которая отключена от сети, и требование, чтобы проверка восстановления проходила без ошибок25).
У копий, которые нельзя изменить, тоже есть слабые места. В них могли попасть уже испорченные или заражённые данные, а право снять защиту может оказаться у того же администратора, чью учётную запись взломали. Поэтому такие копии дополнительно изолируют и регулярно проверяют восстановлением26). В июле 2025 года агент Replit во время запрета на изменения принял пустые ответы базы за ошибку и удалил рабочую базу с записями о более чем 1 200 руководителях. Штатного способа отменить удаление не было, данные восстанавливали вручную27).
В обоих случаях копии можно было удалить вместе с рабочими данными, у агента было больше прав, чем нужно, а удаление прошло без подтверждения человеком. Запрет в инструкции агента не защищает: модель может его нарушить28). Защищают технические ограничения: разные учётные данные для тестовой и рабочей среды, подтверждение человеком любых удалений и копии, к которым у агента нет доступа. 43 % организаций признают, что внедряют ИИ быстрее, чем успевают защитить данные((Veeam, Data Trust and Resilience Report 2026, 14.04.2026. https://veeam.com/blog/data-trust-resilience-report.html)).