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

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

Меня зовут Алексей Зотов, и у меня более чем 15-летний опыт в сфере резервного копирования. Я руковожу направлением ИТ-инфраструктуры в К2Тех. Средний стаж моей команды по бэкапу — 7–8 лет, и мы саппортили больше сотни заказчиков, инфраструктуры на тысячи хостов и петабайты данных. В общем, на рынке не первый день, но все это не означает, что со мной нельзя спорить в комментах. В конце концов, универсального подхода к резервному копированию не существует. Я лишь описываю общие принципы, но многое зависит от конкретного продукта.

Какие устройства выбрать для бэкапа?

Строго говоря, для хранения резервных копий используют два типа устройств: ленточные и дисковые. И кажется, будто в России уже нашли ответ на вопрос из заголовка. У нас 90% крупных компаний так или иначе используют ленты (вместе с дисками или сами по себе). Это притом, что скорый конец этого типа носителей предрекали уже много раз. Кажется, в первый раз на Хабре такие прогнозы появились около десяти лет назад, но вопреки всему, популярность «ленточек» растет. В прошлом году таких библиотек было продано на рекордные 153 эксабайта.

Подробнее о лентах для бэкапа

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

Я видел, как на Хабре еще в 2013-м жаловались на скорость восстановления с лент и говорили, что это делает их непригодными для бэкапа. Это не всегда так. Ленточные библиотеки хорошо масштабируются по производительности. Они состоят из набора кассет, робота, вставляющего эти кассеты, и набора ленточных приводов, которые эти кассеты читают или пишут. Если распараллелить потоки бэкапа или писать данные с нескольких клиентов параллельно, увеличение числа параллельно работающих приводов пропорционально повышает скорость резервного копирования и восстановления данных. Главное, уметь их нагрузить и использовать софт, поддерживающий мультистриминг.

У ленточных хранилищ другие недостатки: 

• Последовательный режим чтения и записи. Мотая ленту, вы можете либо записывать, либо считывать данные. Новый массив информации можно добавить только в конец предыдущей записи, а не в произвольное место кассеты.

• Не поддерживают оптимизации. Например, синтетическое резервное копирование, мгновенное восстановление данных и дедупликация — это такая legacy технология. Ты не можешь часто делать мелкие бэкапы, потому что по факту эти ленты нужно постоянно монтировать, размонтировать, перематывать. Поэтому ленты не подойдут, например, для бэкапа транзакционных логов с большого числа клиентов каждые 15–30 минут.

• Меньшая надежность. Со временем ленты могут размагнититься или рассыпаться. Старые поколения особенно уязвимы к проблемам при чтении. Это просто боль, когда заказчики складывают бэкапы на длительный срок и забывают, а через пять лет вспоминают, что им нужно восстановиться. Конечно, оказывается, что к этому времени лента рассыпалась. 

Хорошо помню случай, когда у заказчика лежали кассеты еще из позапрошлого десятилетия, 2000-х годов. Формально бэкап есть, но на самом деле практически нет шансов с него восстановиться. Это не говоря о софте, который ставился максимум на Windows Server 2003. 

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

15 лет назад в процессе профилактики мы советовали присмотреться и, возможно, заменить ленту после 300 монтирований, а после тысячи (по моему опыту) – часто появлялись ошибки чтения/записи. Это были SDLT кассеты или поколение LTO2-LTO3. Однако, начиная где-то с LTO5, даже счетчик в 3-4 тысячи монтирований ничего уже не значил, и число отказов снизилось на порядок. 

Подробнее о дисках для бэкапа

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

• Серверы со встроенными дисками (от 12 до 24 и более).

• СХД начального уровня.

• Специализированные устройства хранения, такие как HPE StoreOnce, Dell DataDomain или новый Tatlin.Backup от Yadro, который мы тестировали все лето. Спойлер: есть нюансы, но в целом все отлично. Ждите статью.

Все эти устройства в том или ином виде снабжены функциями сжатия, дедупликации и повышенной отказоустойчивости. В первом и втором случаях – это софтовые реализации (кстати, диски обычно используем, конечно же, NL-SAS, главное, с объемом знать меру и брать на 8/10/12 ТБ), а в третьем – на уровне СХД. Но, несмотря на все различия, основа всех этих систем — жесткие диски.

По сравнению с лентами, дисковые СХД имеют два ключевых преимущества:

• Произвольный доступ. В любой момент можно прочесть и восстановить любой блок. 

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

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

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

Ленточные библиотеки с десятками или сотнями кассет дают больше шансов на восстановление ошибочно удаленных данных. Некоторые кассеты могут не использоваться неделями, что увеличивает вероятность успешного восстановления информации. 

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

С дисковыми хранилищами такой исход маловероятен. Мы неоднократно сталкивались с ситуациями, когда бэкапы на дисках удалялись случайно или намеренно (для освобождения места). Когда заказчики обнаруживали, что удаленный бэкап им необходим, восстановить данные уже не представлялось возможным; на физическом носителе ничего не оставалось.

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

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

