Как выбрать эффективную стратегию резервного копирования

Введение

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

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

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

Часть 1 — В чем разница между избыточностью и резервным копированием?

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

Избыточность

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

Однако решение по избыточности обычно не является также решением по резервному копированию. Избыточное хранилище не обязательно обеспечивает защиту от отказа, затрагивающего всю машину или систему. Например, если у вас настроен зеркальный RAID (например, RAID 1), ваши данные избыточны в том смысле, что если один диск выйдет из строя, другой все равно будет доступен. Однако если сама машина выйдет из строя, все ваши данные могут быть потеряны.

С решениями резервного копирования, такими как MySQL Group Replication, каждая операция обычно выполняется на каждой копии данных. Это включает в себя злонамеренные или случайные операции. По определению, резервное решение также должно позволять восстановиться из предыдущей точки, когда данные известны как правильные.

Резервное копирование

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

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

Резервные копии по себе не обеспечивают автоматического переключения. Это означает, что ваши сбои могут не привести к потере данных (при условии, что ваши резервные копии на 100% актуальны), но они могут стоить вам времени безотказной работы. Вот почему избыточность и резервное копирование часто используются в комбинации друг с другом.

Часть 2 — Резервное копирование на уровне файлов

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

Как использовать команду cp

В теории вы можете создать резервную копию Linux-машины, например, вашего облачного сервера, с помощью команды cp. Это копирует файлы из одного локального расположения в другое. На локальном компьютере вы можете подключить съемный носитель и скопировать файлы на него:

mount /dev/sdc /mnt/my-backup
cp -a /etc/* /mnt/my-backup
umount /dev/sdc

В этом примере подключается съемный диск sdc как /mnt/my-backup, а затем копируется каталог /etc на диск. Затем диск отключается и его можно хранить в другом месте.

Как использовать Rsync

A better alternative to cp is the rsync command. Rsync is a powerful tool that provides a wide array of options for replicating files and directories across many different environments, with built-in checksum validation and other features. Rsync can perform the equivalent of the cp operation above like so:

mount /dev/sdc /mnt/my-backup
rsync -azvP /etc/* /mnt/my-backup
umount /dev/sdc

-azvP – типичный набор опций Rsync. Вот разбор, что делает каждая из них:

• a enables “Archive Mode” for this copy operation, which preserves file modification times, owners, and so on. It is also the equivalent of providing each of the -rlptgoD options individually (yes, really). Notably, the -r option tells Rsync to recurse into subdirectories to copy nested files and folders as well. This option is common to many other copy operations, such as cp and scp.
• z compresses data during the transfer itself, if possible. This is useful for any transfers over slow connections, especially when transferring data that compresses very effectively, like logs and other text.
• v enables verbose mode, so you can read more details of your transfer while it is in progress.
• P tells Rsync to retain partial copies of any files that do not transfer completely, so that transfers can be resumed later.

Вы можете ознакомиться с другими опциями rsync на его странице руководства.

Конечно, в облачной среде вы обычно не будете монтировать и копировать файлы на монтированный диск каждый раз. Rsync также может выполнять удаленные резервные копии по сети, предоставляя синтаксис в стиле SSH. Это будет работать на любом хосте, на который вы можете подключиться по SSH, при условии, что rsync установлен на обеих концах. Поскольку rsync считается основным инструментом Linux, это почти всегда безопасное предположение, даже если вы работаете локально на компьютере Mac или Windows.

rsync -azvP /etc/* username@remote_host:/backup/

Это выполнит резервное копирование каталога /etc локальной машины в каталог на remote_host, расположенный в /backup. Это будет успешно, если у вас есть разрешение на запись в этот каталог и есть свободное место.

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

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

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

Bacula

Bacula – это сложное, гибкое решение, которое работает по модели клиент-сервер. Bacula разработан с отдельными концепциями клиентов, мест резервного копирования и директоров (компонент, который оркестрирует фактическое резервное копирование). Он также настраивает каждую задачу резервного копирования в единицу, называемую “заданием”.

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

Duplicity

Duplicity – еще один инструмент для резервного копирования с открытым исходным кодом. По умолчанию он использует шифрование GPG для передачи.

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

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

Часть 3 — Резервные копии на уровне блоков

A slightly less common, but important alternative to file-level backups are block-level backups. This style of backup is also known as “imaging” because it can be used to duplicate and restore entire devices. Block-level backups allow you to copy on a deeper level than a file. While a file-based backup might copy file1, file2, and file3 to a backup location, a block-based backup system would copy the entire “block” that those files reside on. Another way of explaining the same concept is to say that block-level backups copy information bit after bit. They do not know about the files that may span those bits.

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

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

Самым распространенным способом выполнения блочных резервных копий является использование утилиты dd. dd можно использовать для создания полных образов дисков, а также часто используется при архивации съемных носителей, таких как CD или DVD. Это означает, что вы можете создать резервную копию раздела или диска в один файл или в необработанное устройство без каких-либо предварительных шагов.

Для использования dd необходимо указать место ввода и место вывода, как показано ниже:

dd if=/path/of/original/device of=/path/to/place/backup

В этом сценарии аргумент if= указывает устройство или местоположение ввода. Аргумент of= указывает файл или местоположение вывода. Будьте внимательны, чтобы не перепутать их, иначе вы можете случайно стереть весь диск.

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

dd if=/dev/sda3 of=~/documents.img

Часть 4 — Резервное копирование версий

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

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

cp file1 file1.bak
nano file1

Вы даже можете автоматизировать этот процесс, создавая отмеченные временем скрытые файлы каждый раз, когда вы изменяете файл с помощью вашего редактора. Например, вы можете разместить это в вашем файле ~/.bashrc, так что каждый раз, когда вы запускаете nano из вашей оболочки bash (т.е. $), он автоматически создает резервную копию, отмеченную годом (%y), месяцем (%m), днем (%d) и т. д.:

nano() { cp $1 .${1}.`date +%y-%m-%d_%H.%M.%S`.bak; /usr/bin/nano $1; }

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

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

Часть 5 — Резервное копирование на уровне сервера

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

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

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

Больше информации о резервных копиях и снимках DigitalOcean можно узнать из документации Контейнеры и Образы.

GitOps

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

Заключение

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