Politica di conservazione dei backup: come scegliere i periodi di conservazione e le regole di eliminazione

Una politica di conservazione dei backup definisce quali stati dei dati restano disponibili, per quanto tempo conservarli e che cosa accade alla scadenza. Il suo scopo va oltre il risparmio di spazio. Uno storico troppo breve può scadere prima che qualcuno scopra un errore. Uno storico troppo lungo aumenta i volumi, i costi e la quantità di dati sensibili da proteggere.

Una politica utile definisce la cronologia di ripristino richiesta, la granularità del punto di ripristino, le posizioni di archiviazione, le eccezioni di eliminazione e un proprietario per ogni sistema. Un numero predefinito di giorni preso da un esempio altrui non può sostituire queste decisioni.

Distinguere quattro diverse questioni di conservazione

Un programma di backup non definisce l’intera politica di conservazione

Un lungo periodo di conservazione non fornisce automaticamente una cronologia dettagliata. Se conservi solo un punto di ripristino al mese, non puoi garantire di poter ripristinare i dati in qualsiasi giorno di quel mese. Al contrario, i backup frequenti non ti aiuteranno a trovare uno stato precedente se l’intera cronologia viene eliminata prima che qualcuno scopra il problema.

Un backup e un archivio hanno scopi correlati ma diversi. Un backup ripristina uno stato specifico di un sistema o dei suoi dati. Un archivio può supportare una conservazione prolungata e la ricerca di singoli record. Chiarisci il risultato richiesto invece di applicare automaticamente un periodo di conservazione per ogni backup completo del sistema.

Per un’applicazione cloud, verifica la cronologia della versione nativa, il cestino, le regole di conservazione dei contenuti e le funzionalità di backup separatamente. Il loro ambito e le operazioni disponibili possono differire. Una politica di conservazione non dimostra che il ripristino richiesto è possibile, e il nome del fornitore non stabilisce che non sia disponibile.

Raccogliere i requisiti per ciascun gruppo di dati

Definire profondità e granularità necessarie dello storico

Chiedete al proprietario del sistema quali errori devono essere corretti e quando le persone di solito se ne accorgono. Una cancellazione rilevata immediatamente e un’anomalia silenziosa scoperta durante una successiva riconciliazione richiedono storie diverse. Tenete conto dei cicli aziendali completi, dei controlli dei dati e della possibilità di ripristinare uno stato precedente utilizzabile.

Specificate con quale precisione è necessario selezionare uno stato: una transazione specifica, un momento vicino, un giorno o un punto storico meno frequente. Confrontate questo con le modifiche dei dati e l’RPO concordato. L’RPO descrive la perdita accettabile di modifiche recenti, ma non determina automaticamente la profondità dell’intera storia.

Elencate i dati e le dipendenze che devono essere ripristinate insieme. Un’applicazione potrebbe aver bisogno del suo database, dei file, delle impostazioni e delle versioni di componenti compatibili. Mantenere un elemento per un lungo periodo di tempo non aiuterà se un componente correlato è già scaduto o non può essere utilizzato.

Verificare vincoli e responsabilità

Classificate i dati in base al valore, alla sensibilità e alle regole applicabili. Il responsabile del processo conferma la necessità di una storia. Il responsabile tecnico verifica le funzionalità del prodotto e i costi. Concordate i requisiti per documenti, dati personali e eccezioni di cancellazione con le persone responsabili in organizzazione.

Non assegnate un unico periodo di conservazione a tutti i dati semplicemente perché qualcuno menziona HIPAA, GDPR, normative finanziarie o la legge di un altro paese. Ogni requisito si applica a dati, organizzazioni e attività specifiche. Registrate il risultato concordato di tale valutazione nella politica di backup, piuttosto che fare un’assunzione basata sul nome di una legge.

Progettare i livelli dello storico e verificare i limiti del prodotto

Conservare i punti di ripristino necessari, non semplicemente più file

È possibile dividere la politica in una storia recente dettagliata e punti storici meno frequenti. Un sistema GFS descrive generalmente una combinazione di backup giornalieri, settimanali e mensili. Aiuta a organizzare la storia, ma non prescrive periodi di conservazione obbligatori o garantisce ogni stato intermedio.

Per ogni livello, definire come selezionare i punti di ripristino, per quanto tempo conservarli e come spostarli tra i livelli. Confermare quale evento utilizza il prodotto per calcolare l’età: avvio del lavoro, creazione del punto di ripristino o un altro evento. Verificare il fuso orario e le regole di sovrapposizione. L’insieme di dati effettivamente conservato è più importante di un nome di programma facile da capire.

Se si utilizzano backup completi e incrementali, definire quali dati richiede il punto di ripristino selezionato. Eliminare manualmente un singolo file da una catena di backup è rischioso. Utilizzare la gestione del ciclo di vita supportata e verificare che preservi le dipendenze di altri punti di ripristino. Verificare l’implementazione prima di fare affidamento su una affermazione che ogni punto è indipendente.

Distinguere conservazione, tipo di archiviazione e disponibilità del ripristino

Spostare la cronologia più vecchia in una classe di archiviazione meno costosa può modificare il tempo di recupero, i costi di ripristino e le restrizioni di eliminazione. Prima di spostarla, verificare che sia possibile recuperare i dati entro il tempo richiesto. Un prezzo di archiviazione basso non può compensare un percorso di ripristino inadatto.

