[Документация Yandex Cloud](../../index.md) > [Yandex Managed Service for MySQL®](../index.md) > [Концепции](index.md) > Резервные копии

# Резервные копии в Managed Service for MySQL®

Managed Service for MySQL® обеспечивает автоматическое и ручное резервное копирование баз данных.

Для кластеров с неподдерживаемой версией СУБД восстановление из резервных копий недоступно.

## Создание резервной копии {#size}

Резервные копии могут быть созданы автоматически или вручную, в обоих случаях создается [полная физическая резервная копия](https://dev.mysql.com/doc/refman/5.7/en/backup-types.html) всех баз данных.

Отключить автоматическое создание резервных копий нельзя. Однако при [создании](../operations/cluster-create.md) или [изменении](../operations/update.md#change-additional-settings) кластера для таких резервных копий можно задать промежуток времени, в течение которого начинается резервное копирование. По умолчанию — `22:00 - 23:00` UTC (Coordinated Universal Time).

После создания резервная копия сжимается для дальнейшего хранения.

В кластерах из одного хоста резервная копия создается чтением данных с хоста-мастера, а в многохостовых кластерах, так как это ресурсоемкая операция — с одной из реплик. При этом:

* Выбирается реплика с наибольшим приоритетом резервного копирования. Приоритет можно задать при [создании](../operations/cluster-create.md) кластера, [добавлении](../operations/hosts.md#add) в него новых хостов или [изменении настроек](../operations/hosts.md#update) существующих, тем самым указав конкретную реплику для резервного копирования. Минимальное значение приоритета резервного копирования — `0`, максимальное — `100`, по умолчанию — `0`.
* Если наибольший приоритет имеют несколько реплик, источник резервного копирования выбирается среди них случайным образом.

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

Резервные копии создаются только на работающих кластерах. Если вы используете кластер Managed Service for MySQL® не круглосуточно, проверьте [настройки времени начала резервного копирования](../operations/update.md#change-additional-settings).

О том, как вручную создать резервную копию, читайте в разделе [Управление резервными копиями](../operations/cluster-backups.md).

## Хранение резервной копии {#storage}

Особенности хранения резервных копий в Managed Service for MySQL®:

* Резервные копии хранятся во внутреннем хранилище Yandex Cloud в виде бинарных файлов и шифруются с помощью [GPG](https://ru.wikipedia.org/wiki/GnuPG). У каждого кластера свои ключи шифрования.

* В существующем кластере для созданных автоматически резервных копий срок хранения можно настроить в диапазоне от 7 до 60 дней (по умолчанию — 7). Созданные вручную резервные копии хранятся бессрочно.

* После удаления кластера все его резервные копии хранятся 7 дней, включая созданные вручную. Хранение резервных копий в этот период не тарифицируется.

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

* На хранилище резервных копий не распространяется действие [квот](https://kz.console.yandex.cloud/cloud?section=quotas) и лимитов для хранилища кластера.

* Резервные копии содержатся в объектном хранилище и не занимают место в хранилище кластера. При этом если в кластере есть N свободных гигабайт места, то хранение первых N гигабайт резервных копий не тарифицируется.

    Подробнее в разделе [Правила тарификации](../pricing.md#rules-storage).

## Восстановление из резервной копии {#capabilities}

Восстанавливая кластер из резервной копии, вы создаете новый кластер с данными из резервной копии. Если в каталоге не хватает [ресурсов](limits.md) для создания такого кластера, восстановиться из резервной копии не получится. Средняя скорость восстановления из резервной копии — 10 МБ/с на каждое ядро БД.

При восстановлении до состояния на текущий момент времени новый кластер будет отражать состояние:

* существующего кластера на момент восстановления;
* удаленного кластера на момент архивации последнего бинарного лога.

Чтобы восстановить кластер из резервной копии, следуйте [инструкциям](../operations/cluster-backups.md).

{% note tip %}

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

{% endnote %}

## PITR в Managed Service for MySQL® {#pitr-details}

Managed Service for MySQL® позволяет восстановить состояние кластера _на любой момент времени_ (Point-in-Time-Recovery, PITR) после создания самой старой полной резервной копии. Это достигается за счет дополнения данных резервной копии, выбранной в качестве начальной точки для восстановления, записями из бинарных логов (Binary Log) более поздних резервных копий кластера.

> Например, если операция создания резервной копии завершилась 10.08.2020 в 12:00:00 UTC, текущая дата — 15.08.2020 19:00:00 UTC, а последний бинарный лог был сохранен 15.08.2020 в 18:50:00 UTC, кластер может быть восстановлен в любое свое состояние в промежутке времени с 10.08.2020 12:00:01 UTC до 15.08.2020 18:50:00 UTC включительно.

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

На создание и загрузку архива бинарного лога в объектное хранилище требуется некоторое время. Из-за этого состояние кластера, хранящееся в объектном хранилище, может отличаться от реального.

По умолчанию PITR включен.

Подробнее о PITR в [документации MySQL®](https://dev.mysql.com/doc/refman/8.0/en/point-in-time-recovery.html).