Как перенести ИИ-агента Hermes на новый сервер и ничего не потерять

В какой-то момент мой ИИ-агент Hermes перестал быть просто установленной программой.

Внутри него уже жили память, Telegram, расписания, базы данных, роли ИИ-сотрудников, OpenClaw, Obsidian и Syncthing. Поэтому задача «переехать на другой сервер» быстро превратилась в вопрос: как перенести цифрового сотрудника вместе со всей его жизнью и не получить после запуска пустого двойника?

Я прошёл этот перенос вручную. Старый сервер находился в России и использовал дополнительную прокси-прослойку для Telegram и внешних API. Новый сервер находился в Нидерландах, поэтому мог обращаться к сервисам напрямую.

На первый взгляд всё выглядело просто: скопировать домашнюю папку, запустить Hermes и поменять DNS. На практике это опасный сценарий. Можно потерять последние сообщения, повредить SQLite-базу, одновременно запустить двух агентов с одним Telegram-токеном или заставить Syncthing считать новый сервер совершенно новым устройством.

Ниже мой рабочий порядок переноса. Это не универсальный установщик, а подробный чек-лист для Linux-сервера с systemd, SSH и rsync. Названия сервисов и пути у вас могут отличаться, поэтому сначала найдите свои, а уже потом выполняйте команды.

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

Что на самом деле нужно переносить

У Hermes есть не только исполняемый файл. В моём случае перенос состоял из нескольких слоёв:

• ~/.hermes — конфигурация, память, состояния, базы SQLite и рабочие данные Hermes;
• ~/.local — пользовательские программы, Python-окружения, Syncthing и часть runtime;
• ~/.openclaw — конфигурация и данные OpenClaw, если он работает рядом с Hermes;
• ~/.codex и ~/.secrets — связанные инструменты и безопасное хранилище, если они используются;
• Obsidian Vault — база знаний агента;
• дополнительные папки Syncthing — например, фото с телефона;
• shell-профили, SSH-ключи и пользовательские systemd-юниты;
• системные systemd-юниты, reverse proxy, DNS и TLS.

Сам Obsidian в моей системе весил всего около 65 МБ. Когда общий перенос показал больше 12 ГБ, причиной оказался не vault: примерно по 5 ГБ занимали .hermes и .local, ещё около 2 ГБ — .openclaw. Отдельная папка с фотографиями iPhone добавила ещё около 6 ГБ.

Это важный урок: сначала измеряйте папки отдельно. Иначе можно долго ждать копирования «маленькой базы заметок», хотя на самом деле вы переносите окружения Python, кэши, модели, базы и медиа.

Схема безопасного переезда

Весь перенос можно свести к пяти фазам:

1. Инвентаризация старого сервера.
2. Подготовка нового сервера и предварительная копия данных.
3. Короткая остановка старого Hermes.
4. Финальная синхронизация изменившихся файлов и запуск нового экземпляра.
5. Переключение DNS только после внутренних проверок.

Главная идея — копировать данные два раза. Первый большой проход выполняется заранее, пока старый агент ещё работает. Второй проход делается после его остановки и переносит только последние изменения. Так простой сокращается с часов до нескольких минут.

Шаг 1. Зафиксируйте исходное состояние

Перед первой командой создайте небольшой паспорт миграции:

• IP или hostname старого и нового сервера;
• имя пользователя, от которого работает Hermes;
• UID и GID пользователя;
• версия Ubuntu или другого Linux;
• версия Hermes, Python, Node.js и OpenClaw;
• пути к данным;
• названия systemd-сервисов;
• локальные порты dashboard и gateway;
• список доменов;
• текущий TTL DNS;
• папки и Device ID Syncthing;
• настройки прокси, которые нужны на старом сервере, но не нужны на новом.

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

В примерах ниже используются переменные. Задайте свои значения в текущей shell-сессии. Тестовый IP из документации нельзя оставлять в реальной команде:

AGENT_USER="agent"
AGENT_UID_NUMBER="1000"
AGENT_GID_NUMBER="1000"
NEW_SERVER_IP="203.0.113.20"
HERMES_PORT="9119"
OPENCLAW_PORT="18789"

Базовая диагностика:

hostname
uname -a
df -h
free -h
id $AGENT_USER

