Что-то для бэкапа уже настроено, нужно просмотреть. Нужно настроить грамотный бэкап БД и хранимых файлов, с возможностью обратной загрузки и с хронологией хранимых данных. Также нужны скрипты для быстрого копирования данный на устройство, с которого через ssh я подключен к паю. В общем, нужна качественно настроенная система создания, хранения и систематизации бэкапов, лёгкая и с простым управлением через заранее написанные скрипты. Ну ли можно попробовать развернуть что-то готовое третьим контейнером, и настроить для нашего приложения.
Что-то для бэкапа уже настроено, нужно просмотреть. Нужно настроить грамотный бэкап БД и хранимых файлов, с возможностью обратной загрузки и с хронологией хранимых данных. Также нужны скрипты для быстрого копирования данный на устройство, с которого через ssh я подключен к паю. В общем, нужна качественно настроенная система создания, хранения и систематизации бэкапов, лёгкая и с простым управлением через заранее написанные скрипты. Ну ли можно попробовать развернуть что-то готовое третьим контейнером, и настроить для нашего приложения.
NotBigGhost
added this to the 1.4 — Настройка бэкапа на VPS milestone 2026-09-13 18:55:48 +03:00
Отдельный контейнер backup на restic в docker-compose.yml.
Образ собирается из deploy/backup/ на restic/restic:0.19.1 и публикуется через build-push.
Контейнер работает от uid 10001, как app.
Секреты приложения в контейнер не передаются.
На Pi по-прежнему нужны только docker-compose.yml и .env; SSH-ключ лежит в .env в base64.
Снимки по расписанию.
Две копии: локальная на Pi (том backup-repo) и на VPS (SFTP).
Копия БД снимается консистентно (VACUUM INTO) и проверяется integrity_check.
Дедупликация и шифрование.
Сжатие — только средствами restic: формат репозитория v2, уровень задаёт BACKUP_COMPRESSION.
Хранение: 14 дней, 8 недель, 12 месяцев.
В теги снимка пишутся число игроков и партий.
Раз в неделю — проверка данных.
Команда fs-backup:run, list (хронология), status, verify, restore, export (несжатый .tar), import (понимает и старые fs_*.tar.gz).
Восстановление через промежуточную директорию.
Не выполняется, пока работает app.
Снимок разворачивается в .restore-new внутри каждого тома и проверяется.
Перед заменой создаётся страховочный снимок pre-restore.
Замена — через rename; при сбое текущие данные остаются нетронутыми или возвращаются на место.
Это заодно исправляет баг старого restore.sh: docker cp делал файлы root-овыми, и БД становилась доступна только для чтения.
Скрипты для ПКscripts/fs-backup.ps1 и scripts/fs-backup.sh.
pull: снимок с Pi копируется в backups\ со сверкой sha256.
list, status, now: те же команды на Pi через ssh.
restore-test: учебное восстановление на тест-клоне.
Подробная пошаговая инструкцияdeploy/backup/README.md по всем ручным шагам: пароль, ключ, VPS (пользователь только для SFTP), сборка образов, Pi, ПК, учебное восстановление, восстановление прода, гибель Pi, неполадки, чек-лист.
Compat/Breaking. Удаляются scripts/backup.sh и scripts/restore.sh, меняется набор BACKUP_* в .env. Миграция прода: VPS → .env и compose на Pi → up -d. API и фронтенд не меняются.
Критерии готовности
Снимки по расписанию попадают в оба репозитория, зашифрованы, дедуплицированы и чистятся по дням, неделям и месяцам.
Сжатие делает только restic.
list показывает хронологию: время, размер, содержимое.
Восстановление и импорт идут через промежуточную директорию и возвращают рабочие данные с правильным владельцем. Проверено, что при сбое проверки текущие данные не меняются, что восстановление поверх работающего app запрещено и что создаётся pre-restore.
С ПК снимок выгружается одной командой со сверкой sha256.
Инструкция написана и прогнана на локальном стенде: эмуляция VPS в контейнере, тест-клон.
Все проверки (сборка amd64 и arm64, shellcheck, compose config, сценарии бэкапа и восстановления) зелёные.
Ветка:issue-64-backup от dev
## План выполнения
1. **Отдельный контейнер `backup` на restic** в `docker-compose.yml`.
- Образ собирается из `deploy/backup/` на `restic/restic:0.19.1` и публикуется через `build-push`.
- Контейнер работает от uid 10001, как `app`.
- Секреты приложения в контейнер не передаются.
- На Pi по-прежнему нужны только `docker-compose.yml` и `.env`; SSH-ключ лежит в `.env` в base64.
2. **Снимки по расписанию.**
- Две копии: локальная на Pi (том `backup-repo`) и на VPS (SFTP).
- Копия БД снимается консистентно (`VACUUM INTO`) и проверяется `integrity_check`.
- Дедупликация и шифрование.
- Сжатие — только средствами restic: формат репозитория v2, уровень задаёт `BACKUP_COMPRESSION`.
- Хранение: 14 дней, 8 недель, 12 месяцев.
- В теги снимка пишутся число игроков и партий.
- Раз в неделю — проверка данных.
3. **Команда `fs-backup`:** `run`, `list` (хронология), `status`, `verify`, `restore`, `export` (несжатый `.tar`), `import` (понимает и старые `fs_*.tar.gz`).
4. **Восстановление через промежуточную директорию.**
- Не выполняется, пока работает `app`.
- Снимок разворачивается в `.restore-new` внутри каждого тома и проверяется.
- Перед заменой создаётся страховочный снимок `pre-restore`.
- Замена — через `rename`; при сбое текущие данные остаются нетронутыми или возвращаются на место.
- Это заодно исправляет баг старого `restore.sh`: `docker cp` делал файлы root-овыми, и БД становилась доступна только для чтения.
5. **Скрипты для ПК** `scripts/fs-backup.ps1` и `scripts/fs-backup.sh`.
- `pull`: снимок с Pi копируется в `backups\` со сверкой sha256.
- `list`, `status`, `now`: те же команды на Pi через ssh.
- `restore-test`: учебное восстановление на тест-клоне.
6. **Подробная пошаговая инструкция** `deploy/backup/README.md` по всем ручным шагам: пароль, ключ, VPS (пользователь только для SFTP), сборка образов, Pi, ПК, учебное восстановление, восстановление прода, гибель Pi, неполадки, чек-лист.
7. **Compat/Breaking.** Удаляются `scripts/backup.sh` и `scripts/restore.sh`, меняется набор `BACKUP_*` в `.env`. Миграция прода: VPS → `.env` и compose на Pi → `up -d`. API и фронтенд не меняются.
**Критерии готовности**
- Снимки по расписанию попадают в оба репозитория, зашифрованы, дедуплицированы и чистятся по дням, неделям и месяцам.
- Сжатие делает только restic.
- `list` показывает хронологию: время, размер, содержимое.
- Восстановление и импорт идут через промежуточную директорию и возвращают рабочие данные с правильным владельцем. Проверено, что при сбое проверки текущие данные не меняются, что восстановление поверх работающего `app` запрещено и что создаётся `pre-restore`.
- С ПК снимок выгружается одной командой со сверкой sha256.
- Инструкция написана и прогнана на локальном стенде: эмуляция VPS в контейнере, тест-клон.
- Все проверки (сборка amd64 и arm64, shellcheck, compose config, сценарии бэкапа и восстановления) зелёные.
**Ветка:** `issue-64-backup` от `dev`
Итог: бэкапы делает контейнер backup на restic. Каждую ночь он сохраняет зашифрованный снимок с дедупликацией в две копии — на Pi и на VPS (SFTP). Сжатие — средствами restic. Хронология показывает, сколько игроков и партий было в каждом снимке. Хранение: дни, недели, месяцы.
Восстановление идёт через промежуточную директорию: проверка развёрнутых данных, страховочный снимок pre-restore, откат при сбое и команда recover после обрыва питания.
С ПК снимок скачивается одной командой .\scripts\fs-backup.ps1 pull со сверкой sha256. Учебное восстановление на тест-клоне — restore-test.
В Debian/Ubuntu системный пользователь backup уже есть, поэтому на VPS используется fsbackup.
Старый restore.sh делал БД root-овой — после восстановления она была доступна только для чтения.
Добавлена защита: новый пустой Pi не перезапишет историю на VPS.
Проверки:
shellcheck, разбор .ps1, compose config — чисто.
Сборка образа под amd64 и arm64.
pytest — 147 passed.
На локальном стенде (эмуляция VPS и Pi) пройдены сценарии:
бэкап и очистка;
restore и import, в том числе настоящего старого архива;
сбои и обрезанные архивы — данные не меняются;
recover;
«Pi умер»;
скрипты ПК по ssh/scp.
Команды разделов VPS и Pi из README выполнены буквально.
Не проверено: реальные Pi и VPS.
Статус:Status/In Review Осталось за вами:
ревью и мёрж PR — задача закроется автоматически;
после мёржа — ручная настройка по deploy/backup/README.md. На Pi не забудьте удалить старые строки BACKUP_* из .env.
Работа выполнена, открыт PR: https://gitea.arseniev.info/NotBigGhost/ForbiddenStarsApp/pulls/66
**Итог:** бэкапы делает контейнер `backup` на restic. Каждую ночь он сохраняет зашифрованный снимок с дедупликацией в две копии — на Pi и на VPS (SFTP). Сжатие — средствами restic. Хронология показывает, сколько игроков и партий было в каждом снимке. Хранение: дни, недели, месяцы.
Восстановление идёт через промежуточную директорию: проверка развёрнутых данных, страховочный снимок `pre-restore`, откат при сбое и команда `recover` после обрыва питания.
С ПК снимок скачивается одной командой `.\scripts\fs-backup.ps1 pull` со сверкой sha256. Учебное восстановление на тест-клоне — `restore-test`.
Подробная пошаговая инструкция по всему, что нужно сделать руками: [`deploy/backup/README.md`](https://gitea.arseniev.info/NotBigGhost/ForbiddenStarsApp/src/branch/issue-64-backup/deploy/backup/README.md).
**По ходу найдено и учтено:**
- В Debian/Ubuntu системный пользователь `backup` уже есть, поэтому на VPS используется `fsbackup`.
- Старый `restore.sh` делал БД root-овой — после восстановления она была доступна только для чтения.
- Добавлена защита: новый пустой Pi не перезапишет историю на VPS.
**Проверки:**
- `shellcheck`, разбор `.ps1`, `compose config` — чисто.
- Сборка образа под amd64 и arm64.
- `pytest` — 147 passed.
- На локальном стенде (эмуляция VPS и Pi) пройдены сценарии:
- бэкап и очистка;
- `restore` и `import`, в том числе настоящего старого архива;
- сбои и обрезанные архивы — данные не меняются;
- `recover`;
- «Pi умер»;
- скрипты ПК по ssh/scp.
- Команды разделов VPS и Pi из README выполнены буквально.
- Не проверено: реальные Pi и VPS.
**Статус:** `Status/In Review`
**Осталось за вами:**
- ревью и мёрж PR — задача закроется автоматически;
- после мёржа — ручная настройка по `deploy/backup/README.md`. На Pi не забудьте удалить старые строки `BACKUP_*` из `.env`.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Что-то для бэкапа уже настроено, нужно просмотреть. Нужно настроить грамотный бэкап БД и хранимых файлов, с возможностью обратной загрузки и с хронологией хранимых данных. Также нужны скрипты для быстрого копирования данный на устройство, с которого через ssh я подключен к паю. В общем, нужна качественно настроенная система создания, хранения и систематизации бэкапов, лёгкая и с простым управлением через заранее написанные скрипты. Ну ли можно попробовать развернуть что-то готовое третьим контейнером, и настроить для нашего приложения.
План выполнения
backupна restic вdocker-compose.yml.deploy/backup/наrestic/restic:0.19.1и публикуется черезbuild-push.app.docker-compose.ymlи.env; SSH-ключ лежит в.envв base64.backup-repo) и на VPS (SFTP).VACUUM INTO) и проверяетсяintegrity_check.BACKUP_COMPRESSION.fs-backup:run,list(хронология),status,verify,restore,export(несжатый.tar),import(понимает и старыеfs_*.tar.gz).app..restore-newвнутри каждого тома и проверяется.pre-restore.rename; при сбое текущие данные остаются нетронутыми или возвращаются на место.restore.sh:docker cpделал файлы root-овыми, и БД становилась доступна только для чтения.scripts/fs-backup.ps1иscripts/fs-backup.sh.pull: снимок с Pi копируется вbackups\со сверкой sha256.list,status,now: те же команды на Pi через ssh.restore-test: учебное восстановление на тест-клоне.deploy/backup/README.mdпо всем ручным шагам: пароль, ключ, VPS (пользователь только для SFTP), сборка образов, Pi, ПК, учебное восстановление, восстановление прода, гибель Pi, неполадки, чек-лист.scripts/backup.shиscripts/restore.sh, меняется наборBACKUP_*в.env. Миграция прода: VPS →.envи compose на Pi →up -d. API и фронтенд не меняются.Критерии готовности
listпоказывает хронологию: время, размер, содержимое.appзапрещено и что создаётсяpre-restore.Ветка:
issue-64-backupотdevРабота выполнена, открыт PR: #66
Итог: бэкапы делает контейнер
backupна restic. Каждую ночь он сохраняет зашифрованный снимок с дедупликацией в две копии — на Pi и на VPS (SFTP). Сжатие — средствами restic. Хронология показывает, сколько игроков и партий было в каждом снимке. Хранение: дни, недели, месяцы.Восстановление идёт через промежуточную директорию: проверка развёрнутых данных, страховочный снимок
pre-restore, откат при сбое и командаrecoverпосле обрыва питания.С ПК снимок скачивается одной командой
.\scripts\fs-backup.ps1 pullсо сверкой sha256. Учебное восстановление на тест-клоне —restore-test.Подробная пошаговая инструкция по всему, что нужно сделать руками:
deploy/backup/README.md.По ходу найдено и учтено:
backupуже есть, поэтому на VPS используетсяfsbackup.restore.shделал БД root-овой — после восстановления она была доступна только для чтения.Проверки:
shellcheck, разбор.ps1,compose config— чисто.pytest— 147 passed.restoreиimport, в том числе настоящего старого архива;recover;Статус:
Status/In ReviewОсталось за вами:
deploy/backup/README.md. На Pi не забудьте удалить старые строкиBACKUP_*из.env.