Резервное копирование и восстановление из объектного хранилища S3 — это новая функция, появившаяся с выпуском SQL Server 2022. Резервное копирование или восстановление можно делать в S3, расположенное локально или в облаке.

Что такое объектное хранилище?

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

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

Объектное хранилище может быть определяемым программно или быть аппаратным устройством, либо быть комбинацией гибридных и облачных сценариев. SQL Server 2022 совместим с любым решением для хранения объектов, поддерживающих S3 Rest API. Это означает, что решение на его основе для хранения объектов может работать в локальной сети, облаке или в гибридной среде.

Как это работает?

Несмотря на различия в архитектуре хранения, операции резервного копирования и восстановления между SQL Server и S3 ведут себя очень похоже на резервное копирование и восстановление по URL-адресу. Пользователю необходимо настроить учетные данные, а затем выполнить операцию резервного копирования или восстановления. Чтобы отличить традиционное резервное копирование по URL-адресу от объектного хранилища, SQL Server 2022 использует в качестве префикса URL-адреса «S3://».

По соображениям безопасности между SQL Server 2022 и поставщиком хранилища объектов должна быть установлена ​​конечная точка HTTPS, для которой должен использоваться сертификат и должны поддерживаться self-signed сертификаты.  Также администратором хранилища должны быть предоставлены необходимые права доступа.

Хранилище файлов резервных копии базы данных в объектном хранилище пригодно для восстановления, как и традиционные файлы резервной копии базы данных.

Части и ограничения на размер файла

В отличие от традиционных файловых систем, хранилище объектов дробит и хранит свои данные в блоках, называемых частями, подобно блочным BLOB-объектам в хранилище Azure. Размер каждой части может изменяться от 5 МБ до 20 МБ, а значение по умолчанию равно 10 МБ. Это поведение контролируется SQL Server через параметр MaxTransferSize в сочетании с Compression.

Для одного URL-адреса под резервное копирование может быть выделено до 10000 частей, поэтому ограничение на размер файла для одного URL-адреса составляет 10000 частей * MaxTransferSize. SQL Server может раздробить одну резервную копию базы данных на 64 URL-адреса, при этом максимально поддерживаемое количество составляет 10000 частей * MaxTransferSize * 64 URL-адреса.

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

Преимущества и распространенные сценарии

Существует два основных преимущества и два варианта использования резервного копирования и восстановления из S3:

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

  • Миграция: возможность легко выполнять резервное копирование/восстановление с
    использованием хранилища S3 упрощает миграцию базы данных.

Комментарии (3)


  1. Tzimie
    25.08.2023 13:27

    Очень сомнительные преимущества


  1. vagon333
    25.08.2023 13:27
    +2

    Я бы оставил каждой задаче свой инструмент:
    - бэкап шустро на локальный диск
    - а затем копия бэкапа на удаленные носители.

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


    1. mentin
      25.08.2023 13:27

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