du -sh \
  /home/$AGENT_USER/.hermes \
  /home/$AGENT_USER/.local \
  /home/$AGENT_USER/.openclaw \
  /home/$AGENT_USER/obsidian-vault \
  /home/$AGENT_USER/iphone-photos 2>/dev/null

systemctl list-unit-files | grep -Ei 'hermes|openclaw|syncthing'
systemctl list-timers --all
crontab -u $AGENT_USER -l
ss -lntp
timedatectl
ufw status 2>/dev/null

Для пользовательских сервисов:

AGENT_UID=$(id -u $AGENT_USER)
runuser -u $AGENT_USER -- env XDG_RUNTIME_DIR=/run/user/$AGENT_UID \
  systemctl --user list-unit-files | grep -Ei 'openclaw|syncthing'

runuser -u $AGENT_USER -- env XDG_RUNTIME_DIR=/run/user/$AGENT_UID \
  systemctl --user list-timers --all

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

Шаг 2. Проверьте новый сервер до копирования

На новом сервере должно быть достаточно диска и памяти. Оставьте запас минимум 20-30 процентов, потому что базы, журналы, временные файлы и обновления продолжат расти.

Если старый Hermes использовал VPN или SOCKS-прокси, сначала проверьте, нужен ли он в новой локации:

curl -I --max-time 10 https://api.telegram.org/
curl -I --max-time 10 https://api.openai.com/v1/models

Для Telegram ответ 302 от базового URL означает, что сеть доступна. Для OpenAI ответ 401 без ключа также полезен: соединение дошло до API, просто запрос не авторизован.

На этом этапе создайте пользователя с тем же UID и GID, что на старой машине. Это уменьшает количество проблем с владельцами файлов после rsync:

groupadd --gid $AGENT_GID_NUMBER $AGENT_USER
useradd --uid $AGENT_UID_NUMBER --gid $AGENT_GID_NUMBER --create-home --shell /bin/bash $AGENT_USER

Если пользователь уже существует, сначала сравните id $AGENT_USER на двух серверах. Не меняйте UID вслепую на сервере, где уже есть данные других пользователей.

Подготовьте SSH-доступ между серверами и установите системные зависимости, но пока не запускайте Hermes, OpenClaw и Syncthing на новой машине. Проверьте firewall: обычно нужны 80/443 для reverse proxy и 22000 для прямых соединений Syncthing, если вы их используете. GUI Syncthing на 8384 безопаснее оставить на loopback и открывать через SSH-туннель.

Не копируйте целиком чужие authorized_keys и root-конфигурацию. Переносите только те ключи и правила доступа, которые действительно нужны новому серверу.

Шаг 3. Сделайте предварительную копию

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

rsync -aHAX --numeric-ids --info=progress2 \
  /home/$AGENT_USER/.hermes/ \
  root@$NEW_SERVER_IP:/home/$AGENT_USER/.hermes/

rsync -aHAX --numeric-ids --info=progress2 \
  /home/$AGENT_USER/.local/ \
  root@$NEW_SERVER_IP:/home/$AGENT_USER/.local/

rsync -aHAX --numeric-ids --info=progress2 \
  /home/$AGENT_USER/.openclaw/ \
  root@$NEW_SERVER_IP:/home/$AGENT_USER/.openclaw/

rsync -aHAX --numeric-ids --info=progress2 \
  /home/$AGENT_USER/obsidian-vault/ \
  root@$NEW_SERVER_IP:/home/$AGENT_USER/obsidian-vault/

Дополнительные папки Syncthing копируйте тем же способом.

Файлы с токенами и API-ключами передавайте только по защищённому SSH-каналу. Не складывайте .env и .secrets во временный публичный архив, не выводите их содержимое в терминал и не вставляйте значения в историю команд.

Ключ --numeric-ids сохраняет числовых владельцев. -HAX нужен, если вы хотите перенести hard links, ACL и extended attributes. Не добавляйте --delete, пока не понимаете, какие файлы он удалит на принимающей стороне.

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

Шаг 4. Подготовьте сервисы, но не запускайте их

Перенесите или создайте systemd-юниты на новом сервере. В моей схеме отдельно работали:

• Hermes dashboard;
• Hermes gateway;
• OpenClaw gateway;
• Syncthing;
• reverse proxy или socket-proxy для доступа к локальным портам.

