Нет бэкапа — жди факапа, или Почему важно вовремя делать резервные копии

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

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

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

А теперь, когда с теорией разобрались, давайте перейдём к практике!

Не повторяйте чужие ошибки!

Большинство системных администраторов при планировании архитектуры совершают типовые ошибки. Вот несколько распространённых заблуждений:

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

1. «Сервер будет работать без сбоев и резервные копии не нужны». Если бы всё было так! Например, пользователь обнаружил, что у него не работает сервер баз данных, а сам сервер периодически виснет. После проверки оказалось, что на жёстком диске машины было множество ошибок чтения и записи. Ресурс жёсткого диска не бесконечен. На его поверхности появились области, чтение информации с которых было невозможно. Это привело к появлению битых секторов. К сожалению, часть информации была безвозвратно утеряна без возможности восстановления.

2. «Если я закажу самое дорогое и надёжное железо, то у меня никогда и ничего не сломается». Это тоже не всегда совпадает с реальным положением дел. И, чтобы доказать точку зрения, поделимся ещё одним случаем. Сисадмин одной компании, казалось бы, предусмотрел практически всё: процессор последнего поколения, оперативная память с поддержкой контроля чётности (ECC), RAID1-массив из SSD.

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

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

3. «Если мы будем использовать кластеризацию, то все наши данные будут под защитой». Это тоже неправда, и мы расскажем почему. Руководство одной организации захотело сделать так, чтобы их сайт был доступен всегда, вне зависимости от проблем в дата-центрах. Для этого специалисты создали отказоустойчивый кластер на множестве узлов в разных дата-центрах. Эту систему протестировали: по очереди выключали серверы и сегменты сети, имитировали отключение дата-центра. Сайт при этом работал в любых условиях.

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

Что учитывать при проектировании системы бэкапов

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

Как часто нужно создавать резервные копии

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

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

Сколько должно длиться резервное копирование

Для начала определимся, каким бывает резервное копирование. Чаще его разделяют на полное и инкрементальное.

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

→ большой объём информации требует серьёзной дисковой подсистемы для хранения  резервных копий.

→ выполнение резервного копирования будет происходить очень долго.

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

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

Зачем нужен план восстановления

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

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

Что такое неконсистентность данных и к чему она может привести

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

Подобные случаи неконсистентности бывают при выполнении копирования базы данных утилитой mysqldump  с ключом --skip-lock-tables. Также, если при создании копии выполняется архивирование в многотомный архив и по какой-то причине часть архива утеряна, то резервную копию можно считать неконсистентной.

Сколько должно стоить резервное копирование

Расчёт стоимости резервного копирования можно сравнить со страхованием на случай непредвиденной ситуации. Поэтому рекомендуется выделять на бэкапы 1% от прибыли компании.

Формула расчёта выглядит так: S (сумма в месяц) = 30 (количество дней в месяце) * X * 24 (количество часов в сутках) * 0,01, где X — прибыль компании в час.

Возьмём для примера некую абстрактную компанию, которая зарабатывает 100 000 рублей в час. Таким образом, формула будет выглядеть вот так: S (сумма в месяц) = 30 * 100 000 * 24 * 0,01 = 720 000 (бюджет системы резервного копирования). Если система стоит дороже, есть повод задуматься, обоснованы ли траты.

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

Для создания систем резервного копирования подходит множество инструментов, начиная от простых утилит копирования SCP, CP до сложных многоуровневых распределенных систем резервного копирования: Bareos, Bacula, Acronis TrueBackup. Нужно отметить, что панели управления, такие как ISPmanager, Cpanel, Plesk, включают встроенные скрипты для создания резервных копий. Также некоторые CMS, такие, как «1С-Битрикс», Joomla и WordPress, включают встроенные инструменты для бэкапов.

Некоторые хостинг-провайдеры (в том числе и мы) предлагают комплексные решения. Так, каждый клиент REG.RU, заказавший услугу «Администрирование сервера», автоматически подключается к системе резервного копирования. Она децентрализована и использует несколько серверов управления, которые дублируют друг друга. Для хранения данных мы используем профессиональные, многодисковые шасси Supermicro. Для бэкапов баз данных применяются наши собственные разработки на основе утилит mysqldump, rsync, xtrabackup.

Для решения задачи мы разработали несколько планов.

Первый план копирования — хранение информации 14 суток

По выходным дням (либо дням, согласованным с клиентом) выполняется полное копирование всех файлов. В остальные дни по ночами мы производим инкрементальное копирование. Резервное копирование баз данных также производится 1 раз в сутки, в ночное время. По желанию клиента время начала копирования может быть изменено. Инструмент для копирования баз данных выбирается индивидуально для каждого проекта.

Второй план копирования — хранение информации 7 суток

Условия те же, что в предыдущем плане. Отличается только время хранения и, соответственно, требования к дисковому хранилищу.

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

— для 14 суток хранения

3 * полный размер занятого места + 16 * 3% полного занятого места, то есть для сервера с занятым местом 500 Гб потребуется 1 740 Гб.

— для 7 суток хранения

2 * полный размер занятого места + 13 * 3% полного занятого места, то есть для сервера с занятым местом 500 Гб потребуется 1 195 Гб.

Все данные очень усреднённые, к каждому проекту у нас индивидуальный подход. Место для хранения копий баз данных в данной формуле не учитывается.

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

⌘⌘⌘

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