chore: tune backup function and related docs

docs/configuration/env-vars.md

@@ -84,8 +84,6 @@
 | `BACKUP_PG_DUMP_TIMEOUT_SECONDS` | Таймаут выполнения `pg_dump`. |
 | `BACKUP_PG_RESTORE_PATH` | Путь к `pg_restore` внутри backend-контейнера для восстановления из админки. |
 | `BACKUP_PG_RESTORE_TIMEOUT_SECONDS` | Таймаут выполнения `pg_restore`. |
-| `BACKUP_ARCHIVE_SIGNATURE_REQUIRED` | Требовать валидную HMAC-подпись `manifest.json` при upload/restore. По умолчанию `True`. |
-| `BACKUP_ARCHIVE_SIGNATURE_SECRET` | Отдельный секрет подписи backup-архивов. Если пусто, используется `BOT_TOKEN`. |
 | `BACKUP_COMPOSE_ENABLED` | Добавлять snapshot compose-каталога в архив. Если mount отсутствует, бэкап БД не падает. |
 | `BACKUP_COMPOSE_SOURCE_DIR` | Путь внутри контейнера к compose-каталогу. В стандартном compose это `/app/compose-source`. |
 | `BACKUP_COMPOSE_RESTORE_DIR` | Куда восстанавливать compose-файлы. Если пусто, используется `BACKUP_COMPOSE_SOURCE_DIR`. |

docs/features/backups.md

@@ -24,23 +24,26 @@ remnawave-minishop-backup-20260527-120000+0300.zip
 
 Основные параметры доступны в админке: **Система -> Настройки -> Бэкапы**.
 
-Минимальный `.env`:
+Минимальный `.env`, если `LOG_CHAT_ID` уже задан и подходит для бэкапов:
 
 ```env
 BACKUP_ENABLED=True
-BACKUP_CHAT_ID=-1001234567890
-BACKUP_INTERVAL_SECONDS=3600
-BACKUP_LOCAL_RETENTION=100
-BACKUP_COMPOSE_ENABLED=True
-COMPOSE_BACKUP_SOURCE=.
-COMPOSE_RESTORE_MODE=rw
 ```
 
-`BACKUP_INTERVAL_SECONDS=3600` запускает бэкапы ровно на границе часа: 12:00, 13:00 и т.д. Значение по умолчанию для локального хранения - 100 последних ZIP-архивов.
+Если бэкапы нужно отправлять в отдельный чат или topic/thread, добавьте только нужные переменные:
+
+```env
+BACKUP_CHAT_ID=-1001234567890
+BACKUP_THREAD_ID=123
+```
+
+Остальные backup-переменные обычно не нужны в `.env`: `BACKUP_INTERVAL_SECONDS=3600` запускает бэкапы ровно на границе часа 12:00, 13:00 и т.д.; `BACKUP_LOCAL_RETENTION=100` хранит 100 последних ZIP-архивов; `BACKUP_COMPOSE_ENABLED=True`, `COMPOSE_BACKUP_SOURCE=.` и `COMPOSE_RESTORE_MODE=rw` уже совпадают со стандартным compose-сценарием.
 
 `BACKUP_CHAT_ID` задает чат Telegram для отправки архивов. Если он пустой, используется `LOG_CHAT_ID`. Для topic/thread можно указать `BACKUP_THREAD_ID`; если он пустой, используется `LOG_THREAD_ID`.
 
-Каждый архив подписывается HMAC-подписью в `manifest.json` и содержит SHA-256 каждого файла. По умолчанию restore принимает только архивы с валидной подписью этого инстанса. Если нужен отдельный стабильный ключ подписи, задайте `BACKUP_ARCHIVE_SIGNATURE_SECRET`; если ключ пустой, используется `BOT_TOKEN`.
+Каждый архив содержит `manifest.json` с SHA-256 и размером каждого файла. Это позволяет проверить, что архив не поврежден и его содержимое не отличается от manifest.
+
+Архив не привязан к текущему инстансу, `BOT_TOKEN` или серверу. Его можно загрузить и восстановить на другом сервере, если формат архива поддерживается и проверки целостности проходят.
 
 ## Mount compose-папки
 
@@ -91,7 +94,6 @@ Backend валидирует архив до восстановления:
 
 - файл должен быть валидным ZIP;
 - `manifest.json` должен принадлежать `remnawave-minishop` и иметь поддерживаемую версию формата;
-- HMAC-подпись manifest должна быть валидной, если `BACKUP_ARCHIVE_SIGNATURE_REQUIRED=True`;
 - SHA-256 и размер каждого файла должны совпадать с manifest;
 - выбранный server-side файл должен лежать внутри `BACKUP_DIR`, путь вида `../backup.zip` отклоняется;
 - пути внутри ZIP не могут быть абсолютными, содержать `..`, `\`, пустые сегменты или дубли;
@@ -101,7 +103,18 @@ Backend валидирует архив до восстановления:
 - compose restore стартует только если целевая папка существует и доступна на запись;
 - backup/restore защищены одним Redis lock, чтобы две операции не выполнялись одновременно.
 
-Это защищает от случайной загрузки мусорного файла, zip-slip-архивов, поврежденных ZIP и структурно похожих архивов, которые не были созданы этим инстансом. Если вы сознательно восстанавливаете старый неподписанный архив, временно выставьте `BACKUP_ARCHIVE_SIGNATURE_REQUIRED=False`, восстановите архив и верните проверку обратно.
+Это защищает от случайной загрузки мусорного файла, zip-slip-архивов и поврежденных ZIP. Проверка специально не привязана к секретам инстанса, чтобы архивы можно было использовать для переноса между серверами. Это не проверка доверенного источника: не восстанавливайте архивы, происхождение которых вы не контролируете.
+
+## Перенос на другой сервер
+
+Для переноса БД между инстансами:
+
+1. Создайте backup на старом сервере или возьмите ZIP из Telegram.
+2. На новом сервере загрузите архив в **Система -> Бэкапы**.
+3. Выберите `БД`; `compose-папку` включайте только если хотите перенести `.env`, `docker-compose.yml` и proxy-конфиги.
+4. Запустите restore и после восстановления выполните миграции/healthcheck.
+
+Если переносите compose-папку, проверьте домены, токены, `WEBHOOK_BASE_URL`, `SUBSCRIPTION_MINI_APP_URL`, bind-порты и volume/mount пути: на новом сервере они могут отличаться.
 
 ## Ручное восстановление БД
 
@@ -134,8 +147,6 @@ docker compose logs -f backend worker
 | `BACKUP_INTERVAL_SECONDS` | Периодичность, по умолчанию `3600`. |
 | `BACKUP_LOCAL_RETENTION` | Сколько последних архивов хранить на сервере. |
 | `BACKUP_DIR` | Каталог ZIP-архивов. |
-| `BACKUP_ARCHIVE_SIGNATURE_REQUIRED` | Требовать валидную HMAC-подпись manifest при upload/restore. |
-| `BACKUP_ARCHIVE_SIGNATURE_SECRET` | Отдельный секрет подписи архивов; если пустой, используется `BOT_TOKEN`. |
 | `BACKUP_COMPOSE_ENABLED` | Добавлять compose snapshot. |
 | `COMPOSE_BACKUP_SOURCE` | Host-путь compose-папки для mount в контейнеры. |
 | `COMPOSE_RESTORE_MODE` | `rw` для восстановления compose из админки, `ro` для запрета записи. |