Отдельно перенесите cron-задания и пользовательские systemd timers, если они не хранятся внутри самого Hermes. Сравните расписания на двух серверах, но не включайте их на новом, пока старый контур ещё работает.

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

systemctl daemon-reload
loginctl enable-linger $AGENT_USER

Для пользовательских сервисов:

AGENT_UID=$(id -u $AGENT_USER)
runuser -u $AGENT_USER -- env XDG_RUNTIME_DIR=/run/user/$AGENT_UID \
  systemctl --user daemon-reload

До финальной синхронизации сервисы на новом сервере должны оставаться inactive. Особенно это касается Telegram и Syncthing. Два одновременно работающих экземпляра с одинаковыми токенами и Device ID могут конфликтовать.

Шаг 5. Уберите старую сетевую обвязку

Старый сервер может содержать настройки, которые на новом только мешают:

• ALL_PROXY;
• HTTP_PROXY и HTTPS_PROXY;
• TELEGRAM_PROXY;
• отдельный SOCKS-сервис;
• proxy-параметр внутри конфигурации OpenClaw;
• зависимости systemd вида Requires=old-proxy.service.

Сначала найдите файлы, где они встречаются, не печатая содержимое секретных env-файлов:

grep -RIlE 'ALL_PROXY|HTTPS_PROXY|HTTP_PROXY|TELEGRAM_PROXY|127\.0\.0\.1:1080' \
  /home/$AGENT_USER/.hermes \
  /home/$AGENT_USER/.openclaw \
  /etc/systemd/system 2>/dev/null

Сделайте резервные копии конфигов и удалите только ненужные proxy-поля на новом сервере. Не редактируйте исходную копию на старом: она нужна для отката.

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

Шаг 6. Сохраните личность Syncthing

Если просто установить Syncthing заново, сервер получит новый Device ID. Тогда MacBook и телефон придётся подключать повторно.

Чтобы сохранить старую идентичность, переносите вместе:

• config.xml;
• cert.pem;
• key.pem;
• каталог состояния Syncthing, если он находится рядом.

В зависимости от версии путь может быть одним из этих:

/home/$AGENT_USER/.local/state/syncthing/
/home/$AGENT_USER/.config/syncthing/

Никогда не запускайте старый и новый Syncthing одновременно с одной парой cert.pem и key.pem. Для других устройств это будет один и тот же сервер, появившийся сразу в двух местах.

После переноса можно поменять только отображаемое имя устройства в config.xml, например со server-old на server-new. Device ID при этом останется прежним.

Шаг 7. Остановите старый контур

Это точка, после которой начинается короткое окно простоя.

Остановите Hermes dashboard, gateway, OpenClaw и Syncthing на старом сервере:

systemctl stop hermes-dashboard-$AGENT_USER.service
systemctl stop hermes-gateway-$AGENT_USER.service

AGENT_UID=$(id -u $AGENT_USER)
runuser -u $AGENT_USER -- env XDG_RUNTIME_DIR=/run/user/$AGENT_UID \
  systemctl --user stop openclaw-gateway.service syncthing.service

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

pgrep -au $AGENT_USER -f 'hermes|openclaw|syncthing'

Если процесс не остановился за обычный таймаут, изучите журнал и только потом завершайте его принудительно. В моём случае dashboard пришлось остановить жёстко, поэтому особенно важно было перенести SQLite-файлы вместе с WAL и проверить базы перед запуском.

Шаг 8. Выполните финальный rsync

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

Не забудьте:

• базы *.db;
• файлы *.db-wal и *.db-shm, если они остались после остановки;
• последние изменения Obsidian;
• состояние OpenClaw;
• конфигурацию и состояние Syncthing;
• дополнительные синхронизируемые папки.

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

1. исключить destination-specific конфиг из финального rsync;
2. скопировать всё, а затем ещё раз применить и проверить настройки нового сервера до запуска.

Я использовал второй подход с обязательной повторной проверкой.

После копирования восстановите владельца:

chown -R $AGENT_USER:$AGENT_USER \
  /home/$AGENT_USER/.hermes \
  /home/$AGENT_USER/.local \
  /home/$AGENT_USER/.openclaw \
  /home/$AGENT_USER/obsidian-vault

Не применяйте рекурсивный chown к неизвестным системным путям. Ограничивайте команду конкретными каталогами пользователя.

