Бэкап: не просто одна копия

Слишком многие люди преступно пренебрегают резервным копированием. Из-за заблуждений в этой области теряется слишком много данных; это связано и с ошибочными техниками наподобие «бэкапов Шрёдингера» (то есть никогда не тестируемых, а значит, валидных и невалидных одновременно), и с концептуальными заблуждениями о том, что такое бэкапы и как они работают (RAID — это не бэкап!).

Сегодня о резервном копировании зачастую думают по остаточному принципу. Многие полностью полагаются на «облако», не задаваясь даже вопросами о том, каким образом защищаются их данные. Большинство упускает из виду, что даже крупные поставщики облачных услуг работают по модели коллективной ответственности. В условиях пользования они часто подчёркивают, что, несмотря на обеспечение ими безопасности инфраструктуры, в конечном итоге ответственность за защиту и резервное копирование данных лежит на пользователях. Когда хранишь всё «в облаке», в кластерах, которыми владеют другие компании, или в распределённых системах Kubernetes, бэкапы часто кажутся ненужными. Иногда я спрашиваю коллег или разработчиков о том, как они реализуют резервное копирование, и они смотрят на меня так, как будто я говорю на каком-то древнем забытом языке. Они попросту никогда об этом не задумывались. Но данные не эфемерны, их необходимо защищать любыми возможными способами.

Я всегда исповедовал такую философию: данные обязаны быть восстанавливаемыми (и как можно быстрее), целостными и храниться в открытом формате (чтобы для их восстановления или анализа не приходилось покупать что-то). Эти пункты могут показаться очевидными, но на деле это не всегда так.

Я сталкивался со множеством сценариев утери данных:

• Дата-центры, уничтоженные пожаром — у меня было там 142 сервера, но все их восстановили всего за несколько часов.

• Затопленные серверные.

• Серверы, уничтоженные при землетрясениях, часто из-за обрушения стен.

• Всё чаще возникающие инциденты различных ransomware-атак.

• Намеренное повреждение лицами, желающими создать проблемы.

• Ошибки администраторов, которые могут случиться с каждым.

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

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

План резервного копирования: задаём правильные вопросы

Ещё не прикоснувшись ни к одному файлу, вы должны начать с плана, а этот план начинается с ответов на правильные вопросы:

«Какой риск для меня приемлем? Какие данные мне нужно защищать? С каким даунтаймом я готов мириться в случае утери данных? Какой тип и объём пространства хранения у меня есть?»

Особенно важен первый вопрос. Часто применяется рискованный способ хранения бэкапа на той же машине, которая требует резервного копирования. Это удобно, но в случае отказа машины такая стратегия обернётся поражением. Даже использование классического USB-накопителя не обеспечивает должной защиты, потому что эти устройства, как и любые другие аппаратные компоненты, подвержены сбоям. И, вопреки популярному мнению, даже дорогостоящие источники бесперебойного питания (ИБП) не имеют полной защиты от катастрофических сбоев.

Следовательно, первым делом нужно создать план управления, обеспечивающий баланс между безопасностью и стоимостью. Часто самый безопасный бэкап — это тот, который хранится как можно дальше от исходной машины. Однако при таком подходе возникают трудности, связанные с пространством и шириной канала. Бэкапы в локальной сети (LAN) реализуются достаточно легко, а при создании бэкапов в сторонней сети нужно учитывать аспекты, связанные с подключением. Из-за них иногда приходится идти на компромисс и снижать объём попадающих в бэкап данных, чтобы обеспечить достаточную скорость процессов бэкапа и восстановления.

Безопасность не всегда равна практичности. Например, при скорости передачи 200 Мбит/с и бэкапе на 2 ТБ время восстановления окажется существенным. Однако если ваша цель — не быстрое восстановление, а просто обеспечение доступности данных, то часто самым безопасным оказывается самый близкий бэкап, то есть тот, к которому мы можем «прикасаться» и обращаться, даже находясь офлайн.

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

Фундаментальное решение: весь диск или отдельные файлы

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

Бэкап всего диска (или накопителя)

Преимущества:

• Полное восстановление: восстановление бэкапа всего диска позволяет быстро вернуть систему к её точному предыдущему состоянию, включая загрузчик.

• Интеграция в системы виртуализации: если ваша VM — это единый файл в файловой системе наподобие ZFS или btrfs, можно просто скопировать этот файл (предварительно создав снэпшот), получив таким образом полный бэкап VM. Решения типа Proxmox позволяют удобно управлять бэкапами целых дисков через командную строку или веб-интерфейс.