Ad esempio, AWS Backup utilizza impostazioni separate per i programmi, il ciclo di vita e le transizioni verso l’archiviazione a freddo. Il supporto per le transizioni dipende dalle risorse e sono previste limitazioni per la durata minima e le modifiche alla configurazione. Verificare le condizioni attuali del servizio. Non trasferire i numeri e i limiti di un prodotto a un altro.

Per le copie archiviate altrove, verificare le regole del sistema di destinazione. La durata di conservazione, la classe di archiviazione e il comportamento dopo l’eliminazione della copia principale possono differire dalla sorgente. Registrare quali copie sono controllate dalla politica, inclusi i vecchi backup manuali e i dati conservati dopo che un sistema viene disattivato.

Concordare blocchi ed eccezioni prima dell’eliminazione

L’immutabilità può impedire l’eliminazione precoce. La sua durata non corrisponde sempre all’intero periodo di conservazione. Verificare entrambi i valori, i permessi per modificarli e le impostazioni irreversibili. Allungare un periodo può comportare costi aggiuntivi, mentre accorciarlo tramite controlli normali potrebbe essere impossibile.

Un’indagine o un’altra eccezione concordata può richiedere la sospensione dell’eliminazione di un determinato insieme di dati. Specificare il motivo, l’ambito, il responsabile della decisione, la data di revisione e il processo per rimuovere l’eccezione. Verificare esattamente come il prodotto supporta questo. Non presumere che ogni backup fornisca automaticamente una conservazione legale.

Compilare la matrice della politica di conservazione

Utilizzare una riga separata per ogni sistema o classe di dati con gli stessi requisiti. Compilare i campi tra parentesi dopo aver raggiunto un accordo. Se i dati all’interno di un singolo sistema presentano vincoli diversi, creare righe separate e verificare se il prodotto può applicare regole diverse senza compromettere il recupero completo.

Matrice di conservazione con campi da concordare

Aggiungere la versione della policy e le impostazioni che la implementano alla matrice. Registrare separatamente le eccezioni approvate e il processo di modifica. Questo consente di confrontare la decisione concordata con la configurazione effettiva, invece di dover cercare tra email e vecchie versioni.

Verificare l’applicazione della politica e la conclusione della conservazione

Dopo la configurazione, confrontare i punti di ripristino previsti e effettivi ai confini dei livelli. Assicurarsi che la cronologia richiesta rimanga e che le regole non entrino in conflitto. Verificare come si comportano i punti di ripristino esistenti dopo un cambiamento di policy: il prodotto potrebbe applicare nuove impostazioni in modo diverso a questi rispetto a nuove copie.

Ripristina un punto di ripristino precedente selezionato, nonché uno recente. Verifica la disponibilità dell’applicazione, delle dipendenze richieste e dei dati nella classe di archiviazione appropriata. Per una copia crittografata, conferma l’accesso alle chiavi di decrittazione. Misura il tempo di recupero e verifica che i dati ripristinati supportino l’attività aziendale.

La scadenza dovrebbe innescare l’azione prevista, a condizione che siano presenti blocchi e eccezioni. Verifica i risultati della cancellazione, gli errori e le copie rimanenti in altre posizioni. Eliminare un elemento del catalogo non rilascia sempre immediatamente ogni blocco fisico. Dati condivisi, catene e meccanismi di archiviazione possono influire su questo. Conferma come il servizio e il tipo di media verificano la cancellazione.

Non promettere di eliminare immediatamente un singolo record da ogni backup completo immutabile. Se le regole di accesso o cancellazione richiedono una gestione speciale, concordate un processo tecnicamente fattibile in anticipo. Distruggere i supporti non è nemmeno un’azione universale per ogni punto di ripristino nel cloud scaduto.

Rivedere costi, protezione ed eccezioni

• Confrontare profondità e granularità effettive dello storico con la matrice.
• Monitorare crescita dei volumi, processi non riusciti ed errori del ciclo di vita.
• Verifica i permessi, la protezione dell’accesso amministrativo e la disponibilità delle chiavi.
• Includi i costi di archiviazione, recupero, trasferimento e mantenimento della compatibilità.
• Rivedi i periodi di conservazione dopo che cambiano i cicli aziendali, i sistemi, le minacce o i requisiti concordati.
• Conferma la necessità continua di eccezioni estese e terminandole in conformità con la decisione approvata.
• Conserva i risultati della verifica, i responsabili della correzione e la cronologia delle modifiche alle politiche.

L’automazione aiuta ad applicare in modo coerente orari e cancellazioni. Applicherà anche una regola errata in modo coerente. Tieni traccia delle eccezioni e verifica il risultato. Conservare indefinitamente, solo in caso, e un periodo per l’intera azienda necessita della stessa giustificazione della riduzione della cronologia.

Avete bisogno di concordare la profondità della documentazione storica e verificarne l’implementazione? Contattate DKs Enterprises per soluzioni di backup e disaster recovery. Preparate la vostra matrice di sistemi, i periodi di conservazione attuali e le eccezioni note per discutere del lavoro necessario.

Fonti

• Documentazione ufficiale del ciclo di vita di AWS Backup