Что такое резервное хранилище?

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

Производительность восстановления особенно важна во время атак программ-вымогателей. Согласно отчету Sophos «The State of Ransomware 2026», основанному на опросе 2158 руководителей в сфере ИТ и кибербезопасности, организации использовали резервные копии для восстановления данных в 66% атак, при которых данные были зашифрованы (по сравнению с 54% в отчете за 2025 год). Но наличие резервных копий — это лишь часть дела. Организациям также необходимо убедиться, что эти копии защищены от компрометации и могут быть восстановлены достаточно быстро для удовлетворения бизнес-требований.

В этой статье рассматривается, как резервное хранилище поддерживает восстановление, основные типы резервных хранилищ, емкость и хранение, защита от программ-вымогателей, тестирование восстановления, а также способы оценки резервного хранения для баз данных, включая то, какое место в этом занимает Everpure.

Что охватывает резервное хранилище

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

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

Это делает целевое время восстановления (RTO) важнейшим фактором. RTO определяет максимальное допустимое время для восстановления системы или службы после сбоя. Даже когда резервные копии не повреждены, низкая производительность хранилища может увеличить время восстановления за пределы допустимых лимитов, увеличивая время простоя и влияние на бизнес.

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

Снимки (snapshots) на основном массиве могут ускорить восстановление после определенных сбоев, но они дополняют, а не заменяют независимые резервные копии. Программы-вымогатели, административные ошибки или сбои инфраструктуры могут скомпрометировать основное хранилище и его снимки. В рекомендациях Microsoft по SQL Server рекомендуется хранить резервные копии баз данных в отдельном физическом расположении или на отдельном устройстве от файлов базы данных. Подробнее о том, как эти подходы поддерживают различные требования к восстановлению, см. в разделе «Snapshots vs. Backups vs. Replication: What’s the Difference?»

Типы резервных хранилищ

Корпоративные системы резервного копирования обычно объединяют несколько типов резервных хранилищ, а не полагаются только на одно. Каждый тип подходит для определенной части окна восстановления.

Объектное хранилище хранит данные как самодостаточные объекты, к которым осуществляется доступ через API, что подходит для больших наборов данных и политик блокировки объектов. Резервное копирование как услуга (BaaS) переносит целевое хранилище резервных копий и большую часть его работы на сторону провайдера.

Распространенным шаблоном является многоуровневая структура. Последние точки восстановления находятся на самом быстром хранилище, где происходит большинство восстановлений. Более старые копии перемещаются в объектное хранилище или на ленту, где их хранение обходится дешевле и они требуются реже.

Управление емкостью и сроком хранения резервных копий

Емкость и срок хранения — это два параметра, которые определяют стоимость среды резервного копирования и глубину восстановления.

Планирование емкости

Объем резервного хранилища, необходимый для среды, зависит от нескольких переменных:

• Размер защищенных данных: объем данных базы данных, включенных в каждую резервную копию, который может отличаться от выделенного размера базы данных. Для SQL Server фактический размер резервной копии зависит от созданных страниц данных, типа резервной копии, настроек сжатия и шифрования. Используйте исторические размеры резервных копий для оценки требований к хранилищу.
• Скорость изменения: объем данных, изменяющихся между резервными копиями, что определяет размер инкрементных, дифференциальных резервных копий и копий журналов.
• Точки восстановления: количество полных и промежуточных резервных копий, хранящихся одновременно.
• Срок хранения: как долго каждая копия хранится до истечения ее срока действия.
• Сокращение данных: насколько deduplication и сжатие уменьшают сохраненные копии.

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

Политика хранения резервных копий

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

Хранение также определяет окно отката. CISA рекомендует иметь возможность откатывать данные по крайней мере на семь дней, а слишком короткий срок хранения может не оставить ни одной чистой копии, созданной до необнаруженной проблемы.

Текущее управление

Резервное хранилище требует такого же мониторинга, как и производственное хранилище, с другим набором сигналов:

• Успех заданий: неудачные или частично выполненные задания резервного копирования, выявленные до того, как следующее восстановление станет зависимым от них.
• Запас емкости: свободное пространство относительно тенденции роста, чтобы не приходилось сокращать сроки хранения ради высвобождения места.
• Измеренное время восстановления: фактическая продолжительность восстановления по результатам тестов по сравнению с целевыми показателями RTO.
• Перемещение между уровнями: копии, перемещаемые между уровнями по расписанию, соответствующему политике хранения.

