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

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


Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. mount /dev/sdc /mnt/my-backup
  2. cp -a /etc/* /mnt/my-backup
  3. umount /dev/sdc

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

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

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

  1. mount /dev/sdc /mnt/my-backup
  2. rsync -azvP /etc/* /mnt/my-backup
  3. umount /dev/sdc

-azvP — это типичный набор параметров Rsync. В качестве разбивки того, что делает каждый из них:

  • a включает «Режим архива» для этой операции копирования, который сохраняет время модификации файла, владельцев и т. д. Это также эквивалентно предоставлению каждого из -rlptgoD по отдельности (да, на самом деле). В частности, параметр -r указывает Rsync рекурсивно перемещаться в подкаталоги для копирования вложенных файлов и папок. Этот параметр является общим для многих других операций копирования, таких как как cp и scp.
  • z по возможности сжимает данные во время самой передачи. Это полезно для любых передач по медленным соединениям, особенно при передаче данных, которые очень эффективно сжимаются, например журналов и другого текста.
  • v включает подробный режим, поэтому вы можете прочитать более подробную информацию о вашем переводе во время его выполнения.
  • P указывает Rsync сохранять частичные копии любых файлов, которые не были переданы полностью, чтобы передачу можно было возобновить позже.

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

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

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

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

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

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

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

бакула

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

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

Двуличие

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

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

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

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

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

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

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

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

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

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

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

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

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

Часть 4. Версии резервных копий

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

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

  1. cp file1 file1.bak
  2. nano file1

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

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

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

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

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

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

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

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

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

GitOps

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

Заключение

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