Поиск по сайту Поиск

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

Люди делятся на три категории: те кто ещё не делает резервные копии, те, кто уже делает, и те, кто проверяет сделанные. В этом материале, подготовленном совместно со специалистом отдела корпоративных продуктов 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 Гб.

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

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

⌘⌘⌘

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


7 советов для работы с небольшими данными

7 советов для работы с небольшими данными

В современном мире считается, что Big Data — ключ к созданию успешных проектов машинного обучения. Но проблема в том, что...
Read More
Квантовые нейронные сети на процессорах будущего

Квантовые нейронные сети на процессорах будущего

Законы квантовой механики в теории позволяют создать новый тип вычислительных машин, способных решать сверхпроизводительные задачи, недоступные даже самым мощным современным...
Read More
Стэнфордский курс: лекция 7. Обучение нейросетей, часть 2

Стэнфордский курс: лекция 7. Обучение нейросетей, часть 2

В шестой лекции мы начали рассказывать про обучение нейросетей: выяснили, как выбрать функцию активации, подготавливать данные, настраивать параметры и следить...
Read More
Нейросеть распознаёт узор вязания по фото

Нейросеть распознаёт узор вязания по фото

Автоматизированным производством сегодня уже никого не удивишь. Но мы попробуем. Один из наиболее необычных примеров автоматических устройств — вязальные машины,...
Read More
Бариста, учитель и работник типографии: кем были сотрудники REG.RU до того, как стали айтишниками

Бариста, учитель и работник типографии: кем были сотрудники REG.RU до того, как стали айтишниками

Сегодня, 30 сентября, День Интернета в России. В честь этой даты мы расскажем семь историй о том, как сотрудники REG.RU...
Read More
Чек-лист, который заряжен на защиту домена

Чек-лист, который заряжен на защиту домена

Время от времени мы сталкиваемся со случаями, когда мошенники уводят домены наших клиентов. Происходит это по самым разным причинам: от...
Read More
Методы распознавания радужной оболочки глаз. Часть 1

Методы распознавания радужной оболочки глаз. Часть 1

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

Стэнфордский курс: лекция 6. Обучение нейросетей, часть 1

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

Три слова, которые поймут только айтишники

Если вы не разработчик, но работаете в IT-компании, или в вашем окружении есть программисты, то, скорее всего, часто слышите странные...
Read More
Customer development: почему при выборе идеи нужно учитывать мнение клиентов

Customer development: почему при выборе идеи нужно учитывать мнение клиентов

Вместе с менеджером по продуктам REG.RU Никитой Атучиным разбираем, почему MVP — не всегда хорошее решение для старта бизнеса. Если вы...
Read More