Новости

Сбой Microsoft 365: какое локальное хранилище взять для резервных копий

Дмитрий Потоцкий 1 мин чтения
Сбой Microsoft 365: какое локальное хранилище взять для резервных копий

Когда Microsoft 365 недоступен, копия в том же облачном контуре не вернёт почту и файлы в офис. В материале Microsoft для бизнеса указано: общедоступным облаком пользуются 43% малых и средних компаний. Для них второй контур хранения — не замена облаку, а возможность восстановить данные без ожидания провайдера.

Возвращать всю инфраструктуру в офис не нужно. Достаточно вынести одну резервную копию на локальный сервер или NAS, а ещё одну оставить за пределами офиса. Для компании с 5 ТБ данных разберём два варианта: одиночное хранилище на 9,6 ТБ полезной ёмкости и кластер из пяти серверов.

Локальная копия страхует от недоступности облака, но не от пожара в офисе

Схема 3–2–1 требует трёх копий данных на двух типах носителей, причём одна копия хранится за пределами основной площадки. Это правило приводит VK Cloud в разборе способов хранения резервных копий.

Пять серверов локального кластера

Для Microsoft 365 схема выглядит так:

  • рабочие данные находятся в Microsoft 365;
  • локальная копия хранится на сервере или NAS в офисе;
  • третья копия уходит на другую площадку или к независимому облачному провайдеру.

Локальный узел сокращает время восстановления при недоступности Microsoft 365. Третья копия нужна уже против другой группы рисков: кражи оборудования, пожара, шифровальщика и ошибки администратора, которая затронула основное хранилище вместе с локальной копией.

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

Для 5 ТБ исходных данных нужно 9,6 ТБ полезной ёмкости

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

Возьмём типовую компанию со следующими допущениями:

  • исходный объём — 5 ТБ;
  • за сутки меняется 2%, то есть 0,1 ТБ;
  • срок хранения — 30 ежедневных точек;
  • свободный запас — 20%.

Расчёт:

(5 ТБ + 5 ТБ × 2% × 30 дней) × 1,2 = 9,6 ТБ

Это полезная ёмкость после учёта избыточности, а не сумма цифр на корпусах дисков. Если массив теряет половину сырой ёмкости на зеркалирование, для 9,6 ТБ потребуется не меньше 19,2 ТБ сырого пространства. Конкретное число дисков зависит от выбранной схемы защиты и допустимого времени восстановления массива.

Формула переносится на другую нагрузку. При тех же 5 ТБ и хранении 60 точек изменения займут уже 6 ТБ:

(5 ТБ + 5 ТБ × 2% × 60 дней) × 1,2 = 13,2 ТБ

Исходный объём вырос вдвое — удваиваются базовые данные и суточные изменения. Срок хранения вырос вдвое — удваивается только часть, отведённая под изменения.

Один сервер подходит для быстрого восстановления, но сам остаётся точкой отказа

Документация CyberStorage задаёт для одиночного локального узла рекомендуемый ориентир: 6 ядер процессора и 16 ГБ оперативной памяти. Минимум ниже — 6 ядер и 12 ГБ, но экономия 4 ГБ оставляет меньше памяти служебным процессам и кэшу.

Избыточность дисков не превращает один сервер в отказоустойчивый кластер. В документации CyberStorage прямо указано: при схеме 3+2 и области отказа «диск» поломка всего хоста может привести к потере данных. Контроллер, системная плата и блок питания остаются общими для всех дисков.

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

Пять узлов сохраняют копии после отказа одного сервера

Если локальная копия должна оставаться доступной при отказе хоста, CyberStorage приводит схему из пяти серверов. На каждом узле стоят отдельный системный диск, диск метаданных и десять дисков данных.

Три сервера управления получают по 8 ядер и 24 ГБ памяти. Два подчинённых — по 6 ядер и 16 ГБ. Это рекомендуемые параметры CyberStorage, а не расчёт для конкретной скорости копирования.

Пять узлов убирают одиночный сервер из списка критических точек, но требуют места, питания и охлаждения для 60 дисков: по 12 на каждый хост с учётом системного диска и диска метаданных. До размещения проверь климат и электропитание серверной. Офисная кладовая без притока воздуха для такой плотности оборудования не подходит.

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

Диски не помогут, если программа копирует только почтовые ящики

Перед закупкой составь перечень объектов Microsoft 365, которые нужно вернуть после сбоя. Одна отметка «Microsoft 365 backup» не подтверждает защиту почты, архивов, групп, сайтов и Teams.

В сравнительной таблице Acronis локальный агент для Office 365 работает на машине Windows с доступом в интернет и сохраняет копии в локальную или сетевую папку. При этом он защищает только пользовательские и общие почтовые ящики Exchange Online.

Архивные почтовые ящики этот агент не копирует. Новые пользователи, группы, сайты и команды автоматически под защиту не попадают. Значит, сервер может исправно принимать копии, но нужного сайта SharePoint или архива сотрудника на нём не окажется.

До оплаты оборудования зафиксируй четыре пункта:

  • какие объекты Microsoft 365 входят в резервную копию;
  • как система подхватывает новых пользователей, группы и сайты;
  • где хранится третья копия;
  • какой объект и за какое время нужно восстановить на проверке.

Последний пункт отделяет резервную копию от набора файлов, который никто не пробовал вернуть в работу.

Спецификация под задачу

Для расчёта берём 5 ТБ исходных данных, 2% изменений в сутки, 30 ежедневных точек и запас 20%.

Одиночное локальное хранилище

  • Процессор: 6 физических ядер — рекомендуемый ориентир CyberStorage.
  • Память: 16 ГБ.
  • Ёмкость: от 9,6 ТБ после учёта выбранной дисковой защиты.
  • Диски: отдельный системный накопитель и массив данных; число и объём дисков подбираются так, чтобы после избыточности оставалось не меньше 9,6 ТБ.
  • Сеть: пропускная способность должна укладывать полное восстановление в допустимое время. Например, перенос 5 ТБ за восемь часов требует средней полезной скорости около 174 МБ/с: 5 000 000 МБ ÷ 28 800 с.
  • Питание: ИБП и, если платформа поддерживает, два блока питания.
  • Внешний контур: ещё одна копия вне офиса.

Это вариант для малого бизнеса, которому нужно локально восстановить данные после недоступности Microsoft 365. Отказ самого сервера он не переживает.

Кластер с отказоустойчивостью по узлам

  • Пять физических серверов.
  • Узлы 1–3: по 8 ядер и 24 ГБ памяти.
  • Узлы 4–5: по 6 ядер и 16 ГБ памяти.
  • На каждом узле: системный диск, диск метаданных и 10 дисков данных.
  • Отдельное резервирование питания и сети для всех пяти машин.
  • Размер дисков: по расчёту полезной ёмкости кластера с учётом выбранной схемы избыточности.
  • Размещение: серверное помещение с рассчитанными питанием, охлаждением и местом под 60 дисков.

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

Выбор сводится к одному порогу. Если после поломки локального узла компания может дождаться ремонта или загрузить копию с удалённой площадки, бери одиночный сервер на 6 ядер, 16 ГБ памяти и 9,6 ТБ полезного пространства. Если даже в этот момент восстановление должно идти локально, закладывай пять узлов. В обоих случаях закупка заканчивается не установкой дисков, а пробным восстановлением почтового ящика, файла и одного рабочего объекта Microsoft 365.