Backup e disaster recovery Odoo: business continuity per PMI italiane (guida pratica)

Quarantaduesima guida operativa Odoo 19 per PMI italiane. Un guasto hardware, un ransomware, un errore umano massivo, un incendio nei datacenter. Sono i 4 scenari più comuni di disastro IT per una PMI. Senza un piano di backup e disaster recovery (DR) testato, qualsiasi di questi eventi può causare la fine dell’azienda. Con un DR plan strutturato e testato, il sistema torna operativo in 4-24 ore con perdita minima di dati. In questa guida vediamo come progettare backup e disaster recovery Odoo per business continuity.

Vediamo: scenari di disastro, RTO/RPO, strategie backup (3-2-1 rule), disaster recovery plan, test periodici, business continuity plan, casi pratici PMI italiane.

Cosa proteggere: i 3 livelli di Odoo

1. Database PostgreSQL

• Tutti i dati transazionali (ordini, fatture, registrazioni)
• Configurazione moduli installati
• Audit log e cronologia modifiche
• Sequenze documentali

2. Filestore (allegati)

• PDF fatture, XML SdI
• Documenti caricati (contratti, scansioni)
• Immagini prodotti
• Avatar utenti, loghi

3. Codice e configurazione

• Custom modules (in repository Git)
• File configurazione server (odoo.conf, nginx, postgres)
• SSL certificate
• Cron jobs scheduling

Scenari di disastro tipici

1. Hardware failure

• Disk corruption, server down, network failure
• Probabilità: media (1-2 volte/anno per server fisico)
• Impatto: downtime ore-giorni se senza HA
• Mitigation: RAID, HA setup, cloud auto-recovery

2. Ransomware/cyberattack

• Cifratura dati, richiesta riscatto
• Probabilità: alta (PMI italiane: 40%+ subiscono almeno 1 attacco/anno)
• Impatto: settimane di downtime, perdita dati permanente se backup compromessi
• Mitigation: backup immutable + offline, security awareness

3. Errore umano

• Cancellazione massive dati, import sbagliato, bug Custom
• Probabilità: alta (10-20 incidenti/anno per PMI media)
• Impatto: variabile, da 1h a settimane
• Mitigation: backup point-in-time, audit log, undo features

4. Disastro naturale/fisico

• Incendio datacenter, alluvione, terremoto
• Probabilità: bassa (1 evento ogni 5-10 anni)
• Impatto: catastrofico se single-site
• Mitigation: backup geografico distinct, multi-region

5. Vendor failure

• Cloud provider down, partner Odoo fallimento
• Probabilità: bassa-media
• Impatto: ore-settimane
• Mitigation: backup esterni indipendenti, multi-cloud per critici

RTO e RPO: i due numeri che definiscono il piano

RTO (Recovery Time Objective)

Tempo massimo per cui l’azienda può rimanere senza il sistema. Quantifica il “quanto lentamente possiamo tornare operativi”.

RTO	Soluzione tipica	Costo /anno
< 1h	High Availability + hot standby	10-30k €
1-4h	Hot backup + automated restore	5-15k €
4-24h	Cold backup + manual restore	2-6k €
1-7 giorni	Backup base + ricostruzione	500-2k €

RPO (Recovery Point Objective)

Quantità massima di dati che l’azienda può permettersi di perdere. Quantifica il “quanto possiamo perdere indietro nel tempo”.

RPO	Soluzione	Casi d’uso
0 (zero loss)	Synchronous replication	Banche, sanità critical
< 15 minuti	Continuous replication	E-commerce alto volume
1-4 ore	Backup orario incrementale	PMI Operations
24 ore	Backup giornaliero	PMI standard (raccomandato)
1 settimana	Backup settimanale	Solo dev/test environment

Stima RTO/RPO target per PMI tipica

• PMI standard: RTO 4-8h, RPO 24h → backup giornaliero + procedura restore documentata
• PMI con e-commerce: RTO 2-4h, RPO 4h → backup orario incrementale + hot standby
• PMI manifattura just-in-time: RTO 1-2h, RPO 1h → HA setup + continuous replication

Dati critici da proteggere: focus contabilità

Movimenti contabili

I journal entries sono il cuore della contabilità: anni di registrazioni che, persi, significano la fine dell’azienda. Il backup deve garantire integrità referenziale completa:

• Tutte le scritture contabili con riferimenti
• Riconciliazioni bancarie
• Allegati fatture (XML SdI, PDF)
• Sequenze numerazione invariate

Giornali contabili

I giornali (sales, purchase, bank, miscellaneous) sono la struttura organizzativa della contabilità. Configurazioni e impostazioni di ognuno vanno preservate:

• Configurazione conti di default
• Sequenze numerazione per giornale
• Currency settings
• Restrizioni utenti per giornale

