# Persistenza dati Docker `.157` e sync documentazione `.53`

## Obiettivo

Rendere esplicita la persistenza dei dati critici fuori dai volumi Docker anonimi o impliciti, e standardizzare il passaggio della documentazione operativa verso la macchina `.53`.

## Decisione operativa

Per il multisite produzione/demo su `192.168.0.157` la persistenza deve vivere su disco host, non solo nel layer gestito da Docker:

- MySQL produzione: `/srv/netgescon/prod/mysql`
- storage Laravel produzione: `/srv/netgescon/prod/storage`
- public produzione: `/srv/netgescon/prod/public`
- bootstrap cache produzione: `/srv/netgescon/prod/bootstrap-cache`
- redis produzione: `/srv/netgescon/prod/redis`
- MySQL demo: `/srv/netgescon/demo/mysql`
- storage Laravel demo: `/srv/netgescon/demo/storage`
- public demo: `/srv/netgescon/demo/public`
- bootstrap cache demo: `/srv/netgescon/demo/bootstrap-cache`
- redis demo: `/srv/netgescon/demo/redis`
- Traefik/Let's Encrypt: `/srv/netgescon/traefik/letsencrypt`
- backup locali multisite: `/srv/netgescon/backups/multisite`

Questi path sono configurabili da `docker/.env.multisite`.

## Script operativi introdotti

### Preparazione path host

```bash
./scripts/ops/netgescon-prepare-multisite-host-paths.sh --env-file docker/.env.multisite --report
```

Effetti:

- crea le directory host richieste dal compose
- prepara le sottodirectory Laravel minime in `storage/`
- imposta ownership compatibile con `www-data` per storage/cache/public

### Deploy e update

Gli script:

- `./scripts/deploy-multisite.sh`
- `./scripts/update-multisite.sh`

ora eseguono automaticamente:

1. generazione `APP_KEY` se manca
2. preparazione path host persistenti
3. build/recreate dei servizi Docker

### Backup locale completo

```bash
./docker/backup-multisite.sh
```

Contenuto del backup:

- dump SQL produzione
- dump SQL demo
- archivio `tar.gz` di `prod/storage`
- archivio `tar.gz` di `prod/public`
- archivio `tar.gz` di `demo/storage`
- archivio `tar.gz` di `demo/public`
- copia del file `docker/.env.multisite`

Output predefinito:

- `/srv/netgescon/backups/multisite`

### Backup incrementale documenti su Google Drive

```bash
./scripts/ops/netgescon-data-backup-incremental-gdrive.sh --env-file docker/.env.multisite
```

Default operativi:

- sorgente: `${PROD_STORAGE_PATH}/app/amministratori`
- remoto: `gdrive:NetGesconBackups/prod/documenti-amministratori`

Questo copre la copia incrementale dei documenti per amministratore/stabile/fornitore gia presenti nello storage applicativo.

Per backup pre-update applicativo con zip e metadati continua a restare valido anche:

```bash
php artisan netgescon:preupdate-backup --admin-id=<ID> --drive --tag=pre-update
```

## Procedura documentale verso `.53`

### Principio

La sorgente ufficiale resta il repository Day0/Gitea. La `.53` deve avere un mirror documentale pulito, separato dal checkout applicativo sporco o operativo.

### Sync standard dopo ogni aggiornamento docs

```bash
./scripts/ai/sync_docs_to_53.sh --env-file docker/.env.multisite
```

Default:

- host target: `michele@192.168.0.53`
- mirror target: `/var/www/netgescon-docs`
- bootstrap remoto: `~/netgescon/netgescon-day0/scripts/ai/bootstrap_docs_mirror.sh`

Modalita `mirror`:

- esegue sulla `.53` il refresh del mirror docs da Gitea
- mantiene `.53` allineata al commit ufficiale
- evita di usare come sorgente il checkout applicativo `/var/www/netgescon`

Modalita alternativa `push`:

```bash
./scripts/ai/sync_docs_to_53.sh --mode push --env-file docker/.env.multisite
```

Usarla solo per emergenze operative o bootstrap, non come flusso normale.

## Verifica minima consigliata su `.157`

```bash
./scripts/ops/netgescon-prepare-multisite-host-paths.sh --env-file docker/.env.multisite --report
docker compose --env-file docker/.env.multisite -f docker/docker-compose.multisite.yml ps
du -sh /srv/netgescon/prod/mysql /srv/netgescon/prod/storage /srv/netgescon/demo/mysql /srv/netgescon/demo/storage
```

## Verifica minima consigliata su `.53`

```bash
./scripts/ai/sync_docs_to_53.sh --env-file docker/.env.multisite
ssh michele@192.168.0.53 'test -f /var/www/netgescon-docs/docs/README.md && git -C /var/www/netgescon-docs rev-parse --short HEAD'
```

## Criterio di successo

La procedura puo essere considerata attiva quando:

1. i servizi `prod_app` e `prod_db` usano bind mount host visibili sotto `/srv/netgescon`
2. i dump SQL e gli archivi `storage/public` vengono prodotti su disco host
3. la copia incrementale verso Google Drive punta allo storage persistente host
4. la `.53` dispone di un mirror docs aggiornabile con un solo comando