Облака как средство хранения бэкапов. Immutable Storage

Новый тренд в резервном копировании — создание условно отчуждаемых копий в облачных объектных хранилищах, совместимых с Amazon S3. Такую услугу предлагают разные компании, в том числе и коллеги из K2 Cloud. Да, по сути эти те же жесткие диски, но расположенные вне вашей инфраструктуры. В теории они обладают надежностью дисковых систем, но обычно стоят немного дешевле СХД в вашей серверной.

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

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

Современные объектные хранилища с поддержкой программного копирования предлагают функцию Immutable Storage. Это реализация принципа WORM (write once, read many). После записи данных их невозможно удалить даже с правами администратора в течение заданного периода.

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

Если Immutable Storage недоступна, можно защитить резервные копии альтернативным способом. Создайте дополнительные облачные аккаунты с отдельными паролями и логинами (двухфакторка — наше все!). Периодически загружайте туда резервные копии, а затем разрывайте связь с этим хранилищем. Но такой метод, конечно, повышает цену хранения данных и вероятность утечки.

Как частота и время хранения бэкапов влияют на стоимость хранения

И вновь мы возвращаемся к вопросу расходов на хранение бэкапов. Зачастую клиенты принимают необъективные решения при выборе оборудования из-за неправильной оценки частоты и сроков хранения резервных копий.

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

Грубо прикинем, что 1 ГБ хранения в месяц может стоить 2–3 рубля. Цифра кажется небольшой, но это пока. 

У нас такое бывало не раз: заказчик просит делать бэкапы каждую неделю и хранить их минимум месяц. Мы предлагаем схему: полный бэкап в выходные, инкрементальные — каждый день. За месяц накапливается 4 полные копии. Заказчик хочет хранить месячные копии год. Это еще 12 полных копий. Окей. А вдобавок он хочет хранить годовые копии еще 5 лет. Хорошо. Еще 5 полных копий.

В итоге получается 4+12+5 — 21 копия, которую нужно постоянно хранить. А потом оказывается, что это бэкап фронтенда на 100 терабайт. Получается больше 2 петабайт хранилища только под резервные копии!

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

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

• Создайте регламент резервного копирования. Для этого классифицируйте все системы: критически важные для миссии, критически важные для бизнеса, важные для бизнес-целей, тестовые среды разработки. Затем для каждой категории определите целевое время восстановления (RTO), целевую точку восстановления (RPO), сроки хранения и частоту сохранения. 

• Храните долго только «золотые копии», а не ежемесячные бэкапы. «Золотые копии» стоит хранить как минимум год, а ключевые данные, возможно, до 5–10 лет. Но больший срок — обычно лишняя нагрузка, тем более что эти данные с высокой долей вероятности уже никогда не будут восстанавливаться. Разве что вы работаете в архиве типа Wayback Machine.

• Обязательно нужно создать регламент для процедур тестирования восстановления данных. Если тестирование не проведено ни разу за 5 лет, велика вероятность, что при восстановлении что-то пойдет не так. Кроме того, нужно учитывать, что срок резервных копий может превышать срок плановой замены оборудования и ПО в компании. Бывает так, что требуется восстановить информацию с архивного носителя, а соответствующее оборудование и ПО приходится искать в музее.
  В случае с тем заказчиком мы выяснили, что достаточно хранить данные год, а не 5-10 лет. Исключение составили несколько критически важных файлов. Кроме того, оказалось, что можно бэкапить не все системы, а только часть. Тогда вдумчивый анализ помог снизить затраты на оборудование и стоимость хранения почти в десять раз.

• Микшируйте различные системы хранения. Для оперативных бэкапов, которые хранятся 2–4 недели, оптимальный выбор — диски. Если хочется хранить данные на них дольше, необходимо использовать дедупликацию (софтовую или на базе специализированного хранилища). Однако классический подход к долгосрочному хранению — это все-таки ленты, а более гибкая альтернатива — облачные хранилища.

• Соблюдайте правило нескольких площадок. Не самый лучший, но минимально допустимый подход — перекрестное хранение копий на удаленной площадке, например, ЦОД и РЦОД. Стандартный, надежный подход — хранение на обеих площадках (дедупликация снизит нагрузку на канал, а специализированные устройства позволят передавать бэкапы напрямую). При идеальном раскладе к этой паре копий добавляется еще одна отчуждаемая — облако или кассеты, вывезенные на третью локацию.

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

To be continued…

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

Традиционно для бесед о бэкапе я всегда доступен по адресу: alzotov@k2.tech

Больше про бэкапы и СХД:

От носителей до регламентов: как построить безопасную архитектуру бэкапов

Тестируем СХД ExaGrid EX18: получилось ли заменить Dell DataDomain и HPE StoreOnce?