Меня зовут Михаил, я работаю в Magnit Tech и занимаюсь внедрением 1C платформы на операционную систему Linux. В этой статье я расскажу, как реализовать создание резервных копий бакетов S3-совместимого объектного хранилища MinIO.

(Сразу дам спойлер: нам удалось это сделать с наименьшими затратами места на диске с использованием инкрементальных бэкапов).

В платформе 1С с версии 8.3.23 появилась поддержка работы с объектным хранилищем S3. Все файлы, которые раньше записывались в БД теперь  могут быть автоматически адресованы в объектное хранилище. При этом основной недостаток 1С – это то, что любое изменение файлов в хранилище  приводит к удалению старого файла и созданию нового с новым именем.

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

Краткое описание понятий (погружение в теорию)

Если вы шарите в MinIO или в других схожих S3-совместимых объектных хранилищах, то пропускайте этот раздел, тут мы пройдемся по базе MinIO.

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

Cловарь терминов

• MinIO S3 - это S3-совместимое (Simple Storage Service / Сервис простого хранилища) объектное хранилище, которое предоставляет доступ к содержимому через протоколы HTTP/HTTPS, оно состоит из выделенных одноуровневых ячеек хранения - бакетов, в которых хранятся файлы (объекты) по указанным префиксам, например, "https://127.0.0.1:9001/mybucket/myfile" .

• Бакет (Bucket / Корзина) отдельная ячейка хранения группы объектов со своей конфигурацией, содержащей правила предоставления доступа, удержания объектов, включение версионирования и т.п. Множество бакетов легко воспринимать как одноуровневую файловую структуру, где ниже бакета спуститься нельзя, то есть все что идет после бакета - это не папки как файловой структуре, а префиксы (пространство имен) по которым мы можем различать объекты между собой.
  Соответственно пустых префиксов в бакете быть не может. Пример, префикса в формате URL с HTTPS протоколом: "https://127.0.0.1:9001/mybucket/folder-with-png/image.png".

• Объекты (Objects) - это файлы различных форматов (CSV, XLS, TAR, ZIP, MP3, MP4, JPEG, PNG и т.д.), которые хранятся в бакете.

• Префикс (Prefix) является ключом для доступа к объекту. Он представляет из себя строку, состоящую из наименований уровней иерархии, например, "folder1" и разделителей, например "/". Он создается только при создании объектов и не может существовать без них. Префикс позволяет имитировать структуру файловой системы.

Более кратко понятия изложены в словаре официальной документации MinIO

S3-совместимое объектное хранилище мы можем выбрать в роли альтернативы для хранения неструктурированных данных. Например, мы можем хранить таблицы (CSV, XSLX), видео, картинки, аудио (MP4, JPEG, PNG, MP3) и так далее.

Одним из его основных преимуществ является возможность производить горизонтальное масштабирование.

Помимо MinIO S3 имеется множество различных реализаций этого хранилища, например, AWS S3, Google Cloud Storage, Azure Cloud.

Основное использование MinIO S3 - это разгрузка БД, в которых хранятся BLOB (Binary Large OBject) файлы (картинки, архивы и прочие неструктурированные данные, безжалостно пожирающие место на жестком диске).

Пример кейса из реальной жизни: у нас при переносе 1C с серверов Windows Server на Linux встретились тяжеловесные БД MS SQL Server, где большей частью размеров оказались неструктурированные данные.

На этом наше теоретическое введение заканчивается. Перейдем к основной части

Чего мы хотим

Процитирую задачу:

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

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

Удивительно, но найти ответ на вопрос «Как бэкапить бакет?» оказалось не так просто. Поисковик Google и даже всезнающая LLM DeepSeek не выдавали нам релевантный ответ. В конце концов приняв тот факт, что эта тема не имеет широкого распространения мы обратились к официальной документации MinIO! И тут мы также не встретили готового решения. Разве что только намеки на то как это можно реализовать.

Этот шаг можно тоже пропустить, так как тут я только описываю установку базовых инструментов - Docker, CLI клиент и сервер MinIO перед изучением различных решений, которые я находил в процессе исследования вопроса.

