Перейти к основному содержимому

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

Резервная копия состоит из двух частей, и одна без другой бесполезна:

  1. База данных — события, политики, операторы, ключ подписи расширения (в зашифрованном виде).
  2. Секреты установки — файл .env (Docker) или /etc/tetra/config.yaml (пакет). Там пароль базы, токен сенсоров, ключ сессий и ключ шифрования crx_secret_key.
Секреты храните отдельно от дампа базы

Ключ подписи расширения лежит в базе зашифрованным. Дамп базы плюс crx_secret_key в том же архиве = возможность подписать пакет расширения для вашего парка. Храните обе части в разных местах, с разным доступом.

И наоборот: потеря crx_secret_key означает новый ID расширения и повторную раздачу расширения на все рабочие станции.

Дамп базы​

Встроенный PostgreSQL (Docker):

docker compose exec -T db pg_dump -U tetra tetra > tetra-backup-$(date +%F).sql

Внешний PostgreSQL:

pg_dump "postgres://tetra:ПАРОЛЬ@postgres.example.local:5432/tetra" > tetra-backup-$(date +%F).sql

Ставьте это в расписание (cron, systemd timer) с той же периодичностью, что и остальные базы организации, и обязательно проверяйте восстановление хотя бы раз — непроверенная копия не копия.

Восстановление​

Docker:

docker compose down            # том с данными сохраняется
docker compose up -d db
cat tetra-backup-2026-07-28.sql | docker compose exec -T db psql -U tetra -d tetra
docker compose up -d

Пакет deb/rpm:

sudo systemctl stop tetra
psql "postgres://tetra:ПАРОЛЬ@localhost:5432/tetra" < tetra-backup-2026-07-28.sql
sudo systemctl start tetra

Восстанавливайте базу вместе с тем же crx_secret_key, который действовал на момент дампа. Если сервер после восстановления пишет в лог wrong encryption key — верните исходное значение ключа, не меняйте его и не удаляйте запись: сам ключ подписи при этом целый.

Что стоит хранить дополнительно​

  • Код лицензии (его же выдаст поддержка при необходимости).
  • Актуальный блок политики Chrome — на случай, если придётся раскатывать заново. Его в любой момент можно заново взять в панели.

Сколько хранить события​

Отдельного механизма ротации событий в текущей версии нет — глубину хранения регулируйте средствами вашей СУБД, если объём станет заметным. Оценка объёма зависит от числа сотрудников и активности использования AI-сервисов; для планирования дисков смотрите фактический рост таблицы за первый месяц эксплуатации.