Шаг 9. Проверьте базы Hermes до запуска

Для SQLite можно выполнить quick_check в режиме чтения:

runuser -u $AGENT_USER -- env HERMES_DB_ROOT=/home/$AGENT_USER/.hermes python3 - <<'PY'
import os
import sqlite3
from pathlib import Path

root = Path(os.environ['HERMES_DB_ROOT'])
for name in ('state.db', 'kanban.db', 'projects.db', 'verification_evidence.db'):
    path = root / name
    if not path.exists():
        continue
    connection = sqlite3.connect(f'file:{path}?mode=ro', uri=True, timeout=30)
    try:
        result = connection.execute('PRAGMA quick_check').fetchone()[0]
        print(f'{name}: {result}')
    finally:
        connection.close()
PY

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

Шаг 10. Запустите новый контур

Сначала системные сервисы:

systemctl enable --now hermes-dashboard-$AGENT_USER.service
systemctl enable --now hermes-gateway-$AGENT_USER.service

Затем пользовательские:

AGENT_UID=$(id -u $AGENT_USER)
runuser -u $AGENT_USER -- env XDG_RUNTIME_DIR=/run/user/$AGENT_UID \
  systemctl --user enable --now openclaw-gateway.service syncthing.service

Проверьте не только слово active, но и реальные признаки жизни:

systemctl --no-pager --full status hermes-gateway-$AGENT_USER.service
journalctl -u hermes-gateway-$AGENT_USER.service --since '-10 min' --no-pager

curl -I http://127.0.0.1:$HERMES_PORT/
curl -I http://127.0.0.1:$OPENCLAW_PORT/
ss -lntp

Убедитесь, что:

• Hermes видит старую память и проекты;
• Telegram-провайдер запустился;
• OpenClaw отвечает локально;
• в журналах нет попыток подключиться к старому прокси;
• процессы выходят в интернет напрямую, если это было целью переезда.

Шаг 11. Проверьте Syncthing

GUI Syncthing безопаснее открывать через SSH-туннель:

ssh -L 8384:127.0.0.1:8384 $AGENT_USER@$NEW_SERVER_IP

После этого откройте http://127.0.0.1:8384 на своём компьютере.

Проверьте каждую папку:

• состояние Up to Date или idle;
• Need Items = 0;
• Need Bytes = 0;
• Errors = 0;
• подключение ожидаемых устройств;
• отсутствие конфликтов регистра имён и permission denied.

У меня после переноса остались две старые ошибки. Они оказались временными файлами .syncthing.*.tmp внутри каталогов без права записи. После точечного исправления прав и повторного сканирования обе папки показали нули. Это хороший пример того, почему зелёный systemd-статус ещё не означает завершённую синхронизацию.

Шаг 12. Настройте reverse proxy и HTTPS

Hermes и OpenClaw безопаснее оставлять на 127.0.0.1, а наружу публиковать только через reverse proxy с HTTPS и дополнительной авторизацией.

Если Nginx Proxy Manager работает в Docker, 127.0.0.1 внутри контейнера указывает на сам контейнер, а не на хост. Используйте адрес host gateway, отдельную Docker-сеть или локальный socket-proxy до loopback-порта приложения.

Перед переключением DNS проверьте новый прокси принудительно через нужный IP:

curl -I --resolve hermes.example.com:80:$NEW_SERVER_IP \
  http://hermes.example.com/

curl -I --resolve hermes.example.com:443:$NEW_SERVER_IP \
  https://hermes.example.com/

Если включена Basic Auth, ответ 401 без логина является ожидаемым и полезным: DNS ещё не переключён, но HTTPS и защита уже отвечают на новом сервере.

Шаг 13. Переключите DNS последним

Только когда локальные сервисы, Syncthing и reverse proxy проверены, поменяйте A-записи доменов на новый IP.

Если возможно, заранее уменьшите TTL до 300-600 секунд. После переключения старый адрес ещё некоторое время может оставаться в кэше провайдера или устройства.

Проверьте распространение записи через несколько резолверов и только после появления нового IP запрашивайте сертификат Let's Encrypt, если он не был подготовлен другим способом.

Финальные внешние признаки:

• HTTP перенаправляет на HTTPS;
• сертификат валиден для нужного домена;
• без Basic Auth сервер отвечает 401, если защита включена;
• после авторизации открывается Hermes или OpenClaw;
• Telegram продолжает принимать сообщения;
• новые данные появляются в Obsidian и Syncthing.

Шаг 14. Отключите автозапуск на старом сервере

После успешного запуска нового контура остановите и отключите старые сервисы:

systemctl disable --now hermes-dashboard-$AGENT_USER.service
systemctl disable --now hermes-gateway-$AGENT_USER.service

AGENT_UID=$(id -u $AGENT_USER)
runuser -u $AGENT_USER -- env XDG_RUNTIME_DIR=/run/user/$AGENT_UID \
  systemctl --user disable --now openclaw-gateway.service syncthing.service

Сначала проверьте зависимости. В моём случае старый SOCKS-туннель использовали и другие Hermes-пользователи, поэтому общий proxy-сервис нельзя было отключать вместе с моим агентом. Я отключил только сервисы своего пользователя.

Данные на старом сервере пока не удаляйте.

План отката, который нужно написать заранее

Хороший перенос начинается не с rsync, а с ответа на вопрос: что делать, если новый сервер не взлетит?

Мой план отката выглядел так:

1. Остановить Hermes, OpenClaw и Syncthing на новом сервере.
2. Вернуть DNS на старый IP.
3. Снова включить сервисы на старом сервере.
4. Если на новом сервере уже появились уникальные данные, сначала аккуратно вернуть их назад.
5. Не запускать одновременно две копии Telegram и Syncthing с одинаковой идентичностью.

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

Полный чек-лист переноса Hermes

До остановки старого сервера

• Записаны IP, пользователи, UID/GID, версии и пути.
• Измерен размер всех каталогов, а не только Obsidian.
• Проверено свободное место на новом сервере.
• Проверен прямой доступ к Telegram и модельным API.
• Сделан snapshot или другая независимая резервная копия старого сервера.
• Создан пользователь с корректным UID/GID.
• Настроен SSH между серверами.
• Проверены firewall, часовой пояс, cron и systemd timers.
• Выполнен предварительный rsync больших каталогов.
• Подготовлены systemd-юниты, но новые сервисы не запущены.
• Подготовлены настройки без старого VPN или прокси.
• Перенесена идентичность Syncthing.
• Записан план отката.

Во время переключения

• Остановлены Hermes dashboard и gateway на старом сервере.
• Остановлены OpenClaw и Syncthing.
• Проверено отсутствие старых процессов.
• Выполнен финальный rsync.
• Не перезаписаны конфиги, специфичные для нового сервера.
• Проверены владельцы файлов.
• Все SQLite-базы вернули quick_check: ok.

После запуска нового сервера

• Все нужные systemd-сервисы имеют статус active.
• Hermes и OpenClaw отвечают на локальных портах.
• Telegram подключён и принимает тестовое сообщение.
• В окружении процессов нет старых proxy-переменных.
• Obsidian и дополнительные папки Syncthing показывают нули ошибок и ожидания.
• Reverse proxy отвечает на новом IP.
• HTTPS и Basic Auth проверены.
• DNS переключён только после внутренних тестов.
• Старые сервисы отключены от автозапуска.
• Старые данные сохранены для отката.
• В течение первых суток проверяются журналы, свободный диск и новые файлы синхронизации.

Что я бы сделал иначе в следующий раз

Я бы заранее подготовил три вещи.

Первая — точную карту данных. Большой объём оказался не Obsidian, а окружениями и состояниями агента. Простая таблица путь - размер - зачем нужен - можно ли пересоздать сделала бы оценку быстрее.

Вторая — отдельный лист проверки сервисов. Не один общий пункт «Hermes работает», а dashboard, gateway, Telegram, OpenClaw, Syncthing, DNS, TLS и базы по отдельности.

Третья — снижение DNS TTL за сутки до переноса. Тогда меньше пользователей попадает на старый IP после переключения.

Но главное решение оказалось правильным: ничего не удалять на старом сервере и разделить копирование на предварительный и финальный проход. Благодаря этому перенос почти 19 ГБ данных не превратился в многочасовой простой, а старый сервер остался безопасной страховкой.

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

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

Если вы строите собственную команду ИИ-сотрудников и хотите видеть реальные удачи, ошибки и техническое закулисье, подписывайтесь на Telegram Ильи Шведкова.