Предварительная подготовка инструментов MinIO:

Для того чтобы мы могли практически убедиться в работе исследуемых решений мы решили развернуть тестовый сервер MinIO с топологией Single-Node Single-Drive (SNSD) в Docker контейнере, поскольку это просто и не требует много времени на настройку (ссылочка на инструкцию по установке сервера minio).

Для администрирования нашего сервера мы взяли заботливо предложенную утилиту mc.

Инструменты и их версии:

Сервер MinIO - RELEASE.2024-11-07T00-52-20Z

CLI клиент MinIO mc - RELEASE.2024-11-17T19-35-25Z

Docker клиент и сервер - версия 27.3.1, API версии 1.47

Развертывание тестового MinIO сервера с помощью Docker:

$sudo docker pull minio/minio:latest
$sudo mkdir -p /var/minio/data
$sudo docker run -d \
    -p 9000:9000 \
    -p 9001:9001 \
    --name minio \
    -v /var/minio/data:/data \
    -e "MINIO_ROOT_USER=ROOTNAME" \
    -e "MINIO_ROOT_PASSWORD=CHANGEME123" \
    minio/minio server /data --console-address ":9001"

Как видно для сервера мы указали переменные MINIO_ROOT_USER и MINIO_ROOT_PASSWORD, они указывают имя и пароль root пользователя. Запоминаем их.

После запуска сервера в Docker контейнере мы можем войти в консоль MinIO в браузере под именем root пользователя по следующему URL “http://localhost:9001/":

Отлично! Мы имеем свой локальный MinIO сервер и можем иметь к нему доступ через консоль в браузере (MinIO Web интерфейс).

Так как консоль не может покрыть все наши административные “хотелки”, мы дополнительно установили CLI клиент MinIO - mc.

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

Установка mc на нашу тачку с ОС Linux и архитектурой 64 bit Intel производиться с помощью следующих команд:

$curl https://dl.min.io/client/mc/release/linux-amd64/mc \
  --create-dirs \
  -o $HOME/minio-binaries/mc
$chmod +x $HOME/minio-binaries/mc
$export PATH=$PATH:$HOME/minio-binaries/

Проверка работы:

$mc --help

Указываем alias развернутого MinIO сервера для mc c указанием имени и пароля пользователя под которым будем выполнять операции:

$mc alias set local http://localhost:9000 ROOTNAME CHANGEME123

Проверяем все ли на месте командой mc ping:

$mc ping local

Результат:

Немного про mc:

mc - он же CLI клиент MinIO, удобный инструмент для взаимодействия как с локальной файловой системой, так и с S3-совместимым хранилищем, то есть как и в Unix системах мы имеем стандартные команды ls, cp, mv, rm, вместо rsync - mirror для работы с файловой системой и с S3, также имеем команды работающие только для S3-совместимого хранилища, например, mc admin info.

Он имеет два режима: mc и mc admin

mc - для любого хранилища

mc admin - только для работы с MinIO S3 и AWS S3

Получив все базовые инструменты мы можем перейти к самой увлекательной рубрике ээээксперементы!

Поиск решения

Для понимания того насколько решение полное требуется иметь ответы на следующие вопросы:

1. Что вообще представляет из себя конфигурация бакета?

2. Что мы можем знать об объектах?

Ответ на первый вопрос:

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

Конфигурация бакета состоит из следующих опций:

• Версионирование объектов (Versioning)
  Описание: Позволяет хранить несколько версий одного объекта, что полезно для восстановления данных после случайного удаления или перезаписи. Версионирование объектов может быть включено "enabled" единожды и после только приостановлено "suspended" [ссылка].
  Применение: Включается для обеспечения возможности восстановления предыдущих версий файлов.

• Политики удержания объектов (Object Lock)
  Описание: Позволяет блокировать объекты от удаления или изменения на определенный период времени.  Эту опцию можно включить только при создании бакета и только с версионированием.

