Vai al contenuto

PR21.1 - Gestione dei Backup e Restore

Procedura Gestione dei Backup e Restore

Revisioni
Rev. Data Descrizione Redatto Approvato
0.0 24/04/2026 Prima emissione IT CTO
0.1 09/07/2026 Revisione assistita da IA: allineamento allo stack reale (GitHub, Google Workspace, AWS, server Aruba in IaC, Bitwarden); rimozione di NAS/VMware/Hyper-V/Dropbox/OneDrive/videosorveglianza non in uso RSGI Amministratore Unico

Introduzione

Il presente documento descrive la procedura per la gestione di backup e relativo restore.

Riferimenti e Allegati

MDPR21.1.A - Piano di Restore

MDPR21.1.B - Richiesta Restore

PO21 - Politica Gestione dei Backup

PR03.1 - IT

Definizioni, Acronimi, Abbreviazioni

AWS – Amazon Web Services

Bitwarden – Gestore delle credenziali/segreti, ospitato sul server Aruba

DB – DataBase

ECR – Elastic Container Registry: Docker registry privato

ECS – Elastic Container Service: gestore di container

EC2 – Elastic Compute Cloud: servizio web che fornisce capacità di elaborazione nel cloud AWS

GitHub – Piattaforma di versionamento (repository di codice e documentazione)

IaC – Infrastructure-as-Code (infrastruttura descritta e gestita come codice)

IT – Information Technology

S3 – Simple Storage Service: servizio web di memorizzazione

Task definition: insieme di regole che consentono l’esecuzione di un container Docker

Gestione dei Backup

A fronte della necessità di definire/modificare una strategia di backup/restore, l’IT individua i criteri, le risorse e il tipo di modalità operative necessarie per una procedura di backup. In dettaglio:

  • individua il tipo di supporto da utilizzare tenendo presente:

    • la tipologia del dato da sottoporre a procedura di sicurezza;

    • il suo livello di criticità;

    • l'urgenza della sua reperibilità;

    • esplicite esigenze espresse dal richiedente;

    • l'entità del dato.

  • individua il tipo di software da utilizzare tenendo presente:

    • la tipologia del dato da sottoporre a procedura di sicurezza;

    • il suo livello di criticità;

    • la frequenza con cui va salvato.

  • individua dove salvare il backup;

  • stabilisce il livello di accesso e di protezione del backup;

  • aggiorna l’elenco dei backup (vedi Tabella 1- Riepilogo backup);

Per una procedura di ripristino:

  • individua e reperisce il supporto contenente i dati da ripristinare tenendo presente:

    • la tipologia del dato sottoposto a procedura di sicurezza;

    • il suo livello di criticità;

    • esplicite esigenze espresse dal richiedente;

    • l'entità del dato.

  • individuazione del tipo di software da utilizzare tenendo presente:

    • la tipologia del dato sottoposto a procedura di sicurezza;

    • il suo livello di criticità.

Il documento “MDPR21.1.A - Piano di restore” è sia in input che in output alla procedura, in quanto in base alla pianificazione viene effettuato un test programmato di ripristino (restore) dei backup, e a seguito dell’applicazione della presente procedura il piano viene aggiornato di conseguenza.

Definizione strategia

L’esecuzione è a carico dell’IT, che provvede a verificarne l’esito in base agli strumenti di schedulazione e registrazione previsti per lo specifico ambiente tecnico.

Il prodotto in uscita da una procedura di backup è una copia del dato oggetto della richiesta. La sua gestione è a carico del reparto IT. Le modalità di gestione sono relative a:

  • periodo di conservazione;

  • sito di conservazione.

Il periodo di conservazione è il periodo di tempo per il quale viene assicurata la disponibilità del dato salvato. È definito in base alla:

  • tipologia del dato;

  • esplicita o implicita esigenza del cliente.

Il prodotto in uscita da procedure di restore è il dato ripristinato.

Quando il backup/restore fa riferimento a un’attività schedulata nel piano di restore, in uscita alla procedura il piano viene aggiornato con l’esito dell’operazione.

Descrizione strategie di backup

I backup sono definiti in coerenza con il modello cloud-first di Vectorlab: non esistono NAS, server o supporti di memoria fisici in sede. Tutto ciò che ha valore lavorativo risiede su servizi cloud, per loro natura ridondati. Gli oggetti sottoposti a backup e le relative strategie sono descritti di seguito; il dettaglio operativo (oggetto, tipo, frequenza/RPO, conservazione, misure di sicurezza e verifiche) è riportato nella Tabella 1 - Riepilogo strategie di backup.

Codice e documentazione (GitHub)

Tutto il codice sorgente e la documentazione del SGI sono versionati e ospitati su GitHub: ogni commit costituisce un backup incrementale con storico completo, replicato sull’infrastruttura di GitHub. Le copie di lavoro locali non costituiscono la copia ufficiale.

Google Workspace

I dati di Google Workspace (Gmail, Google Drive, Contatti) sono protetti nativamente dalla piattaforma. Per esigenze di conservazione e recupero si utilizzano Google Vault e/o l’esportazione periodica dei dati, con retention definita nella Tabella 1 e nel documento “MDPO15.A - Data Retention”.

Infrastruttura AWS