Защита резервного хранилища от программ-вымогателей

Злоумышленники также нацеливаются непосредственно на резервное хранилище. Согласно исследованию Sophos за 2024 год, охватившему 2974 специалистов по ИТ и кибербезопасности, организации которых подверглись атакам программ-вымогателей, 94% заявили, что злоумышленники пытались скомпрометировать их резервные копии во время атаки, и 57% этих попыток увенчались успехом. Защита является частью управления резервным хранилищем, а не отдельным проектом.

Правило 3-2-1-1-0

CISA описывает правило 3-2-1 как три копии важных файлов на двух разных типах носителей информации, причем одна копия хранится за пределами офиса. Широко используемое расширение 3-2-1-1-0 добавляет неизменяемую или изолированную (air-gapped) копию и ноль ошибок при проверенных восстановлениях:

• 3 копии данных
• 2 разных носителя информации
• 1 копия за пределами офиса
• 1 копия неизменяема или изолирована
• 0 ошибок при проверенных восстановлениях

Неизменяемые и неизгладимые копии

Неизменяемая резервная копия не может быть изменена в течение периода хранения. Возможность ее удаления зависит от реализации. В документации AWS описаны два S3 Object Lock режима: в режиме управления (governance mode) пользователи с особыми правами могут изменять настройки блокировки или удалять объекты, тогда как в режиме соответствия (compliance mode) защищенная версия объекта не может быть перезаписана или удалена ни одним пользователем, включая пользователя root учетной записи, до окончания срока хранения.

Эта разница лежит между понятиями неизменяемости (immutable) и неудаляемости (indelible). Неудаляемую копию администратор не может удалить до истечения срока ее хранения. Данное различие имеет наибольшее значение в случае компрометации учетных данных администратора.

Изолированные среды (Air gaps) представляют собой отдельный элемент управления. В средах резервного копирования изоляция обычно означает отделение носителей или сети резервного копирования от производственных систем. Изоляция ограничивает круг лиц, имеющих доступ к копии, а неизменяемость ограничивает то, что с ней можно сделать, поэтому эти два метода обычно применяются в комплексе.

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

Защита также распространяется на саму систему резервного копирования:

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

Специальные средства управления безопасностью систем хранения данных описаны в документе NIST SP 800-209, Security Guidelines for Storage Infrastructure, опубликованном в 2020 году. Проект редакции Rev. 1, выпущенный 22 июля 2026 года, дополнен разделом, посвященным угрозам для резервных копий и процессу их создания. Эти же практики применимы независимо от того, разведено ли хранилище резервных копий локально или в облаке.

Тестирование восстановления, а не только резервного копирования

Ноль («0») в формуле 3-2-1-1-0 присутствует потому, что успешное задание резервного копирования не гарантирует работоспособность восстановления. В стандарте NIST Cybersecurity Framework (CSF) 2.0, опубликованном в феврале 2024 года, в качестве результата PR.DS-11 указано создание, защита, обслуживание и тестирование резервных копий, а в результате RC.RP-03 — проверка целостности резервной копии перед восстановлением.

В рекомендациях корпорации Microsoft по работе с SQL Server этот подход сформулирован напрямую: стратегии восстановления не существует, пока резервные копии не протестированы. Рекомендуется выполнять тестовое восстановление каждого типа используемых резервных копий, запускать проверку DBCC CHECKDB для восстановленной базы данных и фиксировать время, затрачиваемое на каждое тестовое восстановление.

Программа тестирования восстановления для баз данных обычно включает в себя:

• Полное восстановление: восстановление полной базы данных в тестовую систему с проверкой на согласованность
• Восстановление на определенный момент времени (Point-in-time recovery): восстановление на заданный момент с использованием полных, дифференциальных резервных копий и журналов транзакций
• Скорость восстановления в сравнении с RTO: измеренная продолжительность от начала восстановления до получения работоспособной базы данных
• Параллельное восстановление: одновременное восстановление нескольких систем, как того требует масштабный инцидент

CISA рекомендует проводить запланированные тесты восстановления. График таких тестов должен быть закреплен в регламенте и зависеть от критичности каждой системы. Регистрация даты, набора резервных копий, продолжительности и результатов каждого теста предоставляет аудиторам необходимые доказательства и показывает, не увеличивается ли время восстановления по мере роста объемов данных.

Как оценивать хранилище резервных копий для рабочих нагрузок баз данных