• Применение: Используется для обеспечения неизменности данных, что важно для соответствия нормативным требованиям.

• Квота (Quota)
  Описание: Позволяет ограничивать объем данных, которые могут быть сохранены в бакете.
  Применение: Используется для контроля использования ресурсов.

• Теги (Tags)
  Описание: Тегирование позволяет добавлять метаданные к объектам в виде ключевых пар (ключ-значение). Теги могут использоваться для классификации, поиска и управления объектами.
  Примечание:
  Теги полезны для организации данных и применения политик на основе метаданных. Теги можно использовать в сочетании с Object Lifecycle Management и Access Control.

• Жизненный цикл объектов (ILM / Object Lifecycle Management)
  Описание: Позволяет автоматически удалять или перемещать объекты по истечении определенного времени или при выполнении других условий.
  Применение: Используется для оптимизации хранения и управления данными.

• Цели бакета (Bucket targets)
  Описание: Целевые места транспортировки объектов, при истечении установленного срока или для размещения объектов на удаленном сервере.

Ответ на второй вопрос:

Объекты в MinIO — это единицы данных, которые хранятся в бакетах. Каждый объект имеет следующие характеристики:

• Ключ (Key): Уникальный идентификатор объекта в бакете.

• Метаданные (Metadata): Дополнительная информация об объекте, такая как тип содержимого, размер, дата создания и пользовательские теги.

• Опционально версия (Version): Если версионирование включено, объект может иметь несколько версий, каждая из которых сохраняется отдельно.

• Уровень хранения (Storage Tier): Объект может находиться на горячем, холодном или архивном уровне хранения в зависимости от настроек Tiering.

Итого в плане бакетов нам интересно сохранять только метаданные бакета, квоту, настройки жизненного цикла объектов, в плане содержимого - объектов нам интересно только сохранять их метаданные.

1. Версионирование объектов

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

Главная фишка такого решения заключается в сохранении версий объектов с учетом изменений и удалений, то есть те файлы, что 1C удалил будут сохранены, а удаление файлов будет помечено на конкретную дату.

При необходимости посмотреть, восстановить или удалить версии их можно фильтровать по дате, возрасту или на крайний случай по ID версии.

И прилагающиеся следующие проблемы:

• Сохраняются только версии объектов, без сохранения конфигурации.

• Место на диске занимается не эффективно, так как MinIO не предоставляет инкрементный или дифференциальный тип версионирования, поэтому каждая новая версия будет иметь свой полный размер (За исключением удалений). Это может сильно сказаться на потреблении пространства диска.
  MinIO does not perform incremental or differential-type versioning. For mutation-heavy workloads, this may result in substantial drive usage by older or aged object versions. [ссылка] (Свернуть)
  Например, мы имели громоздкий файл ZIP на 30 Гб и чуть-чуть поменяли, добавлением 1 Гб данных, в итоге у нас имеется 2 версии: V1 размером 30 Гб и V2 размером 31Гб.

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

• Перенос версий возможен только с помощью репликации.

Посмотрим как производить базовые операции для включения версионирования, как отображать версии объектов, как производить восстановление версии. 

1.1 Включение версионирования бакета

Версионирование включается у бакета как при его создании, так и после. При выключении версии объектов не будут удалены и при загрузке нового объекта ему будет присвоен ID null. Более подробно об версионировании бакета можно узнать из официального источника MinIO.

Включение версионирования бакета при создании:

Пример:

Включение версионирования у бакета, если оно выключено:

$mc version enable <server-alias>/<bucket>

Пример:

Проверка наличия версионирования:

$mc version info –json <server-alias>/<bucket>

Пример:

1.2 Просмотр файлов в бакете

Любая версия в бакете имеет присвоенный уникальный ID, а также маркер, который может иметь значение либо PUT - загружен, либо DEL - удален.

Чтобы посмотреть на версии можно использовать как Web интерфейс MinIO “консоль”, так и любой совместимый с MinIO CLI клиент, например, mc, rclone, aws и так далее.
Предварительно повторим ситуацию, когда мы имеем файл в бакете с несколькими версиями.

