> For the complete documentation index, see [llms.txt](https://docs.iexexchanger.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.iexexchanger.com/server-i-dannye/upravlenie-cherez-iexctl.md).

# Управление через iexctl

`iexctl` — команда для проверки и обслуживания установленного iEXExchanger. Через неё можно проверить службы, создать резервную копию, изменить параметры Backend и Frontend, восстановить настройки, посмотреть регистрацию сервера и подготовить диагностику для поддержки.

### Где выполнять команды

Подключитесь по SSH к серверу, на котором установлен продукт. Команды обслуживания выполняются от `root` или через `sudo`. В этой инструкции используется `sudo`; в сессии `root` его можно убрать.

{% content-ref url="/spaces/uyjsNtEAtO6Sby8CHWyD/pages/cCEoFDjTDIufy3NUEakd" %}
[Подключение к серверу по SSH](/help-center/upravlenie-serverom/podklyuchenie-k-serveru-po-ssh.md)
{% endcontent-ref %}

После установки команда доступна из любого рабочего каталога. Проверьте её наличие:

```bash
command -v iexctl
```

Основной исполняемый файл находится в `/usr/local/sbin/iexctl`, глобальная команда — в `/usr/local/bin/iexctl`. Если оболочка не находит `iexctl`, используйте полный путь:

```bash
sudo /usr/local/sbin/iexctl --help
```

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

### Справка и версия команды

Открыть общую справку:

```bash
sudo iexctl --help
```

Посмотреть параметры нужной команды:

```bash
sudo iexctl env set --help
sudo iexctl backup operator --help
```

Показать версию `iexctl`:

```bash
sudo iexctl --version
```

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

```bash
sudo iexctl version
sudo iexctl version --format json
```

Это версия управляющей команды. Версия установленного продукта также выводится в отчёте `iexctl doctor`. Для справки и краткой версии доступны короткие флаги `-h` и `-v`.

### Формат вывода и время выполнения

По умолчанию результат выводится как текст. Для обработки в скриптах доступны JSON и YAML:

```bash
sudo iexctl doctor --format json
sudo iexctl services status --format yaml
```

`services logs` поддерживает только текстовый вывод. `backup operator` также возвращает текст: параметр `--format json` или `--format yaml` не преобразует его результат.

Параметр `--timeout` задаёт лимит времени выполнения операции. По умолчанию используется `2h`; значение должно быть больше нуля и не превышать `24h`. Для длительных проверок резервных копий можно увеличить лимит:

```bash
sudo iexctl backup verify --full --timeout 12h
```

Ненулевой код завершения означает ошибку выполнения или непрохождение проверки. Нулевой код у команды просмотра означает, что сведения удалось получить. Готовность и предупреждения оценивайте по самому отчёту; для проверки служб используйте `services verify`.

## Диагностика установленного продукта

`doctor` выполняет диагностику текущей установки. Команда не изменяет настройки и не перезапускает службы:

```bash
sudo iexctl doctor
```

В отчёт входят:

* сохранённое состояние установки и совместимость серверного профиля с текущими управляющими программами;
* соответствие активного релиза состоянию установки и наличие отметки успешной приёмки;
* проверка установленных управляющих программ и глобальной команды `iexctl`;
* готовность служб и проверка конфигурации Nginx;
* версии PHP и Node.js, обязательные расширения PHP и ionCube Loader;
* наличие точной строки CRON для планировщика задач;
* ответ основной базы PostgreSQL и базы Pulse на локальный запрос, доступность локального порта Redis;
* наличие свободного места и inode — записей файловой системы, необходимых для создания файлов;
* готовность резервного копирования, если оно включено.

### Как читать результат

<table><thead><tr><th width="177.66015625">Отметка</th><th>Значение</th></tr></thead><tbody><tr><td><code>OK</code></td><td>Проверка пройдена</td></tr><tr><td><code>WARN</code></td><td>Есть предупреждение, которое нужно оценить отдельно</td></tr><tr><td><code>ERROR</code></td><td>Обязательная проверка не пройдена</td></tr></tbody></table>

Если есть `ERROR`, команда возвращает ненулевой код завершения. Отдельная неудачная проверка не останавливает остальные проверки отчёта.

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

Ошибка `deployment.schema` означает, что серверный профиль требует штатного перехода через обновление продукта. Не исправляйте её ручной заменой служебных метаданных установки.

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

## Управление службами

Команды `services` используют каталог служб текущей установки. Имена служб подбираются автоматически с учётом установленной версии PHP и включённого резервного копирования.

### Состояние и готовность

Посмотреть состояние:

```bash
sudo iexctl services status
```

В текстовом отчёте отображаются имя службы, состояние, автозапуск, оценка работоспособности `health`, время работы и результат последнего выполнения.

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

```bash
sudo iexctl services status --format json
```

Проверить готовность всех служб:

```bash
sudo iexctl services verify
```

Если хотя бы одна служба не готова, `verify` возвращает ненулевой код завершения. `status` предназначен для просмотра и может завершиться успешно при наличии проблем в полученном отчёте.

Оценка `health` помогает отличить доступность процесса от его стабильности:

| Значение                                                  | Что учитывать                                                                                                |
| --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ |
| `stable`                                                  | Служба соответствует условиям стабильной работы                                                              |
| `starting`                                                | Служба запускается, применяет конфигурацию или работает менее 30 секунд                                      |
| `unstable`                                                | Подтверждены не менее трёх аварийных завершений за последние десять минут                                    |
| `degraded`                                                | Служба работает, но проверить причины недавних перезапусков не удалось                                       |
| `stopped`, `disabled`, `failed`, `maintenance`, `unknown` | Служба остановлена, отключена, завершилась ошибкой, находится в обслуживании либо её состояние не распознано |

Успешный `verify` подтверждает готовность по текущему состоянию служб. Значения `starting`, `unstable` и `degraded` требуют отдельной оценки и могут присутствовать при `ready=true`. После перезапуска повторите просмотр состояния, когда завершится начальный период наблюдения.

Накопленный счётчик перезапусков сам по себе не означает аварию. Штатная смена версии Update Agent также может увеличивать этот счётчик; оценка нестабильности учитывает подтверждённые аварийные завершения.

Служба `iex-scheduler.service` выполняется однократно. Состояние `inactive` после успешного выполнения для неё нормально. Ежеминутный запуск задач обеспечивает CRON; состояние проверочной службы не является историей всех запусков планировщика.

### Перезапуск группы

Выберите одну группу:

<table><thead><tr><th width="210.27734375">Группа</th><th>Что выполняется</th></tr></thead><tbody><tr><td><code>frontend</code></td><td>Перезапуск клиентского сайта</td></tr><tr><td><code>backend</code></td><td>Перезапуск PHP-FPM, Horizon, Reverb и служб Pulse, затем проверочный запуск планировщика</td></tr><tr><td><code>all</code></td><td>Действия для Backend и Frontend</td></tr></tbody></table>

Перезапустить Frontend:

```bash
sudo iexctl services restart frontend
```

Перезапустить Backend:

```bash
sudo iexctl services restart backend
```

Перезапустить обе группы:

```bash
sudo iexctl services restart all
```

После действий команда проверяет все службы управляемого каталога. Проблема с другой службой этого каталога также может привести к неуспешному результату. PostgreSQL, Redis и Nginx в эти группы перезапуска не входят.

Перезапуск может кратковременно прервать работу соответствующей части продукта.

### Просмотр журналов

Последние 200 строк журнала Frontend:

```bash
sudo iexctl services logs frontend --lines 200
```

Журналы Backend за последние 30 минут:

```bash
sudo iexctl services logs backend --since '30 minutes ago'
```

Доступные цели:

<table><thead><tr><th width="221.3359375">Цель</th><th>Журналы</th></tr></thead><tbody><tr><td><code>frontend</code></td><td>Frontend</td></tr><tr><td><code>backend</code></td><td>PHP-FPM, Horizon, Reverb и обе службы Pulse</td></tr><tr><td><code>horizon</code></td><td>Обработка очередей</td></tr><tr><td><code>reverb</code></td><td>Reverb</td></tr><tr><td><code>pulse</code></td><td>Обе службы Pulse</td></tr><tr><td><code>scheduler</code></td><td>Проверочная служба планировщика</td></tr><tr><td><code>backup</code></td><td>Служба и таймер резервного копирования, если оно включено</td></tr><tr><td><code>update-agent</code></td><td>Update Agent</td></tr><tr><td><code>all</code></td><td>Все службы доступного управляемого каталога</td></tr></tbody></table>

Выбрать журнал Update Agent:

```bash
sudo iexctl services logs update-agent --since '1 hour ago' --lines 300
```

`--lines` принимает значение от 1 до 10 000; по умолчанию — 200. `--since` задаёт начало периода в формате `journalctl`. Оба параметра можно использовать вместе.

Команда выводит полученные записи журнала. Отсутствие записей за выбранный период не подтверждает работоспособность службы: проверьте её через `services status` и `services verify`.

## Резервное копирование

Команды `backup` работают с резервным копированием, включённым при установке. Репозиторий Restic — хранилище управляемых резервных копий — определяется по состоянию установки. Произвольный репозиторий через эти команды выбрать нельзя.

Если управляемое резервное копирование отключено, команды этой группы сообщат об этом.&#x20;

{% content-ref url="/pages/LBKgvBucM15o8QrI5D99" %}
[Создание резервной копии](/server-i-dannye/sozdanie-rezervnoi-kopii.md)
{% endcontent-ref %}

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

```bash
sudo iexctl backup status
```

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

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

```bash
sudo iexctl backup status --format json
```

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

Копия считается устаревшей после 36 часов. Проверка восстановления считается устаревшей после 31 дня. Отсутствие свежей проверки восстановления выводится как предупреждение и учитывается отдельно от готовности ежедневного копирования.

Если служба, таймер или свежая копия не готовы, `backup status` возвращает ненулевой код завершения.

{% hint style="warning" %}
Если репозиторий находится на одной файловой системе с приложением, отказ этого хранилища затронет и продукт, и локальные копии. Для защиты от отказа сервера храните резервные копии также вне него.
{% endhint %}

### Создание копии вручную

```bash
sudo iexctl backup run
```

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

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

### Список копий

```bash
sudo iexctl backup snapshots
```

По умолчанию показываются последние 20 копий с идентификатором, временем создания и именем сервера. Список выводится от новых копий к старым.

Изменить количество записей:

```bash
sudo iexctl backup snapshots --limit 50
```

`--limit` принимает значение от 1 до 1000.

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

Обычная проверка структуры и согласованности репозитория:

```bash
sudo iexctl backup verify
```

Полная проверка с чтением 100% сохранённых данных:

```bash
sudo iexctl backup verify --full
```

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

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

```bash
sudo iexctl backup restore-test
```

Команда извлекает последнюю управляемую копию в закрытый временный каталог внутри `/var/tmp`. Для этого должно хватать свободного места под извлечённые данные.

Проверка подтверждает наличие восстановленных каталогов общих данных и настроек, а также наличие и читаемость дампов основной базы PostgreSQL и базы Pulse. После проверки временные данные удаляются, а успешный результат сохраняется для последующих отчётов `backup status` и `doctor`.

{% hint style="info" %}
`restore-test` проверяет извлечение файлов и чтение структуры дампов. Импорт в отдельную базу и запуск продукта на восстановленных данных в эту проверку не входят.
{% endhint %}

Сохранённое подтверждение относится к проверенному репозиторию и выполненной проверке. Создание следующей копии не запускает новый `restore-test` автоматически.

### Экспорт баз данных через backup operator

`backup operator` позволяет отдельно проверить конфигурацию экспорта и сохранить дампы основной базы и базы Pulse. Утилита продукта запускается от пользователя приложения, а готовые файлы публикуются в закрытом каталоге.

Проверить конфигурацию и подключения:

```bash
sudo iexctl --timeout 20m backup operator config-check
```

Экспортировать базы с меткой операции:

```bash
sudo iexctl --timeout 20m backup operator export --tag before-manual-change
```

`backup` — синоним `export`. Вместо предыдущей команды можно выполнить:

```bash
sudo iexctl --timeout 20m backup operator backup --tag before-manual-change
```

`before-manual-change` — метка этого экспорта. При необходимости замените её своей меткой.

Глобальные параметры `iexctl`, включая `--timeout`, указывайте перед `backup` или перед `operator`. Параметры после `export`, `backup` или `config-check` передаются утилите экспорта. Переопределять `--env`, `--config`, `--profile` и `--output` через эту команду нельзя.

Результат сохраняется внутри `/var/backups/iexexchanger/operator-db`. Команда выводит путь созданного каталога. Файлы экспорта содержат данные баз и доступны только `root`.

Этот экспорт сохраняет базы данных отдельно. Он не создаёт полную управляемую копию файлов и настроек продукта; для неё используйте `backup run`.

## Управление параметрами Backend и Frontend

Команды `env` работают с двумя файлами настроек:

<table><thead><tr><th width="184.1875">Компонент</th><th>Файл</th></tr></thead><tbody><tr><td><code>backend</code></td><td><code>/etc/iexexchanger/backend.env</code></td></tr><tr><td><code>frontend</code></td><td><code>/etc/iexexchanger/frontend.env</code></td></tr></tbody></table>

Перед фактическим изменением сохраняется закрытая копия исходного файла. Запись выполняется атомарно, с сохранением владельца, группы и прав доступа.

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

### Просмотр параметров

Получить список имён:

```bash
sudo iexctl env list backend
sudo iexctl env list frontend
```

Показать значения несекретных параметров:

```bash
sudo iexctl env list backend --show-values
sudo iexctl env list frontend --show-values
```

Прочитать один параметр:

```bash
sudo iexctl env get backend PARAM_NAME
sudo iexctl env get frontend PARAM_NAME
```

Значения параметров, которые распознаны как секретные, заменяются на `<скрыто>`, в том числе при `--show-values` и выводе в JSON или YAML. Классификация учитывает имя параметра: например, наличие `PASSWORD`, `SECRET`, `TOKEN` или `KEY`.

### Добавление или изменение параметра

Выберите ровно один источник значения: `--value`, `--stdin` или `--value-file`. Значение должно быть однострочным, без символа NUL, размером не более 1 MiB.

#### Несекретное значение

```bash
sudo iexctl env set frontend PARAM_NAME --value 'VALUE' --restart
```

`--value` предназначен для несекретных значений. Для параметра, распознанного как секретный, команда отклонит такой способ передачи.

#### Значение из стандартного ввода

```bash
sudo iexctl env set backend PARAM_NAME --stdin --restart
```

После запуска введите одну строку значения, нажмите Enter, затем Ctrl+D. Значение не попадает в историю команд оболочки.

{% hint style="warning" %}
`--stdin` не отключает отображение вводимых символов в терминале. Для секретов используйте защищённый источник ввода или заранее подготовленный файл с доступом только для `root`. Не вставляйте секрет в команды `echo` или `printf`: он может остаться в истории оболочки.
{% endhint %}

#### Значение из файла

Подготовьте обычный файл `/root/iex-env-value` с одной строкой значения, владельцем `root` и правами `0600`. Если используете другое расположение, укажите полный абсолютный путь.

```bash
sudo iexctl env set backend PARAM_NAME \
  --value-file /root/iex-env-value \
  --restart
```

Команда читает значение из файла и не передаёт его аргументом процесса.

### Удаление параметра

Удалить параметр Backend:

```bash
sudo iexctl env unset backend PARAM_NAME --restart
```

Удалить параметр Frontend:

```bash
sudo iexctl env unset frontend PARAM_NAME --restart
```

Удаляется указанное присваивание. Перед изменением сохраняется копия всего исходного файла.

### Применение изменений в процессах

Без `--restart` команда сохраняет файл и не перезапускает процессы. Чтобы применить настройки в работающих процессах, используйте этот флаг либо отдельно выполните `services restart` для соответствующего компонента.

`--restart` перезапускает службы и проверяет их готовность. Очистка и пересборка кеша Laravel в эту операцию не входят.

Если параметр уже имеет требуемое значение, повторная команда не переписывает файл и не создаёт новую запись изменения. При явно заданном `--restart` службы всё равно перезапускаются и проверяются.

{% hint style="warning" %}
Если изменение файла выполнено, а последующий перезапуск или проверка служб завершились ошибкой, сохранённое значение остаётся в файле. Проверьте службы и их журналы. После исправления причины можно повторить команду с `--restart` или перезапустить нужную группу отдельно.
{% endhint %}

### История изменений

```bash
sudo iexctl env history backend
sudo iexctl env history frontend
```

В истории отображаются идентификатор операции, время, действие, имя параметра либо источник восстановления и статус. Значения параметров в историю вывода не включаются.

По умолчанию показываются 20 записей. Для каждого компонента сохраняются последние 50 операций вместе с копиями файлов. Показать всю сохраняемую историю:

```bash
sudo iexctl env history backend --limit 50
```

`--limit` принимает значения от 1 до 50. Значение `0` также выводит всю сохранённую историю.

Статус `completed` означает завершённое изменение файла; `not-applied` — что после прерванной операции подтверждено отсутствие её применения. Восстановление доступно из записей `completed`.

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

#### Сведения об отдельном изменении

Замените `RECEIPT_ID` идентификатором из истории нужного компонента:

```bash
sudo iexctl env receipt backend RECEIPT_ID
sudo iexctl env receipt frontend RECEIPT_ID
```

`receipt` показывает сведения об операции: действие, статус, время, путь резервной копии и SHA-256 файла до и после изменения. Содержимое настроек не выводится.

### Восстановление файла настроек

Восстановление возвращает файл к состоянию **до выбранной операции**.

#### Проверка плана

Сначала получите план для нужного компонента:

```bash
sudo iexctl env restore-plan backend RECEIPT_ID
```

Для Frontend:

```bash
sudo iexctl env restore-plan frontend RECEIPT_ID
```

План показывает источник восстановления, его время, контрольные суммы текущего и целевого файлов и признак наличия изменений. Значения параметров не выводятся. В текстовом результате также приводится команда применения.

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

Замените `RECEIPT_ID` тем же идентификатором операции, а `CURRENT_SHA256` — точным значением `currentSha256` из только что полученного плана:

```bash
sudo iexctl env restore backend RECEIPT_ID \
  --confirm RECEIPT_ID \
  --expected-current-sha256 CURRENT_SHA256 \
  --restart
```

Для Frontend замените `backend` на `frontend` и используйте план этого компонента.

`--confirm` должен точно совпадать с идентификатором операции. `--expected-current-sha256` защищает от применения устаревшего плана: если файл изменился после планирования, восстановление останавливается до записи. В этом случае заново получите и проверьте план.

{% hint style="warning" %}
Восстанавливается весь файл настроек, поэтому последующие изменения этого компонента будут отменены. Перед заменой текущего файла создаётся новая резервная копия и новая запись истории.
{% endhint %}

Без `--restart` восстановится только файл. С этим флагом также выполняются перезапуск и проверка соответствующих служб.

## Регистрация сервера

Регистрация связывает установленный экземпляр продукта с лицензией в кабинете iEXExchanger. Её выполняет Update Agent при запуске, затем штатно повторяет подтверждение связи каждые три часа.

### Просмотр состояния

```bash
sudo iexctl registration status
```

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

Подробные сведения, включая время попытки и регистрации:

```bash
sudo iexctl registration status --format json
```

<table><thead><tr><th width="207.58203125">Статус</th><th>Значение</th></tr></thead><tbody><tr><td><code>unregistered</code></td><td>Регистрация ещё не подтверждена</td></tr><tr><td><code>registered</code></td><td>Последнее подтверждение связи выполнено успешно</td></tr><tr><td><code>retrying</code></td><td>Последняя попытка завершилась ошибкой; причину показывает <code>lastErrorCode</code></td></tr><tr><td><code>reauth_required</code></td><td>Следующая синхронизация должна заново подтвердить регистрацию</td></tr></tbody></table>

Статус `registered` описывает последний сохранённый результат. Для оценки актуальности связи учитывайте время последнего успешного запроса.

Лицензионный ключ и секрет регистрации в вывод не включаются.

### Немедленная синхронизация

```bash
sudo iexctl registration sync
```

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

После завершённого обновления или отката можно выполнить `sync`, чтобы сразу передать сведения о текущей версии, не дожидаясь очередной фоновой синхронизации.

Для первичной регистрации сервер должен иметь публичный IP-адрес на активном сетевом интерфейсе. Адрес прокси или CDN не заменяет адрес сервера.

### Причины ошибок регистрации

В структурированном выводе код находится в `lastErrorCode`; текстовый отчёт выводит его как код последней ошибки.

<table><thead><tr><th width="289.60546875">Код</th><th>Что делать</th></tr></thead><tbody><tr><td><code>remote_retryable</code></td><td>Временная ошибка удалённого сервиса или ограничение запросов; дождитесь автоматического повтора</td></tr><tr><td><code>transport_or_local_error</code></td><td>Проверьте сетевой доступ и локальные данные установки; подробности есть в ошибке команды и журнале Update Agent</td></tr><tr><td><code>unauthorized</code>, <code>not_found</code></td><td>Следующий <code>sync</code> повторно подтвердит регистрацию установленной лицензией</td></tr><tr><td><code>credential_unavailable</code></td><td>Проверьте доступность локального секрета регистрации; ошибка прав или повреждение файла требуют проверки оператора</td></tr><tr><td><code>remote_rejected</code></td><td>Проверьте статус лицензии и разрешение на подключение этого экземпляра</td></tr><tr><td><code>registration_conflict</code></td><td>Проверьте привязку лицензии и IP; при переносе используйте штатную процедуру смены сервера</td></tr><tr><td><code>transfer_pending</code></td><td>Заявка на смену сервера ожидает решения; после подтверждения повторите подключение в разделе «Обновления»</td></tr></tbody></table>

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

`registration sync` не создаёт заявку на смену сервера и не изменяет разрешённый IP лицензии. Перенос оформляется через раздел «Обновления» на новом сервере.

## Ресурсы сервера и прогноз

Команды `resources` показывают фактические замеры и прогноз по сохранённой истории. Update Agent собирает первый замер при запуске, затем повторяет сбор каждый час.

### Текущий замер

Собрать и сохранить внеплановый замер:

```bash
sudo iexctl resources sample
```

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

Текстовый вывод содержит основные показатели. Полный замер доступен в структурированном формате:

```bash
sudo iexctl resources sample --format json
```

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

### История замеров

```bash
sudo iexctl resources history
```

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

```bash
sudo iexctl resources history --limit 72
```

`--limit` принимает значение от 1 до 2160. Сохраняются последние 2160 замеров — примерно 90 дней при штатном ежечасном сборе. Ручные замеры также входят в этот лимит.

### Прогноз заполнения

```bash
sudo iexctl resources forecast
```

Прогноз рассчитывается по сохранённой истории. Чтобы учесть текущее состояние, перед ним выполните `resources sample`.

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

Безопасный порог для прогноза — 85% заполнения файловой системы.

| Статус                 | Значение                                                                       |
| ---------------------- | ------------------------------------------------------------------------------ |
| `insufficient_history` | Данных пока недостаточно для прогноза роста                                    |
| `stable`               | Расчётный запас превышает 30 дней либо положительный рост до порога не выявлен |
| `warning`              | Порог ожидается более чем через 7, но не позднее чем через 30 дней             |
| `critical`             | Порог уже достигнут или ожидается не позднее чем через 7 дней                  |

Уже достигнутый порог отмечается как `critical`, даже если ещё нет достаточной истории или рост отсутствует. После изменения ёмкости диска прогноз использует только замеры для новой ёмкости; историю до расширения не смешивают с новой серией.

Получить полный результат, включая расчётные сроки:

```bash
sudo iexctl resources forecast --format json
```

Прогноз служит рекомендацией по запасу места. Он не меняет конфигурацию сервера и не заменяет требования к продукту из статьи «Системные требования». История ресурсов остаётся на сервере.

{% content-ref url="/pages/RjtzBZHtqwFTm8nJo8p8" %}
[Системные требования](/ustanovka-i-obnovlenie/sistemnye-trebovaniya.md)
{% endcontent-ref %}

## Диагностический комплект для поддержки

Создать комплект:

```bash
sudo iexctl support bundle
```

Команда сохраняет диагностический архив и файл контрольной суммы внутри `/var/lib/iexexchanger/support`. В результате выводятся путь архива, SHA-256, путь файла контрольной суммы, размер и количество файлов.

Комплект содержит сведения об установке и версиях, результаты диагностики, состояния служб и резервного копирования, состояние регистрации, прогноз ресурсов, сведения о последних операциях установки, обновления и отката, а также диагностику Update Agent.

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

В комплект не включаются содержимое файлов настроек, пароли и ключи, дампы баз, строки таблиц и необработанные журналы служб. Свободный текст причины ручной паузы обновлений также исключается.

Архив и контрольная сумма доступны только `root`. Комплект содержит технические сведения об установке и доменах; передавайте его поддержке по согласованному защищённому каналу.

## Проверка после обслуживания

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

```bash
sudo iexctl services verify
sudo iexctl doctor
```

При включённом резервном копировании дополнительно проверьте:

```bash
sudo iexctl backup status
```

Проверьте готовность служб и их оценку `health`, отсутствие обязательных ошибок диагностики и наличие свежей резервной копии. Предупреждения о восстановлении и расположении копий оцените отдельно.

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