«Когда-то я был админом, который не делал бэкапы. Теперь я очень грустный, но бэкапы делаю», — цитата одного сисадмина.

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

Предлагаем в честь праздника сыграть в игру «Было/ не было». Мы опишем частые косяки и лучшие практики при работе с бэкапами, а вы поделитесь в комментариях, что из этого было или не было в вашей карьере.

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

Составлял подробную документацию по бэкапам

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

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

Вот что рассказывает о своем опыте клиент Selectel, который занимается инфраструктурой страховой компании:

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

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

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

Ошибся с выбором окна снятия бэкапов

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

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

Клиент, который развивает площадку для автоматизации рекламных кампаний, обезопасил себя от подобной ошибки с помощью GitHub:

«Все расписания бэкапов у нас лежат в репозитории. На их основании можно найти свободное окно для резервирования нового сервиса.

Окно определяется в зависимости от порядка взаимодействия с сервисом. Где-то пользователи работают с 9:00 до 18:00 — например, бухгалтеры в 1С. После окончания рабочего дня они не задерживаются, так что бэкапиться можно с 6 вечера.

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

Использовал непроверенное решение для бэкапов

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

Один из клиентов рассказал такую поучительную историю из прошлого:

«Однажды использовал бесплатную программу, которая делала что-то наподобие zip-архивов данных. Впоследствии оказалось, что zip нечитаемые — все архивы побиты. К сожалению, понял я это только тогда, когда нужно было восстановить данные. Сделать это, разумеется, не удалось. Зато с тех пор я всегда проверяю работоспособность копий».

Не проверял работоспособность резервных копий

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

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

Способов проверки немало. Так, один из опрошенных нами специалистов пробовал и ручные проверки, и решения из «коробки»:

«Сейчас у меня нет регламентов проверки. Просто проверяю работоспособность копий время от времени. Делаю это нерегулярно, но, если настраиваю что-то новое, обязательно чекаю архив.

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

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

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

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

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

Использовал несколько способов резервного копирования

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

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

Защита данных тоже может быть в двух вариациях. Вот, так, например, решал эту задачу один наш клиент:

«В нашей компании есть правило: резервируем всю инфраструктуру и всегда двумя способами. Так, база данных бэкапится и в режиме plain text — это чистый SQL, который описывает всю структуру базы данных, и в формате бинарных файлов. В экстренном случае это позволит нам более гибко подойти к восстановлению базы».

Не ставил алерты

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

Один из опрошенных клиентов Selectel предлагает не мелочиться и ставить алерты на все: на факт снятия копии; на то, что копия не больше и не меньше, чем должна быть; на остаточный объем места на сервере, куда отправляются бэкапы (чтобы место не кончилось); на статус для команды бэкапа (может завершиться ошибкой) и другое.

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

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

Хранил резервные копии на одном сервере с бэкапируемыми данными

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

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

«Ситуация: в пятницу вечером взломали сервер. В субботу бухгалтер захотел поработать, а у него ничего не открывалось. На самом сервере все файлы были зашифрованы. Хорошо, что резервные копии хранились отдельно и нам удалось все восстановить».

Проблема с сервером может произойти как в ПО, так и в «железной» части. Поэтому резервирование серверов часто идет рука об руку с бэкапами данных. Есть такая неприятная история:

«У сервера с базой данных сгорел блок питания — машина перестала работать. Блок питания заменили, но система не загружалась. Вчерашний бэкап “умер” вместе с сервером. Пришлось брать более старую холодную копию. Разницу между репликами восстанавливали вручную всем отделом: вспоминали, что делали последние два дня, какие документы выписывали и меняли».

Забывал делать бэкапы

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

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

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