# Backup Orchestrator (bckWinRsync)

## Sommario
- Client Windows PySide6 che manda richieste HTTPS a un Orchestrator FastAPI.
- Server Debian su Proxmox che esegue job `rsync` in pull verso `/srv/backup/current` con storicizzazione (`.history/<run_id>`) e retention 20 esecuzioni.
- Sicurezza LAN con HTTPS, SSH, logging strutturato, validazione path e protezioni sulle credenziali.

## Requisiti principali
1. Il client gestisce profili e selezione di cartelle, abilitando “Esegui” solo con almeno una destinazione valida.
2. Il pulsante “Esegui” invia credenziali SSH e percorsi al backend, che crea un job e lo mette in coda.
3. Il job runner server si connette via SSH al client e invoca `rsync --backup --backup-dir=/srv/backup/.history/<run_id>`, senza `--delete`.
4. Le cancellazioni upstream non si propagano: `/current` mantiene i file attivi e `.history` conserva le versioni precedenti fino a 20 run.
5. Il client mostra log/progress via GUI, notificando il completamento o eventuali errori.
6. `config.json` (vicino all’eseguibile) definisce profili, cartelle, endpoint API, compressione e toggle dello scheduler `schtasks`. Lo scheduler può essere attivato o disattivato per chiamare l’API autonomamente.

## Non funzionali
- Affidabilità tramite job idempotenti con lock e timeout.
- Performance differenziali con `rsync -a --info=progress2 --compress` opzionale e `--partial`.
- Manutenibilità grazie a separazione chiara tra GUI, orchestratore e runner/logging.
- Sicurezza con token JWT, HTTPS, SSH limitato all’utente `backupsvc`, DPAPI per credenziali e log rotati.

## Architettura
- **Client PySide6**: profili, scheduler switch, log real-time, polling stato API (`/backup/status/{job_id}`, `/backup/log/{job_id}`).
- **Orchestrator FastAPI + Uvicorn**: espone `/auth/login`, `/profiles`, `/backup/start`, `/backup/status`, `/health`; usa DB (SQLite/Postgres) per job e log.
- **Job Runner (systemd)**: serializza job, invia comandi SSH verso il `sshd` Windows, aggiorna stato job e archivia log/retention.
- **Backup Storage**: `/srv/backup/current` per il dataset attivo, `/srv/backup/.history/<run_id>` per versioni storiche.

## API e sicurezza
- Autenticazione via `/auth/login` che restituisce JWT con scadenza, ratelimit e lockout.
- Validazione input (allow-list cartelle, no path traversal) e logging strutturato JSON senza password.
- HTTPS con certificati self-signed o CA interna; SSH consentito solo dall’IP del server verso `backupsvc` con shell limitata.
- Retention 20 run con task di cleanup che elimina `.history` più vecchi.

## Scheduling e configurazione
- Switch PySide6 gestisce `schtasks` che esegue `BackupClient.exe --auto` con token, se abilitato.
- Configurazione opzionale per credenziali via DPAPI o prompt ogni esecuzione.
- Job runner esegue `rsync` con lock e retry/timeout configurabili.

## Fasi previste
1. Setup server: Debian, storage `/srv/backup`, rsync, OpenSSH client/server, permessi.
2. Orchestrator: API start/status/log, DB, job queue, retention automatica.
3. Client PySide6: GUI, log, scheduler sincronia, config e packaging.
4. Windows helper: script attivazione OpenSSH/rsync, firewall e permessi.
5. QA/hardening: logging, rate limit, test end-to-end e threat modeling leggero.

## Checklist sicurezza
- SSH da server solo verso IP autorizzato e `backupsvc`.
- Password SSH mai loggate, prompt o DPAPI.
- HTTPS interno gestito con cert e rotazione log (logrotate).
- Validazione input e cron job cleanup.
- Utente Linux `backupsvc` con directory `700`, log `640`.

## Deliverable attesi
- Repo server: FastAPI, runner, doc/install, test.
- Repo client: PySide6, config schema, scheduler script, rsync portable.
- Documentazione: manuale utente, runbook admin, threat model, checklist.
- CI: lint/test/build/release pipeline.