Этот формат позволит пользователям легко восстанавливать command_topic с помощью сценариев производителя Kafka.

Например:

### Рабочий процесс

Когда KSQL запускается, он всегда читает командную тему с начала. Если файл резервной копии ещё не существует, то он создаст новый файл и начнёт добавлять в него каждое сообщение command_topic.
Файл резервной копии не будет найден, если это первый раз, когда включены резервные копии, или если service.id службы KSQL отличается от тех, что указаны в именах файлов резервных копий.

Если существует файл резервной копии с тем же service.id KSQL, то KSQL будет добавлять только новые сообщения command_topic в этот файл.

KSQL будет сравнивать каждое потреблённое сообщение command_topic со следующей строкой из файла резервной копии. Если оба сообщения разные, то оно считает command_topic новой восстановленной темой, поэтому KSQL создаст новый файл резервной копии, скопирует все прочитанные сообщения в файл и продолжит добавлять новые сообщения в него. Если больше нет сообщений, прочитанных из файла резервной копии (EOF), то KSQL считает этот файл текущим и будет продолжать добавлять сообщения в него.

KSQL не будет использовать смещения для сравнения с файлом резервной копии. Он будет считать, что каждое смещение начинается с 1, начиная потреблять сообщения из темы и читая сообщения из файла.

### Производительность

Метахранилище KSQL не должно стать большим файлом. Добавление каждой новой команды в файл происходит быстрее. Сообщения команд KSQL невелики, чтобы вызывать замедление во время записи файла резервной копии.
Это, безусловно, добавит дополнительное время при перезапуске KSQL, но, учитывая среднюю задержку ввода-вывода в 10 мс на запись, создание начальной резервной копии займёт около 5 секунд для 500 команд. Также, используя тот же пример из 500 команд и средний размер 4 КБ на команду (используя размер команды потока ksql_processing_log в качестве примера), этот файл резервной копии вырастет до 2 МБ.

## План тестирования

- Модульные тесты.
- Интеграционные тесты для проверки работы шагов резервного копирования и восстановления.

## Этапы и сроки выполнения

Это небольшая функция, которая может занять неделю или меньше.

## Обновление документации

Будет написана документация о том, как включить резервное копирование и восстановить командную тему вручную.

## Последствия для совместимости

Это новая функция, которая не влияет ни на одну другую функцию KSQL или компонентов CP.

## Последствия для безопасности

Резервные копии будут находиться вне среды Kafka. Если в Kafka настроено шифрование, метахранилище KSQL не будет зашифровано в локальной файловой системе.
Пользователю потребуется предоставить среду для шифрования на уровне файлов или дисков, чтобы соответствовать требованиям безопасности своей организации.

В случае, если в Kafka настроены списки контроля доступа (ACL), файл будет доступен неавторизованным пользователям, имеющим доступ к кластеру KSQL.
Однако это не считается проблемой безопасности, если резервная копия находится в тех же частных каталогах KSQL, потому что эти пользователи всё равно будут иметь доступ к файлу ksql-server.properties, который содержит учётные данные пользователя для доступа к командной теме в Kafka. Это ограничение доступа является частью конфигурации системного администратора, позволяющей определённым пользователям получать доступ к файлам KSQL. Но если местоположение находится вне каталога KSQL, пользователям необходимо будет предупредить (в документации), чтобы обеспечить правильные правила безопасности для защиты резервной копии метахранилища от несанкционированного просмотра».