Для этого помещаем файл в бакет с версионированием и производим его удаление, после вносим изменения в локальный файл и загружаем его в бакет с новым именем:

# Включаем у существующего бакета версионирование
$mc version enable local/cs-bucket
# Помещаем файл в бакет
$mc put S3_on-premis_ОС.xlsx local/cs-bucket
# Удаляем файл в бакете
$mc rm local/cs-bucket/S3_on-premis_ОС.xslx 
# Вносим изменения в файл 
$echo “New altering!” >> S3_on-premis_ОС.xslx 
# Помещаем файл с изменениями в бакет с заданным наименованием
$mc put S3_on-premis_ОС.xslx local/cs-bucket/S3_on-premis_ОС-new-name.xslx
# Теперь отображаем что же у нас получилось:
# Команда, чтобы отобразить все версии файлов, которые не младше 5 секунд
$mc ls –rewind "0d0h0m5s" --versions local/cs-bucket

Версии объектов в бакете с включенным версионированием выглядят следующим образом:

Как видно удаленные файлы помечаются меткой DEL и вся их функция заключается в том, чтобы сообщать пользователю о том, что этот файл был удален в указанное время.

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

1.3 Восстановление версии

Вот тут мы наткнулись на камень.

Восстановить версию объекта с помощью клиента нельзя в обычном понимании, введя одну команду.

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

Так мы создадим вторую версию действующего файла, которая основана на содержимом прошлой версии.

$mc cp

Восстановление запускается по ID версии объекта.

Самый простой способ использовать Web интерфейс, где можно отобразить все версии объекта и восстановить выбранную.

Для этого мы можем зайти в консоль и выбрать интересующий нас объект.

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

Иначе нам придется плясать танцы с бубном, поскольку альтернатива - выгружать объект нужной версии

2. Синхронизация содержимого

Тоже очень простая идея синхронизировать содержимое бакета с содержимым бакета с версионированием.

Для этой задачи можно использовать множество инструментов: mc mirror, rclone, restic и тому подобные инструменты наподобие rsync.

Мы же покажем только mc mirror и rclone

mc mirror local/mybucket local/mybucket-versions

2. Репликация бакета

Второй вариант который мы рассматривали – репликация бакета.

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

Идея заключается в том, чтобы производить синхронизацию бакета из серверера источника в сервер хранения версий состояния файлов.

Она нас заинтересовала возможностью сохранять все опции бакета. Однако, как оказалось это решение неэффективно, поскольку вместо 1 сервера нам потребуется запускать 2, и вместо пачки версий объектов мы будем хранить 2 пачки версий объектов.
По нему мы не будем проходить долго, так как изначально это модифицированная версия первого подхода.
То есть теперь мы будем производить сохранение полной резервной копии бакета каждый раз когда будет происходить изменение.
В плане выполнения пункта об эффективности мы сразу же скажем, что 
Имеется 2 варианта репликации:

Репликация бакета со стороны клиента - mc mirror (сохраним только объекты)

Client-side Bucket Replication

Use the command process to synchronize objects between buckets within the same S3-compatible cluster or between two independent S3-compatible clusters. Client-side replication using mc mirror supports MinIO-to-S3 and similar replication configurations. [Ссылка]

Репликация бакета со стороны сервера

Репликация бакета (не site) фактически создает реплику на указанный бакет с сохранением конфигурации (за некоторыми исключениями) и с сохранением содержимого в другое S3 совместимое хранилище (MinIO, AWS S3, Google Cloud Storage, Azure BLOB Storage).

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

Репликация включается .. так-то

Бакет восстанавливается из репликации ... так-то

4. Бэкап данных minio-data с указанием конкретного бакета

Третий вариант, который мы нашли за исключением одного большого НО появился у нас в мыслях на основе комментария на stack-overflow. Смысл подхода прост - бэкапить папку с minio-data, причем только того бакета, который нам требуется. Итого мы имеем бэкап бакета, который будет хранить в себе состояние всех файлов на указанный промежуток времени.