• Гибкость в виртуальных окружениях: ПО типа Proxmox Backup Server способно восстанавливать отдельные файлы из полного бэкапа, обеспечивая преимущества обоих подходов.

Недостатки:

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

• Потребность в большом объёме хранилища: полные бэкапы дисков могут занимать существенные объёмы, включая в себя и необязательные данные.

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

Бэкап отдельных файлов

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

Преимущества:

• Реализация при помощи простых утилит: такую систему можно реализовать на основе стандартных системных утилит наподобие tar, cp, rsync и так далее.

• Детальные бэкапы: возможность копирования конкретных файлов и их сравнения с предыдущими версиями.

• Дельта-копирование: можно выполнять резервное копирование только изменившихся частей файлов, что позволяет сэкономить место и снизить объём передаваемых данных.

• Портируемость и частичное восстановление: файлы можно перемещать по отдельности и при необходимости восстанавливать частично.

• Сжатие и дедупликация: эти возможности часто доступны на уровне файлов или блоков.

• Непрерывность работы: такое резервное копирование можно выполнять без отключения машины.

Недостатки:

• Требования к пространству в хранилище: простое копирование может требовать существенных объёмов хранилища.

• Необходимость снэпшота файловой системы: для обеспечения эффективности и согласованности бэкапов перед копированием крайне рекомендуется создавать снэпшоты (например, нативные снэпшоты ZFS, btrfs, снэпшоты LVM Volume или VSS Microsoft).

• Скрытые опасности: проблемы могут проявиться только при необходимости восстановления бэкапа. И тогда может быть уже слишком поздно.

Решение проблемы согласованности: мощь снэпшотов

При резервном копировании «живой» файловой системы существуют моменты «начала» и «завершения». Между этими моментами данные могут меняться, что может привести к фатальным несоответствиям. В прошлом я сталкивался с подобными проблемами: была повреждена крупная база данных MySQL, и мне поручили её восстановить. Я уверенно взял последний файловый бэкап клиента и восстановил файлы (не нативный дамп). Разумеется, база данных не смогла перезапуститься. Крупный файл данных изменился в промежутке между началом и завершением копирования слишком сильно, потеряв из-за этого целостность. К счастью, у меня был и надлежащим образом созданный дамп, поэтому мне удалось исправить ошибку.

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

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

Перечислю способы, которые я исследовал за годы работы:

• Нативный снэпшот файловой системы (например, BTRFS или ZFS): если у вашей файловой системы есть встроенная поддержка снэпшотов, то мудро будет воспользоваться этой возможностью. Скорее всего, это окажется самым эффективным и технически надёжным вариантом.

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

• DattoBD: я следил за развитием этого инструмента с момента его появления. Раньше я часто им пользовался, но иногда у меня обнаруживались проблемы со стабильностью (паника ядра или невозможность удаления снэпшотов, из-за чего приходилось выполнять перезагрузку). Для работы со снэпшотами Datto я часто пользуюсь скриптами UrBackup, это удобный и эффективный способ.

Архитектура: Push или Pull?

Специалисты давно ведут споры о том, кем должно инициироваться резервное копирование: клиентом (push) или сервером (pull). На мой взгляд, это зависит от ситуации.

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

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

Это не всегда возможно, но способы решения проблемы существуют. Например, можно сделать так, чтобы машины, резервные копии которых выполняются через «push» (то есть при самостоятельном обращении к серверу резервного копирования) могли иметь доступ только к собственному пространству. Ещё важнее то, что сервер резервного копирования из соображений безопасности должен в течение определённого периода хранить снэпшоты собственной файловой системы. Благодаря этому даже в наихудшем сценарии (компрометация рабочей нагрузки -> подключение к серверу резервного копирования -> удаление резервных копий с целью требования выкупа), сервер резервного копирования имел собственные снэпшоты. Доступ к таким снэпшотам на стороне сервера должен быть невозможен со стороны клиента, и их следует хранить столько времени, сколько необходимо для своевременного выявления компрометации.

Мои основные принципы для создания качественной системы бэкапов

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

• Мгновенное восстановление и скорость: система должна обеспечивать быстрое восстановление и работать с высокой скоростью.

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

• Безопасность: для создания основных бэкапов я не пользуюсь популярными облачными устройствами хранения наподобие Dropbox и Google Drive. Ответственность за свои данные следует нести самостоятельно!

• Эффективное управление пространством: сюда включаются такие возможности, как сжатие и дедупликация.

• Минимальная инвазивность: для своей работы системе должно требоваться минимальное количество дополнительных компонентов.

Заключение: что дальше

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

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