====== Почему резервные копии не спасают: правила, которые индустрия выработала за сорок лет ======

Компания может делать копии каждый день и в день аварии обнаружить, что восстанавливать нечего: копия сгорела вместе с оригиналом, месяцами не создавалась из-за незамеченной ошибки или не читается без потерянного ключа. Чтобы копия спасла данные, должны выполняться сразу несколько условий. Копия должна существовать, храниться отдельно от оригинала, иметь версии разной давности, позволять поднять работающую систему, быть проверенной и оставаться недоступной тому, кто уничтожил оригинал. Если не выполнено хотя бы одно условие, данные теряются.

===== Копия должна существовать и быть пригодной =====

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

В январе 2017 года инженер GitLab по ошибке удалил около 300 ГБ данных на рабочем сервере базы. Из пяти настроенных механизмов резервного копирования и репликации не сработал ни один: выгрузка базы молча падала из-за несовпадения версий, письма об ошибках отклонял почтовый сервер, а снимки дисков были включены не на тех серверах. Сервис простоял 18 часов. Данные вернули из ручного снимка: за шесть часов до аварии инженер сделал его, чтобы обновить тестовую среду((GitLab, Postmortem of database outage of January 31, 10.02.2017. https://about.gitlab.com/blog/postmortem-of-database-outage-of-january-31/))((GitLab, GitLab.com database incident — living notes, 01.02.2017. https://about.gitlab.com/blog/gitlab-dot-com-database-incident/)).

В опросе 2026 года участвовали более 900 руководителей ИТ и информационной безопасности. 90 % из них уверены, что смогут восстановить данные. Но среди пострадавших от вымогателей полностью вернули данные лишь 28 %, а в среднем удаётся вернуть 72 % данных((Veeam, Data Trust and Resilience Report 2026, 14.04.2026. https://veeam.com/blog/data-trust-resilience-report.html)).

===== Копия не должна погибнуть вместе с оригиналом =====

Правило 3-2-1: три копии, два типа носителей, одна копия на другой площадке((Veeam Software, Veeam Availability Suite v10: Configuration and Management, Course Guide / Student Guide, 2020.))((CommVault Systems, Core Fundamentals, Student Guide, Simpana, 2015.)). Несколько копий защищают от потери одной из них, разные носители — от отказа конкретной технологии хранения, другая площадка — от потери здания. По отдельности эти меры не работают: три копии в одном дисковом массиве погибнут вместе с массивом, а администратор с доступом ко всем трём может удалить их разом((Veeam Software, Veeam Availability Suite v10: Configuration and Management, Course Guide / Student Guide, 2020.)).

После пожара в дата-центре OVHcloud в Страсбурге в 2021 году оказалось, что «автоматические резервные копии» многих клиентов хранились в том же здании. Суд обязал оператора выплатить двум компаниям 250 тыс. евро: хранить все копии в одном месте противоречит современной практике((Data Center Dynamics, OVHcloud ordered to pay €250k to two customers who lost data in Strasbourg data center fire, 2023. https://datacenterdynamics.com)). Другая площадка должна быть достаточно далеко, чтобы пожар, потоп или отключение питания на основной её не затронули. Соседняя стойка или соседний корпус не подходят.

Несколько файлов бэкапа в одном хранилище не являются независимыми копиями: у них общее оборудование, площадка и права доступа((Veeam Software, Veeam Availability Suite v10: Configuration and Management, Course Guide / Student Guide, 2020.)). Дедупликация (хранение повторяющихся блоков данных в одном экземпляре) усиливает эту зависимость: десять копий в таком хранилище опираются на одни и те же блоки и пропадут вместе с ним((Veritas, Backup Exec Best Practices Guide, v4.3, 2017; Veritas, Backup Exec 16: Deduplication Option, Technical Brief, 2016.)).

===== Нужны копии разной давности =====

Вчерашняя копия бесполезна, если данные удалили, заразили или испортили позавчера. Нужны копии за разные даты. Классическая схема «дед — отец — сын» (GFS): ежедневные копии («сын»), еженедельные полные («отец») и ежемесячные полные («дед»), причём недельные и месячные носители увозят на другую площадку((Veritas, Backup Exec 20.2 Administrator's Guide.))((Veeam Software, Veeam Availability Suite v10: Configuration and Management, Course Guide / Student Guide, 2020.)).

Ежедневная копия обычно содержит только изменения с момента предыдущей. Чтобы вернуть данные на вторник, нужны полная копия за воскресенье и изменения за понедельник и вторник((Veeam Software, Veeam Availability Suite v10: Configuration and Management, Course Guide / Student Guide, 2020.)). Отсюда два следствия. Удалять старые копии нужно с учётом этих связей: если стереть воскресную полную копию как самую старую, более новые копии, которые на неё опираются, станут бесполезны. Поэтому системы резервного копирования удаляют недельный цикл целиком((CommVault Systems, Core Fundamentals, Student Guide, Simpana, 2015.)). Кроме того, глубину хранения и допустимую потерю данных (RPO) задают отдельно: первая определяет, на сколько дней назад можно вернуться, вторая — за какой срок данные можно потерять((Veeam Software, Veeam Availability Suite v10: Configuration and Management, Course Guide / Student Guide, 2020.)).

Диск даёт быстрое восстановление, лента — дешёвое долгое хранение на носителях, которые легко увезти. Схема «диск — диск — лента» (D2D2T) использует и то и другое. Правило 3-2-1 не требует ленты: копии могут быть на любых носителях, лишь бы они не зависели друг от друга((Veeam Software, Veeam Availability Suite v10 — размещение и вторичные копии; https://micronode.ru, D2D2T и дисковые массивы, 2022.)).

===== Из копии должна подниматься система целиком =====

Чтобы восстановить сервер целиком, нужны системный раздел и системные настройки (в Windows — System State), сами данные, загрузочный диск или образ, с которого запускают восстановление, когда ОС не работает, и доступ к хранилищу копий((Veritas, Backup Exec: Simplified Disaster Recovery, Blueprint, 2016.)). Частая ошибка — сохранять только документы и рассчитывать, что из них удастся поднять сервер. Восстановление сервера целиком проверяют редко, поэтому впервые его часто делают в день аварии.

Зашифрованную копию без ключа не прочитать. Ключи нельзя хранить только в той инфраструктуре, которую защищают копии: если она погибнет, ключи пропадут вместе с ней((Veritas Technical Education Services, Backup Exec 16: Security and Encryption Capabilities, Technical Brief, 2016.))((CommVault Systems, Implementation & Maintenance, Student Guide, 2015.)).

Копия нужна и самой системе резервного копирования. Её управляющий сервер знает, какие копии где лежат и какими ключами зашифрованы. Если он погиб, а его копии нет, сохранённые данные бывает невозможно найти и расшифровать((CommVault Systems, Implementation & Maintenance, Student Guide, 2015.)).

Если погибла основная площадка, восстановиться можно только из копии, увезённой на другую. Когда копии делают каждый день, а носители увозят раз в неделю, можно потерять данные за целую неделю((CommVault Systems, Implementation & Maintenance, Student Guide, 2015.)).

===== Копию нужно проверять восстановлением =====

Проверка контрольных сумм показывает, что файлы копии не повреждены. Восстановление отдельного файла показывает, что его можно достать из копии. Ни то ни другое не доказывает, что из копии поднимется работающая система с приложением((Veritas, Backup Exec Best Practices Guide, v4.3, 2017; Veritas, Backup Exec 16: Deduplication Option, Technical Brief, 2016.))((Veeam Software, Veeam Availability Suite v10: Course Guide — SureBackup, 2020.)). Надёжная проверка выглядит так: из копии запускают виртуальную машину в изолированной сети, проверяют, что приложение выполняет обычную рабочую операцию, и записывают, сколько заняло восстановление и все ли данные вернулись((Veeam Software, Veeam Availability Suite v10: Course Guide — SureBackup, 2020.)).

Пробные восстановления заранее находят проблемы, описанные выше: задание не создаёт файлы, нет загрузочного диска, ключей или копии управляющего сервера, никто не знает порядок действий((GitLab, Postmortem of database outage of January 31, 10.02.2017. https://about.gitlab.com/blog/postmortem-of-database-outage-of-january-31/))((GitLab, GitLab.com database incident — living notes, 01.02.2017. https://about.gitlab.com/blog/gitlab-dot-com-database-incident/))((Veritas, Backup Exec: Simplified Disaster Recovery, Blueprint, 2016.))((Veritas Technical Education Services, Backup Exec 16: Security and Encryption Capabilities, Technical Brief, 2016.)). Рекомендуемый график: восстанавливать отдельные файлы ежемесячно, критичные системы и облачные данные — ежеквартально, раз в год проводить учения по аварийному восстановлению с участием руководства и исполнителей. Кроме того, проверку повторяют после каждого изменения сервера, приложения или настроек резервного копирования((The Fulcrum Group, How to Test Your Business Backups Before You Need Them, 02.10.2026. https://thefulcrumgroup.com)).

Проверки стоят денег, их нужно закладывать в бюджет. В хранилище с дедупликацией проверка читает данные в исходном объёме: если записан 1 ТБ, который после дедупликации занимает 200 ГБ, проверка прочитает 1 ТБ. В облаке за чтение копии при проверке платят так же, как за восстановление((Veritas, Backup Exec Best Practices Guide, v4.3, 2017; Veritas, Backup Exec 16: Deduplication Option, Technical Brief, 2016.)).

===== Облачные копии и права доступа =====

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

В 2014 году злоумышленник получил доступ к консоли AWS компании Code Spaces. Когда компания попыталась его заблокировать, он удалил серверы, снимки дисков, хранилища и образы виртуальных машин. Резервные копии лежали в том же аккаунте и пропали вместе со всем остальным. Компания закрылась((Toc Consulting, Anatomy of a Real AWS Breach: Code Spaces, 2014. https://tocconsulting.fr/blog/code-spaces-2014-breach-anatomy)).

В мае 2024 года австралийский пенсионный фонд UniSuper хранил данные в двух регионах Google Cloud в рамках одной подписки. Сотрудники Google при настройке подписки оставили пустым одно поле, и система по умолчанию назначила ей срок в один год. Когда год истёк, подписка была автоматически удалена. Вместе с подпиской пропали виртуальные машины, диски, снимки и резервные копии в обоих регионах: удаление подписки затрагивает все регионы сразу. Фонд восстановился из копий, которые держал у другого провайдера((Google Cloud, Sharing details on a recent incident, 24.05.2024; Ars Technica, Google Cloud explains how it accidentally deleted a customer account, 23.05.2024.)).

Данные в облаке теряют и без взлома: из-за ошибки в настройках, как у UniSuper, из-за случайного удаления, которое синхронизация за минуты разносит по всем устройствам, из-за автоматических скриптов с лишними правами. Две копии в одном аккаунте можно потерять одним действием. Копия должна быть недоступна тому, кто может стереть оригинал: отдельный аккаунт с минимальными правами и подтверждением опасных операций, хранилище с запретом удаления или с сохранением старых версий файлов, оповещения о массовых удалениях((Toc Consulting, Anatomy of a Real AWS Breach: Code Spaces, 2014. https://tocconsulting.fr/blog/code-spaces-2014-breach-anatomy))((Google Cloud, Sharing details on a recent incident, 24.05.2024; Ars Technica, Google Cloud explains how it accidentally deleted a customer account, 23.05.2024.)).

===== Копия должна быть недоступна тому, кто уничтожил оригинал =====

Из-за вымогателей правило 3-2-1 расширили до 3-2-1-1-0. Добавились ещё одна копия, которую нельзя изменить или удалить либо которая отключена от сети, и требование, чтобы проверка восстановления проходила без ошибок((CNiC Solutions, Data Backup Strategies: The 3-2-1 Rule and Best Practices, 2026. https://cnicsolutions.com)). По тому же опросу 2026 года, у 56 % пострадавших от вымогателей данные были зашифрованы или украдены, а 44 % вернули меньше 75 % данных((Veeam, Data Trust and Resilience Report 2026, 14.04.2026. https://veeam.com/blog/data-trust-resilience-report.html)).

В 2017 году вирус NotPetya вывел из строя почти все Windows-серверы и компьютеры Maersk. Копии серверов нашлись, трёх–семидневной давности. А у контроллеров домена (серверов, через которые сотрудники входят в систему) отдельных копий не было: они только синхронизировали данные друг с другом, и вирус уничтожил все сразу. Случайно уцелел один контроллер в Гане: в момент атаки там отключилось электричество. Диск с него перевезли в Великобританию и по нему восстановили сеть. На 45 000 компьютеров и 4 000 серверов ушло около 10 дней, ущерб оценили в 250–300 млн долларов((Wired, The Untold Story of NotPetya, the Most Devastating Cyberattack in History, 2021; Marcoweb, Backup and Recovery: Maersk vs NotPetya, 16.09.2026.)).

У копий, которые нельзя изменить, тоже есть слабые места. В них могли попасть уже испорченные или заражённые данные, а право снять защиту может оказаться у того же администратора, чью учётную запись взломали. Поэтому такие копии дополнительно изолируют и регулярно проверяют восстановлением((CNiC Solutions, Data Backup Strategies: The 3-2-1 Rule and Best Practices, 2026. https://cnicsolutions.com)).

===== ИИ-агенты =====

ИИ-агенты с доступом к рабочим системам теряют данные по тем же причинам, что и люди в историях выше, только за секунды.

В апреле 2026 года агент Cursor на модели Claude Opus 4.6 выполнял задачу в тестовой среде компании PocketOS. Он решил, что проблему с учётными данными нужно исправить удалением диска на хостинге Railway, нашёл в постороннем файле токен с доступом ко всему аккаунту и удалил диск, ни у кого не спросив. За 9 секунд пропали рабочая база и её резервные копии: провайдер хранил их на том же диске. Последней пригодной копии было три месяца, восстановление заняло около 30 часов((https://meetcyber.net, An AI Agent Deleted a Live Production Database in Seconds, 04.2026; Zenity, AI agent database deletion PocketOS, 04.2026.)). В июле 2025 года агент Replit во время запрета на изменения принял пустые ответы базы за ошибку и удалил рабочую базу с записями о более чем 1 200 руководителях. Штатного способа отменить удаление не было, данные восстанавливали вручную((Tom's Hardware, AI coding platform goes rogue during code freeze and deletes entire company database, 07.2025; Fortune, 23.07.2025.)).

В обоих случаях копии можно было удалить вместе с рабочими данными, у агента было больше прав, чем нужно, а удаление прошло без подтверждения человеком. Запрет в инструкции агента не защищает: модель может его нарушить((https://meetcyber.net, An AI Agent Deleted a Live Production Database in Seconds, 04.2026; Zenity, AI agent database deletion PocketOS, 04.2026.)). Защищают технические ограничения: разные учётные данные для тестовой и рабочей среды, подтверждение человеком любых удалений и копии, к которым у агента нет доступа. 43 % организаций признают, что внедряют ИИ быстрее, чем успевают защитить данные((Veeam, Data Trust and Resilience Report 2026, 14.04.2026. https://veeam.com/blog/data-trust-resilience-report.html)).