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

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

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



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

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

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

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



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

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

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

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

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

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



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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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