А теперь большое НО:

Стоит отметить, что идея не официальная и ни в коем случае не поддерживается разработчиками MinIO (из описания официальной документации). Тем не менее, она работает и может послужить в некоторых случаях как выход из ситуации когда требуется производить бэкап состояния одного или нескольких бакетов MinIO сервера, где кластер имеет только один диск.

Как реализовать:

1) В качестве источника содержимого бакета мы используем путь указанный при развертывании MinIO сервера, например, /var/minio/data/<bucket>

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

Например мы захотели воссоздать наш бакет test1 с сервера local на сервере test. Для этого мы используя WinSCP производим незатейливую манипуляцию копирования папки.

Проверяем результат на локальном и тестовом сервере

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

5. Официальное и правильное решение бэкап объектов бакета и его снапшота конфигурации

Оказалось, что поговорка «Хочешь что-то спрятать – положи на самое видное место» действительно работает.

Кто бы мог подумать, что ответ на вопрос «Можно ли вообще целиком бэкапить бакет в MinIO» будет найден.

Описание решения бэкапа конфигурации бакета и его содержимого находилось на официальном сайте во второй главе «Manage Existing MinIO Deployments» (Управление существующими развернутыми серверами MinIO) в 4 подглаве «Migrate from Gateway or Filesystem Mode»  (Миграция из режима Gateway или Filesystem). Причем создание бэкапа бакета имеет понятное и последовательное описание за что стоит сказать отдельное спасибо разработчикам документации MinIO.

Решение для бэкапа и последующего восстановления бакета (не только объектов, но и конфига) без различных развертываний дополнительных MinIO серверов, переброски только объектов и ручного воссоздания бакета со всеми его настройками на сервере состоит только из 4 команд CLI интерфейса MinIO - mc.

Описание команд на момент написания статьи для бэкапа конфигураций кластера указано здесь.
Описание последовательности действий на момент написания статьи бэкапа бакета указано на странице про миграцию из режима Gateway или Filesystem (здесь) в разделе Procedure на 4 шаге при выборе типа развертывания Filesystem Mode.

5.1 Сохранение метаданных бакета и его восстановление на сервере развертывания

Итак, чтобы сохранить метаданные бакета нам предоставляется команда CLI клиента mc

$mc admin cluster bucket export <server-alias>/<bucket>

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

• bucket targets

• lifecycle rules

• notifications

• quotas

• locks

• versioning

Например, у cs-bucket снапшот будет именоваться cs-bucket-cs-bucket-metadata.zip 

Аналогично для восстановления бакета имеется схожая команда:

$mc admin cluster bucket import <server-alias>/ <path/to/METADATA.zip>

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

Остается только получить содержимое бакета с помощью команды синхронизации:

$mc mirror –preserve <server-alias>/<bucket> <path/to/sync/objects>

То есть мы синхронизируем содержимое локальной папки с содержимым  бакета в одну сторону

Для восстановления содержимого мы можем сделать обратное действие:

$mc mirror –preserve <path/to/saved/objects> <server-alias>/<bucket>

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

Ссылка на проект GitLab: https://coderepo.corp.tander.ru/expertise-center-1c/1c_backup_and_recovery_buckets_minio_s3

Описание проекта

Нами был создан проект на GitLab 1c_backup_and_recovery_buckets_MinIO_S3

Он состоит из 2 основных скриптов:

1) bucket_backup.sh - создание полного или инкрементального бэкапа

2) recovery_bucket.sh - восстановление бакета на сервере

Для реализации создания полного и инкрементного бэкапа была использована утилита tar.

Алгоритм создания инкрементального бэкапа:

1. Смотрим какая версия была до этого

2. Если это самый первый бэкап, то имеем в виду, что tar должен сделать 0 уровень (полный), иначе 1 .. N уровень (инкрементальный бэкап)

3. Экспортируем метаданные бакета в созданную папку

4. Синхронизируем содержимое бакета с локальной папкой для содержимого

5. Создаем бэкап из этих папок

