Files
Vladimir Buzalka 2bdac59676 notebookvb
2026-06-14 12:07:35 +02:00

4.2 KiB
Raw Permalink Blame History

MedicusFirebird — Firebird 2.5 zrcadlo Medicus DB na toweru

Kontejnerizované zrcadlo ostré Medicus databáze (Firebird) na serveru tower (Unraid, 192.168.1.76). Nahrazuje dosavadní restore na Windows VM reporter — tu lze po ověření na Firebird části vypnout.

Proč

Všechny ostatní DB (MySQL, PostgreSQL, MongoDB, Redis) běží na toweru jako Docker. Firebird sem logicky patří taky: jeden host, jeden režim záloh/monitoringu, žádná Windows VM navíc.

Tok dat

Ordinace:  gbak  ->  zip  ->  rsync na tower (~02:15)
Tower:     /mnt/user/OrdinaceSynology/MedicusBackup/MEDICUS_RRMMDD_HHMM.zip   (zalohy se HROMADI)
           restore_medicus.sh (denne):
             1) nejnovejsi MEDICUS_*.zip podle nazvu; pokud == last_restored.txt -> skip
             2) pocka az velikost prestane rust (probiha-li jeste rsync) + overi unzip -t
             3) unzip .fbk  ->  gbak -r do medicus_new.fdb  ->  stop+swap+start kontejneru
             4) zapise marker (last_restored.txt)
             5) GFS retence zaloh (prune_backups.sh)
Kontejner: firebird-medicus  ->  serve  tower:3050  /firebird/data/medicus.fdb

Zdrojová DB: Firebird 2.5.7, ODS 11.2, dialect 3, page size 8192. Image: jacobalberty/firebird:2.5-ss = Firebird 2.5.9 (restore 2.5.7 → 2.5.9 v rámci řady OK).

Soubory

Soubor Popis
firebird_create.sh Jednorázové vytvoření / znovuvytvoření kontejneru
restore_medicus.sh Denní rutina: obnova z nejnovější zálohy + retence (cron)
prune_backups.sh GFS retence záloh (volá se z restore; lze i samostatně)
verify_firebird.sh Kontrola: verze enginu, ODS, počet pacientů
last_restored.txt Marker poslední úspěšně restorované zálohy (vzniká za běhu)
restore.log Log denních běhů

Umístění na toweru

  • Skripty: /mnt/user/Scripts/MedicusFirebird/
  • Data kontejneru: /mnt/user/appdata/firebird-medicus/fb (→ /firebird, soubor data/medicus.fdb)
  • Rozbalovací prostor pro .fbk: /mnt/user/appdata/firebird-medicus/work (→ /work)

Kontejner

docker run -d --name firebird-medicus --restart unless-stopped \
  -p 3050:3050 -e ISC_PASSWORD=masterkey -e TZ=Europe/Prague \
  -v /mnt/user/appdata/firebird-medicus/fb:/firebird \
  -v /mnt/user/appdata/firebird-medicus/work:/work \
  jacobalberty/firebird:2.5-ss

Pozn.: gbak/isql jsou v /usr/local/firebird/bin/ (nejsou v PATH → volat plnou cestou). Hesla jsou v security2.fdb (nastaveno přes ISC_PASSWORD), ne v medicus.fdb — restore dat heslo nemění.

Robustnost restoru

Zálohy se v adresáři hromadí a nejnovější se může právě přenášet přes rsync, proto:

  • výběr nejnovější podle názvu (RRMMDD_HHMM → lexikálně = chronologicky)
  • stav v last_restored.txt → když není nic novějšího, nic se nedělá
  • čeká na dokončení přenosu (velikost se ustálí) a ověří integritu unzip -t — nikdy nezpracuje nekompletní soubor
  • marker se zapíše až po úspěšném restoru; zámek (flock) proti souběhu

Retence záloh (GFS, sekvenční, počítaná)

prune_backups.sh drží v adresáři záloh schéma:

  1. 30 posledních dní — nech všechny denní
  2. pak 8 týdnů — z každého ISO-týdne 1× (nejnovější = konec týdne)
  3. pak 12 měsíců — z každého měsíce 1× (nejnovější)
  4. starší → smazat

Datum se čte z názvu (ne mtime). Neparsovatelné názvy se nikdy nemažou. Bezpečnostní přepínač DRY_RUN=1 (jen výpis) / DRY_RUN=0 (maže). V denní rutině řízeno RETENTION_DRYRUN v restore_medicus.sh (ostré = 0).

Připojení klientů (fdb / DSN)

192.168.1.76:/firebird/data/medicus.fdb     SYSDBA / masterkey, charset win1250
# nebo: tower:/firebird/data/medicus.fdb

V Knihovny/medicus_db.py je odpovídající záznam v dsn_map (klíč TOWER). Cutover skriptů/MCP z reporteru (2.5.7) na tower (2.5.9) = otevřené rozhodnutí.

Cron (na toweru)

Záloha přistává ~02:15; denní rutina poté. Plánovat přes User Scripts plugin (vzor: PostgreSQLRestoreFromBackup), spouštět:

/mnt/user/Scripts/MedicusFirebird/restore_medicus.sh      # napr. 06:30 denne