Pagamenti e riconciliazioni

I pagamenti tracciano il flusso finanziario: post-restore, devono essere riconciliati con estratti conto banca per verificare integrità:

• Pagamenti in ingresso (clienti)
• Pagamenti in uscita (fornitori)
• Riconciliazione con estratti conto banca
• Documenti collegati (fatture, bonifici)

La regola 3-2-1 (e la sua evoluzione 3-2-1-1-0)

Regola classica 3-2-1

• 3: 3 copie totali dei dati
• 2: 2 supporti diversi (es. disk + cloud)
• 1: 1 copia off-site (geograficamente distinta)

Evoluzione 3-2-1-1-0

• 1 immutable: 1 copia non modificabile (protezione ransomware)
• 0 errori: 0 errori in test di restore

Implementazione pratica per PMI

• Copia 1: backup locale su server NAS dedicato
• Copia 2: backup su cloud object storage (S3, Backblaze B2)
• Copia 3 (off-site): backup su altro provider cloud o storage offline mensile
• Immutable: cloud storage con versioning o WORM (Write Once Read Many)
• Test mensile: restore in staging, verifica integrità

Frequenza backup

Database

• Full backup: settimanale (es. domenica notte)
• Differential backup: giornaliero (notte)
• Incremental/WAL: ogni 15-60 minuti per RPO bassi
• Retention: 7 daily + 4 weekly + 12 monthly + 7 yearly (configurabile)

Filestore

• Backup giornaliero incrementale
• Sincronizzazione real-time per filestore critico (rsync, MinIO mirror)
• Retention come database

Codice e config

• Codice: già in Git, backup repository remoto
• Config server: snapshot VM settimanale o backup file config
• Cifrato per protezione credentials

Strumenti backup Odoo

Tool nativi

• pg_dump: dump database PostgreSQL completo
• pg_basebackup + WAL: backup continuo
• Odoo backup API: /web/database/backup
• Script bash con cron per automazione

Tool managed

• Odoo.sh: backup automatici inclusi (Odoo managed hosting)
• Barman: PostgreSQL backup manager enterprise
• pgBackRest: backup professionale con encrypt + S3
• Veeam, Acronis: backup VM-level

Tool cloud-native

• AWS RDS automated backups
• Google Cloud SQL backup
• Azure SQL backup
• Snapshot consistency check incluso

Disaster Recovery Plan (DRP)

Componenti del piano

• Identificazione asset critici: cosa proteggere, priorità
• RTO/RPO target per ogni componente
• Procedure di restore: step-by-step documentate
• Ruoli e responsabilità: chi fa cosa durante disastro
• Communication plan: chi comunica a chi (interni + esterni)
• Contatti emergenza: provider cloud, partner Odoo, hosting
• Checklist post-recovery: verifiche pre-ritorno produzione

Procedura restore tipica

• 1. Dichiarazione incident formale + team mobilization
• 2. Assessment scope danno + decisione restore vs rebuild
• 3. Selezione punto di restore (data/ora)
• 4. Restore database PostgreSQL
• 5. Restore filestore
• 6. Restore configurazione server
• 7. Smoke test funzionalità critiche
• 8. Comunicazione utenti ripartenza
• 9. Monitoring intensivo prime 24h
• 10. Postmortem entro 7 giorni

Test periodici del DR

Tipologie di test

• Tabletop exercise: simulazione “su carta”, 2-4 ore (annuale)
• Walkthrough test: revisione procedura passo-passo (semestrale)
• Simulation test: simulazione restore su ambiente test (trimestrale)
• Full DR test: failover completo a sito DR (annuale)
• Surprise drill: test non annunciato per team (annuale)

Cosa misurare nei test

• Tempo effettivo restore (vs RTO target)
• Quantità dati persi (vs RPO target)
• Errori procedurali identificati
• Gap nella documentazione
• Comunicazione e coordinamento team

Issue tipiche scoperte nei test

• Procedura restore obsoleta dopo upgrade infrastruttura
• Credenziali admin non aggiornate
• Backup corrotti senza segnalazione
• Network firewall blocca traffic restore
• Team non sa chi contattare

Business Continuity Plan (BCP)

Cosa è il BCP

Piano più ampio del DRP. Mentre il DRP risponde a “come tornare operativi” il BCP risponde a “come continuare a operare anche durante l’interruzione”.

Componenti BCP per PMI

• Manual operations procedures: come operare senza Odoo (cartaceo, Excel)
• Critical processes prioritization: cosa deve continuare comunque (es. fatturazione)
• Communication plan: clienti, fornitori, autorità
• Alternative workspace: dove lavorare se sede inaccessibile
• Vendor management: backup fornitori critici
• Recovery sequence: ordine ripristino processi business

Costi tipici backup e DR

