Назначения резервного копирования

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

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

Хранилища

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

Кроме него можно зарегистрировать ещё два типа.

Тип	Что это	Что нужно для регистрации
hosted-r2	Второй размещённый регион, выбранный из регионов, которые предлагает развёртывание	Идентификатор и регион. Без учётных данных
customer-s3	Бакет, который ведёт сам клиент, на S3, RustFS или любом S3-совместимом сервисе	Идентификатор, HTTPS-эндпоинт, бакет, регион подписи (по умолчанию us-east-1), необязательный публичный эндпоинт и одна пара ключей доступа

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

Регистрация хранилища

Регистрация – это вызов API учётной записи, а не команда rdc. POST /backups/stores регистрирует хранилище, GET /backups/stores показывает зарегистрированные, а DELETE /backups/stores/<id> выводит хранилище из работы. Для регистрации, смены ключей и вывода из работы нужен API-токен с областью backup:manage, созданный текущим владельцем или администратором организации, и каждое действие попадает в аудит. Для просмотра списка нужна область backup:read.

Сервер проверяет хранилище, прежде чем принять его.

• Проверка соответствия. Сервер выполняет те же проверки, которые проходит размещённое хранилище. Хранилище, не обеспечивающее контрольные суммы, отклоняется при регистрации, а не обнаруживается при первом бэкапе.
• Проверка удаления. Проверка также пробует удалить объект. Если хранилище отказывает, оно регистрируется с отключённой очисткой (см. ниже).
• Правила для эндпоинта. Только HTTPS, порт 443 и никаких эндпоинтов во внутренней сети.
• Лимит хранилищ. Число хранилищ на подписку зависит от тарифа, включая home и не считая выведенные из работы.

Тариф	Хранилища
Free	1
Community	2
Professional	3
Business	5
Enterprise	10

Регистрация уже существующего идентификатора меняет только его учётные данные, и проверка выполняется заново. Хранилище, у которого перестали работать учётные данные, помечается как приостановленное после первого отказа в выдаче доступа. GET /backups/stores показывает эндпоинт, бакет и последние символы идентификатора ключа, но никогда не секрет.

Хранилище нельзя вывести из работы, пока его всё ещё называет включённое назначение, а home вывести нельзя.

Выбор хранилища для назначения

Назначение указывает своё хранилище параметром --target, который используется вместе с --destination:

# Write to the home store (the default).
rdc backup strategy set daily --destination primary

# Write to a registered store.
rdc backup strategy set daily --destination offsite --target office-rustfs

Параметр	Описание
--destination <name>	Назначение, которое нужно создать или изменить
--target <storeId>	Идентификатор зарегистрированного хранилища, в которое пишет назначение (по умолчанию home). Требует --destination

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

Каждый запуск по расписанию делает по одному снимку на каждое включённое назначение, в порядке, в котором назначения были объявлены, и у каждого свой лимит пропускной способности. Каждый снимок – это новый reflink с копированием при записи, поэтому каждый из них – согласованная точка во времени сама по себе. Сбой одного назначения не заставляет пропустить следующее. Юнит всё равно завершается с ненулевым кодом, если какое-то назначение не удалось, так что systemd и проверка пропущенных запусков видят сбой.

Восстановление из хранилища

rdc backup restore, rdc backup restore --path, rdc backup browse --at и rdc backup download --store принимают --from <storeId>:

# The best store, chosen automatically.
rdc backup restore my-app --as my-app-copy --at <snapshot-id>

# One named store.
rdc backup restore my-app --as my-app-copy --at <snapshot-id> --from office-rustfs

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

Без --from команды backup restore, restore --path, browse --at и download --store начинают с первого хранилища этого ранжирования и переходят к следующему, если сбой связан с хранилищем: ошибка сервера, отказ в выдаче доступа или сессии, либо эндпоинт, который не отвечает. Каждая сообщает, какое хранилище её обслужило. Ни одна не переключается на другое хранилище из-за дефекта самого снимка. Отсутствующий, просроченный или повреждённый снимок выглядит одинаково в любом хранилище, поэтому показывается ошибка. Команда с --from читает только это хранилище и никогда не переключается.

Идентификатор снимка, указанный без --from, ищется во всех хранилищах этой линии происхождения.

Статус по назначениям

rdc backup status выводит по строке на каждое назначение рядом с таблицей расписания:

Столбец	Значение
Store	Идентификатор хранилища, в которое пишет назначение
Last run	Когда завершился последний запуск для этого хранилища
Result	Итог этого запуска
Newest snapshot	Самый новый снимок в хранилище
Verify	Результат последней проверки хранилища
Clean-up	enabled или отключена с указанием причины

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

Что учитывается в квоте

Размещённые хранилища, home и любой второй регион, измеряются по физически хранимым уникальным байтам, и эти байты учитываются в той же квоте тарифа. rdc backup usage их показывает.

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

Хранилища с отключённой очисткой

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

rdc backup status и сводка о состоянии бэкапов сообщают, что в хранилище отключена очистка. Бакет продолжает расти, пока не будут добавлены учётные данные с правом удаления: для этого тот же идентификатор регистрируется заново с ключами, которым удаление разрешено.