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

Общая информация#

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

Помимо собственного сервиса для резервного копирования К2 Облако также предлагает опцию резервного копирования баз данных и сервис резервного копирования с помощью агентов.

Основные понятия#

  • Агентское решение — Сервис резервного копирования с использованием агентов от сторонних вендоров.

  • Выборка ресурсов — Группа ресурсов, к которым применяется конкретный план резервного копирования.

  • Задача — Задача по резервному копированию автоматически создаётся в соответствии с заданным пользователем расписанием.

  • Защищённый ресурс — Ресурс, для которого имеется хотя бы одна резервная копия.

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

  • План — План определяет правила резервного копирования и ресурсы, к которым они применяются.

  • Правило — Правило резервного копирования задаёт частоту и окно резервного копирования, место и срок хранения резервных копий.

  • Резервная копия — Сохранённое содержимое ресурса на конкретный момент времени.

  • Частота резервного копирования — Расписание, в соответствие с которым выполняется резервное копирование.

  • Хранилище — Логический контейнер, где хранятся резервные копии.

Надёжное хранение резервных копий#

Резервные копии размещаются на выделенной системе хранения отдельно от дисков. При этом резервные копии ресурсов из одной зоны доступности размещаются в другой зоне доступности.

Резервные копии являются неизменяемыми — их содержимое нельзя модифицировать после создания. Во избежание непреднамеренной потери данных удалённые вручную копии остаются доступны до пяти дней (см. подробнее раздел Политика удаления резервных копий).

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

Пользователи могут получить доступ к разделу Резервное копирование с возможностью просмотра информации и управления резервными копиями, только если им предоставлены соответствующие привилегии (например, они включены в группу BackupAdministrators или BackupOperators). Первая предоставляет все права на действия с резервными копиями, вторая, в отличие от неё, не позволяет их удалять.

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

Политика удаления резервных копий#

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

Примечание

Резервные копии можно удалить только в одноимённом разделе. Образы и снимки, соответствующие резервной копии, удалить нельзя.

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

Когда копия удаляется вручную, она переводится в состояние Удаляется и хранится ещё 5 дней, либо до заданного срока удаления, если до него осталось меньше 5 дней. Пока резервная копия находится в состоянии Удаляется, из неё можно по-прежнему создать защищаемый ресурс (экземпляр или диск).

Консистентность резервных копий#

Согласованность (консистентность) данных может быть обеспечена на разных уровнях:

  • на уровне файловой системы;

  • на уровне приложения.

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

В момент создания снимка экземпляра или его диска данные могут находиться в одном из четырёх состояний с точки зрения консистентности:

  • Данные файловой системы и приложения неконсистентны. Как у файловой системы, так и приложения в момент создания снимка оставались данные в памяти и, соответственно, они отсутствуют в созданном снимке.

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

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

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

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

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

Чтобы обеспечить согласованность создаваемых резервных копий на уровне файловой системы, сервис взаимодействует с QEMU Guest Agent, который предварительно необходимо установить в гостевую ОС.

При запуске задачи на резервное копирование QEMU Guest Agent отправляется команда на заморозку ввода/вывода. В случае ОС Linux агент по умолчанию выполняет fsfreeze, что позволяет обеспечить согласованность только файловой системы. В Windows для этой цели он вызывает Volume Shadow Copy Service (VSS), что гарантирует также согласованность данных VSS-совместимых приложений.

Внимание

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

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

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

Статус коммуникации

Консистентность снимка

Агент не установлен, либо ошибка соединения с агентом

Неконсистентный

Заморозка выполнена успешно в течение 20 сек

Консистентный 1

Заморозка занимает больше 20 сек 2

Неконсистентный

Экземпляр в состоянии Выключен

Консистентый
1

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

2

В этом случае выполняется принудительная разморозка.

Сразу же после создания снимка инициируется процедура разморозки операционной системы путём отправки агенту соответствующей команды.

Подробнее об установке QEMU Guest Agent и необходимых настройках можно прочитать в инструкции.

Особенности применения планов и правил#

Резервное копирование в соответствии с конкретным планом резервного копирования может осуществляться не чаще одного раза в час.

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

Например, заданы два правила:

  • резервное копирование должно выполняться в 00 часов каждый день, окно резервного копирования — 1 ч, срок хранения резервных копий — 7 дней.

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

Два этих правила перекрываются ежедневно в 00:30 ночи, так как окно резервного копирования для первого находится в интервале 00:00-01:00, а второго — 00:30-01:30. В этом случае, резервное копирование будет выполнено в соответствие с первым правилом, поскольку оно предусматривает больший срок хранения. По второму правилу задача на резервное копирование в 00:30 не будет создана, но запустится в следующие часы — в 01:30, 02:30 и т.д., если не возникнет пересечений с другими правилами.

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

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

Примечание

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

Отсрочка создания мгновенных снимков#

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

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

Ограничения на использование#

Для сервиса резервного копирования действуют следующие ограничения:

  • 1 хранилище для резервных копий на проект;

  • 5 планов на проект;

  • 5 правил в плане;

  • 5 выборок ресурсов в плане;

  • 20 уникальных экземпляров во всех выборках ресурсов;

  • 20 уникальных дисков во всех выборках ресурсов.

Примечание

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

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