СофтХабрахабр

Бэкап наготове: разрушаем мифы в честь праздника

Оно просто должно быть в любой серьезной компании, вот и всё. Резервное копирование не относится к модным технологиям, о которых кричат из каждого утюга. В самом начале практики делал резервное копирование практически вручную, скриптами, которые просто копировали файлы. У нас в банке бэкапится несколько тысяч серверов – это сложная, интересная работа, о некоторых тонкостях которой, а также о типичных заблуждениях относительно бэкапов как раз и хочется рассказать.
Этой тематикой я занимаюсь уже почти 20 лет, из них последние 2 года – в Промсвязьбанке. А уже потом пришло время специализированного ПО, в первую очередь Veritas Backup Exec, который сейчас называется Symantec Backup Exec. Потом в Windows появились удобные инструменты: утилита Robocopy для подготовки файлов и NT Backup для копирования. Так что с бэкапами знаком давно.

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

Самое же типичное обращение к бэкапам – это восстановление сохраненной копии баз данных для развертывания различных тестовых систем, клонов для разработчиков.

Вот самые известные из них. Вокруг резервного копирования существует несколько типичных мифов, которые давно пора развеять.

Миф 1. Бэкап давно уже всего лишь мелкая функция внутри систем безопасности или хранения

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

Плюс ролевая модель доступа к системе резервного копирования позволяет делегировать часть полномочий администраторам целевых систем по управлению резервными копиями.

Миф 2. Когда есть RAID, бэкап уже не нужен

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

Вот standby-сервер с отложенной записью – да, может выручить, если ошибка обнаружена до того, как была синхронизирована. От логических ошибок, которые были допущены пользователями системы, избыточность и репликация не спасает. Тут поможет только вовремя сделанный бэкап. А если момент упущен? С учетом того, что логические ошибки – самые частые, старый добрый бэкап остается проверенным и нужным средством. Если известно, что данные изменились вчера, можно восстановить систему по состоянию на позавчера и вытащить из нее нужные данные.

Миф 3. Бэкап – это то, что делается раз в месяц.

Частота резервного копирования – это настраиваемый параметр, в первую очередь зависящий от требований к системе резервного копирования. Вполне реально найти данные, которые практически никогда не меняются и особо не важны, их потеря не будет критичной для компании.
Их, действительно, можно бэкапить раз в месяц и даже реже. А вот более критичные данные сохраняются чаще, в зависимости от показателя RPO (Recovery point objrective), задающего допустимую потерю данных. Это может быть раз в неделю, раз в сутки или даже несколько раз в час. У нас это журналы транзакций из СУБД.

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

Миф 4. Объем копий беспрестанно растет и занимает любое выделенное пространство полностью

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

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

Миф 5. Начался бэкап – всё повисло

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

Например, СУБД Oracle позволяет отдавать несколько потоков, по количеству доступных процессоров, пока скорость передачи не упрется в ограничение пропускной способности сети. Бэкап может идти в один или несколько потоков, в зависимости от того, поддерживает ли резервируемая система многопоточность.

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

Кроме того, трафик может передаваться не через сеть, а через SAN.

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

Миф 6. Запустил систему резервного копирования – вот тебе и отказоустойчивость

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

Потеря данных с момента бэкапа до момента поломки гарантирована, а данные на новый сервер могут заливаться несколько часов (или дней, как повезет). Надеяться, что бэкап восстановит все данные и быстро поднимет упавший сервис не стоит. Поэтому имеет смысл создавать полноценные отказоустойчивые системы, не перекладывая все на бэкап.

Миф 7. Настроил один раз бэкап, проверил что работает. Остается только логи смотреть

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

И немного о работе сисадмина

В ручном режиме никто данные уже давно не копирует. Современные СРК умеют бэкапить практически всё, стоит только как следует его настроить. Если добавился новый сервер – прописать политики: выбрать контент, который будет бэкапиться, указать параметры хранения, и применить расписание.

Сотрудники, поддерживающие работоспособность системы резервного копирования, без дела не сидят.
При этом работы все равно немало из-за обширного парка серверов, среди которых и базы данных, и почтовые системы, и кластеры виртуальных машин, и файловые ресурсы как на Windows, так на Linux/Unix.

В честь праздника хочется пожелать всем админам крепких нервов, четкости движений и бесконечного пространства под хранение бэкапов!

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть