Files
janssen/claude-memory/project_tower_backups.md
2026-06-11 21:49:04 +02:00

30 lines
1.6 KiB
Markdown

---
name: project-tower-backups
description: "Unraid user scripts na Toweru (192.168.1.76) — zálohy MongoDB/PostgreSQL/MySQL, MongoDBBackupWithGzip zálohuje dynamicky všechny DB"
metadata:
node_type: memory
type: project
originSessionId: 5338a9b3-9290-4241-8c98-42b86d832dfc
---
Unraid user scripts jsou na Toweru (192.168.1.76, ssh root) v
`/boot/config/plugins/user.scripts/scripts/<název>/script`.
`MongoDBBackupWithGzip` (denně 4:40) od 2026-06-11 zjišťuje seznam databází
dynamicky přes `mongosh listDatabases` (vynechává `local` a `config`) —
nové DB se zálohují automaticky. Dump přes `docker exec MongoDB mongodump
--archive --gzip` do `/mnt/user/Backup/Critical/MongoDBBackup/tower/<db>/<timestamp>/`.
Rotace GFS bez kopírování (selektivní prune dle data v názvu adresáře):
7 denních / 4 týdenní / 4 měsíční, maže se jen po úspěšném dumpu.
Restore ověřen testem 2026-06-11 (covance → temp DB, 100% shoda docs+indexů).
Sesterské skripty: `MongoDBRestoreFromBackup` (sám projde všechny DB složky),
`MongoDBVerifyIntegrity` (ROZBITÝ — natvrdo seznam DB z jiného serveru);
obdobné trio existuje pro PostgreSQL.
Zbývající díry v disaster recovery (k 2026-06-11): zálohy neopouštějí Tower
(žádný rsync na Synology/cloud) a při selhání zálohy nechodí notifikace.
Pozor na Toweru: `du -h` na FUSE `/mnt/user` hlásí čerstvě zapsaným souborům
falešnou velikost (1.0K) — skutečnou délku dá `ls -l`. mongodump píše průběžné
logy na stderr, takže neprázdný stderr ≠ chyba (rozhoduje exit code).