Migration: application directory as parameter

docs/drafts/timeweb-migration-log.md

@@ -8,6 +8,103 @@
 
 ---
 
+## Шаг 5 — переезд default application_dir на /srv (2026-05-22, выполнено)
+
+`/mnt` по FHS — место для точек монтирования внешних дисков; на
+системном диске Timeweb (фаза 1) это семантически неверно. Поменяли
+дефолт на `/srv/applications` (FHS: «data for services provided by
+this system»), для текущего YC-сервера сделали override в инвентаре.
+
+Изменения:
+
+- `vars/vars.yml` — `application_dir: "/srv/applications"`
+  (комментарий обновлён).
+- `production.yml` — у хоста `server` добавлен override
+  `application_dir: "/mnt/applications"`.
+- `playbook-system.yml` — добавлен `vars/vars.yml` в `vars_files`,
+  захардкоженный `/mnt/applications` в задачах
+  `Create directory for mount` и `Mount external storages` заменён
+  на `{{ application_dir }}`.
+- `playbook-remove-user-and-app.yml` — то же самое (`vars/vars.yml`
+  в `vars_files` + `{{ (application_dir, user_name) | path_join }}`).
+- `tasks.py` — новый helper `_application_dir()` читает значение
+  сначала из inventory (override), затем из `vars/vars.yml`. `login_as_app`
+  больше не содержит `/mnt/applications`.
+
+Что остаётся хардкодом — только `/mnt/applications` в `production.yml`
+как override, и это правильно.
+
+На Timeweb-инвентаре (когда появится) можно либо не задавать
+`application_dir` вовсе (применится дефолт `/srv/applications`), либо
+задать явно — для читаемости.
+
+Проверить прогоном `inv pl -- system` на текущем сервере (Yandex
+Cloud) — ничего не должно поменяться, потому что inventory override
+возвращает `/mnt/applications` и mount всё ещё включён. Diff ожидается
+пустой.
+
+### Восстановление restic-снапшотов после смены путей
+
+Старые снапшоты записаны с путями `/mnt/applications/<app>`. На
+Timeweb данные должны лежать в `/srv/applications/<app>`. У restic
+нет встроенного «remap path» при restore, поэтому делается в два
+шага: восстановить во временный каталог, затем `rsync` на новое
+место с сохранением uid/gid (приложения уже созданы playbook'ом с
+теми же uid/gid, см. шаг про подготовку target).
+
+Пример — восстановить gitea на Timeweb-машине:
+
+```bash
+sudo /usr/local/sbin/restic-shell.sh
+
+# Распакуем нужную поддиректорию во временный каталог
+restic restore latest \
+    --target /tmp/restic-restore \
+    --include /mnt/applications/gitea
+
+# Перенесём данные на новый путь, сохранив владельца/группу/ACL/xattr
+sudo rsync -aAX --info=progress2 \
+    /tmp/restic-restore/mnt/applications/gitea/ \
+    /srv/applications/gitea/
+
+sudo rm -rf /tmp/restic-restore
+```
+
+Несколько приложений за один проход:
+
+```bash
+restic restore latest \
+    --target /tmp/restic-restore \
+    --include /mnt/applications/gitea \
+    --include /mnt/applications/outline \
+    --include /mnt/applications/miniflux
+
+for app in gitea outline miniflux; do
+  sudo rsync -aAX --info=progress2 \
+      "/tmp/restic-restore/mnt/applications/$app/" \
+      "/srv/applications/$app/"
+done
+sudo rm -rf /tmp/restic-restore
+```
+
+Альтернатива через `restic mount` (если не хочется промежуточной
+копии — данные мапятся как FUSE-FS):
+
+```bash
+sudo mkdir -p /mnt/restic-snapshots
+restic mount /mnt/restic-snapshots &
+sudo rsync -aAX \
+    /mnt/restic-snapshots/snapshots/latest/mnt/applications/gitea/ \
+    /srv/applications/gitea/
+sudo fusermount -u /mnt/restic-snapshots
+```
+
+После переезда новые снапшоты будут записываться уже с путями
+`/srv/applications/<app>` — никаких трюков для текущих бэкапов не
+нужно.
+
+---
+
 ## Шаг 4 — условное монтирование внешнего диска (2026-05-22, выполнено)
 
 Задача `Mount external storages` в `playbook-system.yml` теперь