Универсального идеального хранилища для резервных копий не существует. Правильный выбор зависит от требуемого для каждой системы значения RTO, периода хранения, установленного бизнесом, и угроз, от которых должна защитить резервная копия. На практике варианты можно разделить с помощью следующих вопросов:

• Пропускная способность восстановления под нагрузкой: сколько времени занимает полное восстановление типичной базы данных (измеренное, а не заявленное значение) при одновременном выполнении других рабочих задач?
• Защита от удаления: может ли администратор с полными правами удалить копии или сократить срок их хранения, и какое для этого требуется подтверждение?
• Фактическое сокращение объема данных: какой уровень уменьшения размера достигается целевым хранилищем на реальных сжатых и зашифрованных резервных копиях баз данных?
• Интеграция: работает ли решение с используемым ПО для резервного копирования и встроенными инструментами, такими как Oracle Recovery Manager (RMAN) и команда BACKUP в SQL Server?
• Затраты по мере роста данных: как емкость, сроки хранения и любые расходы на передачу данных соотносятся с горизонтом планирования?
• Место восстановления: куда будут восстанавливаться данные, если основное хранилище недоступно или заблокировано для проведения криминалистического исследования?

Как Everpure помогает в управлении хранилищами для резервных копий

Решение Everpure™ FlashBlade служит целевым хранилищем для встроенных инструментов баз данных без использования проприетарных агентов: Oracle RMAN выполняет запись по протоколу Direct NFS (dNFS), а резервные копии SQL Server T-SQL записываются на ресурсы SMB или в хранилище S3. Согласно результатам валидации Everpure, опубликованным в феврале 2026 года, скорость восстановления баз данных Oracle RMAN на массивы FlashBlade превышала 60 ТБ/ч, а восстановление SQL Server в восьми параллельных экземплярах превышало 113 ТБ/ч. Технология FlashBlade Rapid Restore увеличивает скорость восстановления данных без изменения ПО резервного копирования и интегрируется с целым рядом партнерских программных решений для бэкапа.

Для оптимизации емкости хранилища резервных копий технология Purity DeepReduce™ выполняет сокращение данных на основе анализа схожести на массивах FlashBlade//E™ и FlashBlade//S200 R2. В ходе лабораторных испытаний Everpure, опубликованных в июне 2026 года, функция Purity DeepReduce сократила объем несжатых наборов резервных копий SQL Server почти на 55%. Для резервных копий, уже сжатых средствами SQL Server, было обеспечено дополнительное уменьшение объема примерно на 37%, что составило общую эффективную степень сокращения около 68%.

Снимки SafeMode™ Snapshots являются неудаляемыми и защищенными от изменений. Ручное удаление заблокировано на период настроенной задержки удаления, а любые изменения политик защиты снимков требуют многосторонней авторизации с привлечением службы поддержки Everpure, поэтому скомпрометированная учетная запись администратора не сможет самостоятельно удалить копии восстановления. Функция SafeMode встроена в системы FlashBlade и FlashArray™ без необходимости приобретения дополнительных лицензий, и компания Everpure публикует руководства по резервному копированию и восстановлению баз данных Oracle RMAN с использованием массивов FlashArray.

В случаях, когда основные массивы недоступны в результате атаки или сбоя, дополнительное соглашение об уровне обслуживания (SLA) Evergreen//One™ Cyber Recovery and Resilience гарантирует отправку чистых массивов для восстановления на следующий рабочий день в Северной Америке и регионе EMEA, 48 часов на финализацию плана восстановления и скорость передачи данных 8 ТиБ/ч.

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

Заключение

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

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

Часто задаваемые вопросы о хранилищах резервных копий

Какова оптимальная стратегия хранения резервных копий?

Большинство корпоративных стратегий сочетают в себе несколько уровней. Свежие точки восстановления размещаются на быстрых накопителях для регулярного и масштабного восстановления, в то время как более старые копии перемещаются в объектное хранилище или на ленточные носители для недолгого или долгосрочного архивного хранения. Правило 3-2-1-1-0 добавляет сюда наличие копии на удаленной площадке, неизменяемой или изолированной копии, а также проверенных процедур восстановления. Стратегия считается полной только тогда, когда измеренное время восстановления отвечает целевому времени восстановления (RTO) каждой системы.

Что такое масштабируемое решение для хранения резервных копий?

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

Как резервное копирование может масштабироваться по мере роста корпоративных данных?

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

Что такое корпоративное резервное копирование?

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