Componente	Setup	Ricorrente/anno
Backup automatizzato + storage cloud	2-5k €	1-4k €
DR plan documentato + test trimestrali	4-10k €	3-8k €
Hot standby server (HA)	5-15k €	3-10k €
Multi-region setup (cloud)	10-25k €	5-15k €
Business Continuity Plan completo	8-20k €	3-8k €

Errori comuni nel backup/DR

“Backup configurato, mai testato”

Problema: backup esistenti da 3 anni, nessuno ha mai fatto un restore.
Soluzione: test restore mensile obbligatorio. “Backup non testato = no backup”.

“DR plan ma di 2 anni fa”

Problema: piano DR datato, infrastruttura cambiata, procedure obsolete.
Soluzione: review annuale obbligatoria + dopo ogni cambio significativo.

“Backup sullo stesso server di Odoo”

Problema: server compromesso = backup persi.
Soluzione: backup ALWAYS su sistema/storage separato. Off-site obbligatorio.

“Solo backup, nessun DR plan”

Problema: durante disastro nessuno sa che fare, panico totale.
Soluzione: documentazione procedure step-by-step, ruoli chiari, drill periodici.

“Backup ransomware-vulnerable”

Problema: backup su share di rete vengono cifrati durante attacco.
Soluzione: backup immutable o offline almeno per copia critica.

Casi pratici PMI italiane

Caso 1 — Manifattura: DR completo testato

• RTO 4h, RPO 1h target
• Backup ogni 30 min su S3 + immutable copy
• Hot standby in altro region cloud
• Test DR trimestrale documentato
• Costo: 12k € setup + 8k €/anno
• Quando servì: ransomware bloccato, recovery 3.5h, zero dati persi

Caso 2 — Distributore: scampato per fortuna

• Backup automatici ma mai testati
• Disk crash server: tentativo restore
• Backup ultimi 4 mesi corrotti (errore silente)
• Recovery da backup 4 mesi vecchio: persi dati operativi
• Lesson learned: test mensile obbligatorio post-incidente

Caso 3 — Servizi B2B: DR plan a 3 livelli

• Livello 1: backup giornaliero (RPO 24h)
• Livello 2: replica WAL ogni 15 min (RPO 15min)
• Livello 3: hot standby HA (RTO < 1h)
• Annual full DR drill con cliente top come osservatore
• Costo: 18k €/anno totali

Caso 4 — E-commerce: multi-region cloud

• Setup AWS multi-region (Frankfurt + Ireland)
• RDS automated backup + cross-region replication
• S3 cross-region replication per filestore
• Test failover annuale: 12 minuti totali
• Costo: 22k € setup + 14k €/anno

FAQ

Quanto spazio serve per backup Odoo?

Database tipico PMI: 5-50GB. Filestore: 10-200GB (dipende da numero allegati). Con retention 30 giorni daily + 12 mensili: serve 5-15x dimensione live system. Per PMI 50GB live: budget 250-750GB storage backup.

Posso fare backup Odoo a caldo (mentre il sistema è in uso)?

Sì, sia pg_dump che pg_basebackup supportano hot backup senza downtime. Filestore può richiedere snapshot per consistency. Best practice: window di backup in orari off-peak (notte) per ridurre carico.

Quanto dura un restore tipico?

Database 10GB: 15-30 min. Database 100GB: 1-3 ore. Filestore 50GB: 30 min-2h (dipende rete). Restore completo PMI tipica: 2-6 ore inclusi test pre-go-live. Sopra 8h: indica architettura da rivedere.

Conviene Odoo.sh per backup automatici?

Sì se PMI < 50 utenti e setup standard. Odoo.sh include backup gestiti, restore self-service, staging environment. Costo extra: 30-50% vs Odoo Enterprise standalone. Per setup custom complessi: meglio self-managed con tool dedicati.

Devo cifrare i backup?

Sì, sempre. GDPR e best practice security richiedono cifratura at-rest dei backup. Soluzioni: pg_dump | gpg encrypt, S3 server-side encryption, Borg backup encrypted. Costo zero, beneficio massimo. No-go per audit/certificazioni senza encryption.

Prossimi passi

Nelle prossime guide vedremo come scalare Odoo a 200+ utenti con architecture distribuita, come migrare a infrastruttura cloud mantenendo performance, e come gestire upgrade a maggior contesto di anni di customization accumulate.

Vuoi un piano di backup e DR Odoo testato per la tua PMI?
G Tech Group implementa backup e disaster recovery Odoo per PMI italiane: automazione, regola 3-2-1, immutable backup, test periodici, DR plan documentato. Track record recovery riuscito al primo tentativo.
Richiedi un preventivo gratuito oppure prova la nostra demo Odoo 19 live. Oppure prova Odoo direttamente su odoo.com (link partner Brentasoft).