Как делать бэкапы, чтобы не стать грустным админом. Играем в было/не было

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

В тексте перечислили досадные ошибки и лучшие практики в работе с бэкапами, а эпичные и поучительные истории реальных сисадминов оставили на десерт. Их полные боли рассказы читайте здесь.

→ Были или не были у вас такие ситуации? Пишите в комментариях!

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

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

Говорят, все системные администраторы делятся на три группы: те, кто не делает бэкапы, те, кто делает бэкапы, и те, кто проверяет их консистентность и работоспособность.

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

Иногда для проверки достаточно развернуть пустой проект, наполнить его данными, сделать бэкап и восстановиться из него. Также есть практика закрывать риски для систем несколькими способами резервирования: одна копия из 3-4 будет целостной с большей вероятностью.

Достойный подход, одобренный сотнями крепко спящих по ночам админов. Многие согласятся, что первый шаг в работе с бэкапами — это составление документа, в котором описывается, что и как часто нужно делать, где хранить, как восстанавливать. Нередко такой документ является частью Disaster Recovery Plan компании.

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

Кто-то называет это оверхедом, а кто-то — лучшими практиками. Тем не менее, как показывает опыт сисадминов, чем богаче панель инструментов для бэкапов, тем надежнее. В некоторых компаниях реализовывать бэкапы несколькими способами — корпоративная норма. Главное, чтобы было место для их хранения. Часть клиентов бэкапов по расписанию Selectel подключили решение как раз в добавку к существующим способам бэкапирования — чаще всего кастомным скриптам.

Для критических сервисов стоит поднять реплику, чтобы быстро переключиться на нее при отказе «железа». Исключительно на RAID и SMART-мониторинг дисков полагаться не стоит.

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

Иногда это объясняется тем, что другого места нет и так экономнее (плохой сценарий). Или же так админ решает хранение горячей копии данных, чтобы восстановление конкретного утерянного файла происходила быстрее (хороший сценарий). В таком случае правильность решения определяется наличием холодной копии на стороннем сервере.

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

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

Проблему забывчивости, нехватки времени и добрую половину ранее озвученных вызовов решит сервис бэкапов сетевых дисков по расписанию. Бэкапы создаются автоматически по плану, который достаточно настроить один раз и применить ко всем дискам. Для переноса резервных копий в хранилище используются выделенные сети провайдера (не нужно нужно думать о торможении систем из-за ограничений собственных каналов). А для объема хранимых бэкапов нет ограничений — можно забыть о страхе, что однажды бэкап не сделается из-за отсутствия свободного места на диске.

→ Настройте расписание резервного копирования

Цена за бэкап 1 ГБ данных — 3,70 рублей в месяц. Рассчитать цену за хранение ваших бэкапов можно по ссылке.

Читайте также:

#бэкапы #резервное_копирование #системный_администратор #инфраструктура #selectel