Резервное копирование в S3-хранилище #
PgVault умеет сохранять резервные копии в любое S3-совместимое объектное хранилище — протестирована поддержка большинства известных облачных и собственные (self-hosted) хранилищ, поддерживающие тот же протокол(Amazon S3, Cloudflare R2, MinIO, Yandex Object Storage, VK Cloud Storage, Selectel, Backblaze B2).Для Cloudflare R2 в PgVault есть отдельная, специальная оптимизация — достаточно просто указать адрес R2 как обычно, ничего дополнительно настраивать не нужно.
Как подключить #
- Перейдите в раздел Хранилища → Новое хранилище.
- В поле «Тип хранилища» выберите S3-совместимое хранилище.
- Заполните поля: Имя, выберите агента, и тип хранилища «S3-совместимое хранилище»
- Далее детальное описание полей
| Поле | Что указывать |
|---|---|
| Адрес сервера | Адрес вашего S3-провайдера, например storage.yandexcloud.net. Если оставить поле пустым тогда PgVault обратится напрямую к AWS. |
| Бакет | Имя бакета (контейнера), куда будут складываться резервные копии. Бакет должен быть создан заранее на стороне провайдера. |
| Путь внутри бакета | Необязательно. Подпапка внутри бакета, например backups/pgvault — удобно, если один бакет используется для разных целей. |
| Access Key ID | Ключ доступа, выданный вашим S3-провайдером. |
| Регион | Указывается, только если провайдер этого требует (для многих self-hosted и российских провайдеров можно оставить пустым). |
| Secret Access Key | Секретный ключ доступа. При редактировании уже сохранённого хранилища это поле можно оставить пустым, чтобы не менять сохранённый ранее ключ. |
- Нажмите Добавить.
- Обязательно нажмите кнопку «Проверить доступ» — это быстрая проверка, что PgVault реально может подключиться к указанному бакету с указанными ключами. Результат отображается статусом: «доступно», «недоступно: (текст ошибки)» или «проверка в очереди…», пока задание ещё не выполнено агентом.
Шифрование канала #
Соединение с S3-хранилищем всегда идёт по HTTPS — отключить шифрование канала для этого типа хранилища невозможно.
Защита резервных копий в S3 от удаления #
Резервная копия — последняя линия защиты только пока она сама доступна и цела. При атаках с вымогательством злоумышленники, получив доступ к инфраструктуре, часто сначала находят и удаляют резервные копии, и только потом шифруют рабочие системы — так жертва лишается возможности восстановиться. Обычные права доступа здесь не всегда спасают: если атакующий получил тот же токен доступа, что использует и легитимный процесс резервного копирования, для хранилища его запрос на удаление выглядит совершенно законным. Протокол S3 предлагает дополнительные меры для тех, кто хочет защититься именно от этого сценария.
Вариант 1 — Object Lock (неизменяемое хранение) #
Что это. Object Lock — стандартная возможность протокола S3, а не что-то специфичное для одного облачного провайдера. Она есть у AWS S3, MinIO, VK Cloud и большинства других S3-совместимых хранилищ. Если она включена на бакете — загруженный туда объект физически нельзя удалить или изменить до истечения заданного срока, даже с полностью легитимными, настоящими учётными данными.
Как включить. Object Lock настраивается на стороне самого хранилища, при создании бакета — не в PgVault. Обратитесь к документации вашего провайдера объектного хранилища, чтобы создать бакет с включённым Object Lock и нужным сроком хранения. После этого просто укажите этот бакет как обычное S3-хранилище в PgVault, ничего особенного настраивать в самом PgVault не нужно, резервные копии, загружаемые в такой бакет, автоматически получат защиту.
Важно понимать до включения. Большинство S3-провайдеров не дают позже отключить Object Lock у уже созданного бакета — при необходимости изменить режим защиты придётся создавать новый бакет.
Как это соотносится с ротацией (автоматическим удалением старых копий) в PgVault. Пока копия находится под блокировкой Object Lock, попытка удалить её (в том числе автоматическая, по правилам ротации в задаче резервного копирования) хранилище отклонит. Чтобы ротация продолжала исправно работать, задавайте срок блокировки на хранилище короче, чем то время, через которое PgVault по своим правилам будет пытаться удалить эту копию — тогда к моменту удаления блокировка уже истечёт сама.
Вариант 2 — учётные данные без права удаления #
Независимо от Object Lock, стоит завести для S3-хранилища, указываемого в PgVault, отдельную учётную запись (Access Key ID / Secret Access Key) с правами только на запись и чтение объектов — без права на удаление. Тогда даже если сервер PgVault будет скомпрометирован, а сохранённые учётные данные хранилища — расшифрованы и использованы злоумышленником, удалить уже сохранённые резервные копии этими правами будет невозможно.
Компромисс, о котором нужно знать заранее. Встроенная ротация в PgVault не сможет удалять старые копии такими правами — они будут только накапливаться. Если хотите одновременно и защиту от удаления, и автоматическую очистку старых копий — либо используйте вариант с Object Lock выше (где удаление технически возможно, но только после истечения срока), либо очищайте бакет отдельно, вручную или отдельным скриптом с более широкими правами, не хранимыми в самом PgVault.
Что уже защищено в PgVault и без этого #
Эти меры дополняют, а не заменяют то, что уже есть в продукте:
- Шифрование резервных копий отдельным паролем (настраивается в самой задаче резервного копирования) — защищает содержимое, даже если кто-то получит доступ к файлам копий.
- Автоматическая проверка бэкапа — уже встроенная функция, реально восстанавливающая копию во временную базу данных сразу после создания, чтобы подтвердить её целостность, а не просто факт наличия файла.