Пример получаемой структуры инкрементальных бэкапов:

Алгоритм восстановления инкрементального бэкапа:

1. Получаем номер версии для восстановления

2. На основе полученного флага устанавливаем как бэкап требуется восстановить с помощью tar

3. Восстанавливаем архив с версией конфига и содержимого в папку restoration

4. Производим импорт конфига бакета на указанный сервер (создание включено, если нет)

5. Производим синхронизацию файлов локальной папки с бакетом в одну сторону

Пример получаемого локального бэкапа:

Пример полученного бакета на сервере:

Методы резервного копирования

Очередной филиал словарика, который можно спокойно пропустить, если в теме инкрементальных и дифференциальных бэкапов:

Бэкап – это резервная копия множества файлов и папок. Основной задачей решаемой бэкапированием является создание копии файлов и папок и помещение их в общий контейнер.

Основных методов резервного копирования существует 3 - создание полного бэкапа, создание дифференциального бэкапа и создание инкрементального бэкапа.

Полный бэкап - все содержимое помещенное в один архив.

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

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

У каждого из методов имеются преимущества и недостатки

• Полный бэкап быстрее восстанавливается, но занимает много места

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

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

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

В tar  при создании инкрементального бэкапа 0 уровня мы сохраняем всю информацию о начальном содержимом полного бэкапа, так как по факту 0 уровень - это полный бэкап, но с сохранением истории изменений в отдельный снапшот файл *.snar

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

По поводу эффективной стратегии

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

tar при восстановлении содержимого может производить манипуляции по замене файлов и папок, а также по их удалению в папке, которая хранит не архивированное содержимое бакета, в соответствии с информацией указанной в снапшот файле *.snar 

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

Использование решения

Сначала мы должны убедиться, что у нас имеются следующие инструменты:

Как выглядят сохраненные бэкапы бакета с взятого нами сервера:

Как выглядит структура восстановленной версии (содержимое бакета и снапшот метаданных):

Заключение

Для задачи бэкапа бакетов MinIO без строгого ограничения по месту на жестком диске достаточно использовать подготовленные команды клиента mc

Это не сложно и легко автоматизируется с помощью обертки в скрипт на любом удобном для вас языке (SH, BASH, Powershell, Python) и обычного планировщика задач (CRON).

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

В плане автоматизации мы также оборачиваем всю логику в удобный для вашего коллектива язык (BASH, Python) и запускаем его в CRON.

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

Такое решение не является BEST PRACTICES, конечно, но имеет место быть.

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

Для тех, кто дошел аж досюда -- подготовил чек-лист:

Чек-лист

Версионирование бакета
Результат: Решает только проблему удаления объектов с учетом удалений.
Недостатки:

• Не позволяет сохранять состояние бакета целиком.

• Восстановление версий объектов трудоемкая операция.

• Каждая версия объекта, кроме маркеров удаления, храниться целиком без инкрементальной или дифференциальной стратегии.

Синхронизация содержимого
Результат: Решает только проблему удаления объектов.
Недостатки:

• Не позволяет сохранять состояние бакета целиком.

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

• Появляется зависимость от использования планировщика задач.

Репликация бакета
Результат: Сохраняет идентичное текущее состояние бакета целиком.
Недостатки:

• Требует обязательного развертывания нового сервера MinIO.

• Не хранит все версии состояния бакета.

• Неэффективно расходуется дисковое пространство.

Сохранение данных MinIO
Результат: Сохраняет состояние бакета частично - имя бакета и его содержимое.
Официальное решение - бэкап объектов бакета и его снапшота конфигурации
Результат: Решает проблему сохранения состояния бакета целиком (объекты и конфигурация).

Недостатки:

• Неэффективная стратегия хранения резервных копий бакетов.

Официальное решение - бэкап объектов бакета и его снапшота конфигурации с использованием tar
Результат: Решает проблему сохранения состояния бакета целиком (объекты и конфигурация).
Недостатки:

• Привязка к определенной платформе - Linux.

• Неэффективное хранение архивированных файлов.