Le immagini dei container sono conservate sul servizio ECR. I dati conservati su database in cloud AWS vengono salvati tramite script schedulati sul servizio Amazon S3; i backup dei DB sono eseguiti con la periodicità definita in Tabella 1 e vengono conservate le ultime N copie.

Server Aruba (Infrastructure-as-Code)

L’infrastruttura specifica di Vectorlab risiede su un server Aruba gestito in modalità Infrastructure-as-Code: la configurazione è interamente descritta in codice versionato su GitHub e quindi ricostruibile (redeploy) in caso di necessità. Sono inoltre previsti snapshot/backup del server secondo la frequenza indicata in Tabella 1.

Segreti e credenziali (Bitwarden)

I dati sensibili di accesso (password, chiavi, segreti) sono gestiti tramite Bitwarden, ospitato sul server Aruba; ne viene effettuata un’esportazione cifrata periodica secondo la frequenza indicata in Tabella 1.

Descrizione strategie di ripristino

La strategia di ripristino è differente per ogni tipo di servizio su cui è stato effettuato il backup: possono essere effettuati recovery massivi (ad esempio il redeploy dell’infrastruttura sul server Aruba da codice IaC o il ripristino di un container su AWS) oppure granular recovery che consentono il ripristino di un singolo file.

  1. Richiesta restore

La richiesta di restore viene effettuata tramite sistema di ticketing aziendale. In allegato al ticket sarà obbligatorio riempire il modulo di “MDPR21.1.B - Richiesta restore” debitamente compilato in modo da rendere più semplice l’individuazione dei file/cartelle di cui effettuare il restore e il periodo di backup.

Partendo dal modulo IT sceglierà di utilizzare la procedura di restore appropriata.

  1. GSuite

Il ripristino di Google Workspace è gestito tramite Google Vault e/o la console di amministrazione di Google Workspace.

Per il ripristino di file su GSuite i passi sono i seguenti:

  • collegamento all’applicazione “XX”;

  • selezione dell’utenza per cui è da effettuare il ripristino;

  • scelta di tipologia e fascia temporale del backup da ripristinare;

  • per i ripristini relativi a Google Drive, impostazione della cartella per il ripristino; il sistema crea una cartella di ripristino di default nella cartella di root del repository dell’utente; in questa maniera si lascia all’utente la scelta di inserire il file ripristinato nella cartella desiderata.

  • Per i ripristini relativi a Contatti e Gmail, il ripristino avviene nella locazione di default.

  • AWS

Per il ripristino di un container su infrastruttura cloud AWS i passi sono i seguenti:

  • scelta dell’immagine da ripristinare presente su ECR;

  • modifica o nuova creazione della “task definition” in ECS;

  • avvio del task.

Per il ripristino di un DB su infrastruttura cloud AWS i passi sono i seguenti:

  • Download da S3 del DB da ripristinare con la data desiderata, sotto forma di archivio in formato tar.gz;

  • Stop del task relativo al DB su ECS;

  • Su EFS è presente una directory relativa al container del DB; sostituzione del contenuto con i file presenti nell’archivio tar.gz scaricato.

Di seguito una tabella riassuntiva dei backup in essere e informazioni ad esso correlate:

  • OGGETTO BACKUP: applicazione, sistema, informazioni a cui applicare il backup

  • TIPO BACKUP:

    • completo – prevede la copia di tutti i dati (se i dati sono molti richiede potenza computazionale e tempo)

    • incrementale – prevede la copia dei soli dati modificati dall’ultimo backup completo o incrementale (per recuperare i dati è quindi necessario ripristinare l’ultimo backup completo e tutti i successivi incrementali)

    • differenziale – prevede la copia dei soli dati modificati dall’ultimo backup completo (risultano più lenti da effettuare rispetto a quelli incrementali ma consentono di recuperare più velocemente i dati persi)

    • sincronizzato – viene effettuata una copia di ogni file appena è modificato (attenzione che in questo caso si corre il rischio di propagare eventuali errori anche sui dati di backup, valutare se necessario di associarlo ad un backup in altra modalità).

  • GIORNO – ORA: giorno e ora della settimana in cui è schedulato il backup

  • FREQUENZA: ogni quanto il backup viene ri-effettuato

  • SUPPORTO: indicazione del supporto su cui è effettuato il backup (es NAS, Cloud, Hard Disk, nastri magnetici …)

  • ACCESSI: personale avente accesso al backup (ADS, ….)

  • PERIODO CONSERVAZIONE: indicazione del periodo di conservazione delle copie

  • LUOGO DI CONSERVAZIONE. Indicare con precisione luogo in cui le copie sono conservate

  • MISURE DI SICUREZZA: indicare misure di sicurezza applicate alle copie di backup e al luogo di conservazione (crittografia, cassaforte con chiavi gestite da …, luogo protetto da ….)

  • VERIFICHE: frequenza con cui vengono verificate le copie di backup (giornaliera, settimanale, mensile).

Oggetto backup Tipo di backup Giorno - Ora

Frequenza

(RPO)

 Supporto Accessi Periodo conservazione Luogo conservazione Misure Sicurezza Verifiche
GSuite Continuous AdS

Tabella 1 - Riepilogo strategie di backup