Un backup consente di recuperare i dati, ma ripristinarlo direttamente sul database attivo può eliminare modifiche legittime apportate dopo la data del backup. Quando il problema riguarda un record o un insieme circoscritto, l’obiettivo è di solito recuperare le informazioni perse e conservare il resto dello stato attuale. Per farlo, occorre trattare il recupero come un’operazione di confronto e riconciliazione, non come una semplice sostituzione.
La strategia appropriata dipende dal motore di database, dallo schema, dalla disponibilità di log di audit e dall’entità del danno. In un’applicazione PHP, è opportuno separare la logica di recupero dall’applicazione in produzione, documentare le decisioni e testare le convalide prima di scrivere i dati. Se non è possibile determinare quali modifiche siano sicure, fermarsi e preparare una riconciliazione manuale è spesso meno rischioso che automatizzare una sovrascrittura.
Definire cosa significa recuperare i dati
Un ripristino completo sostituisce un database, uno schema o un ampio insieme di dati con il contenuto di un punto di ripristino. Un recupero selettivo, invece, cerca di ripristinare righe specifiche o determinati valori senza modificare gli altri dati attivi. Prima di scegliere, descrivi con precisione il risultato atteso: quale entità manca o è stata alterata, quali campi devono essere recuperati e quali modifiche successive devono essere conservate.
Delimita l’ambito usando identificatori stabili, come la chiave primaria, e non soltanto valori che potrebbero essere cambiati, come il nome o l’indirizzo email. Chiarisci anche se l’incidente riguarda record correlati: per esempio, un ordine può dipendere da righe, pagamenti, indirizzi ed eventi di stato. Recuperare solo la riga principale può lasciare un’entità incoerente; recuperare l’intero gruppo può includere modifiche valide che non devono essere annullate.
- Registra il sintomo, l’intervallo temporale approssimativo e chi ha segnalato il problema.
- Individua le tabelle, le chiavi primarie, le chiavi esterne e i vincoli rilevanti.
- Definisci quali campi devono tornare a un valore precedente e quali devono rimanere invariati.
- Stabilisci chi approverà l’operazione e quali controlli consentiranno di considerarla conclusa.
Scegliere un punto di ripristino e ricostruire il contesto
Seleziona un punto di ripristino che consenta di ricostruire lo stato richiesto, non necessariamente un backup precedente al danno. A seconda dell’incidente, può essere necessario confrontare più backup, log delle transazioni e dati di audit per individuare le informazioni da recuperare e il contesto successivo da conservare. Il ripristino point-in-time può produrre un database temporaneo utile per estrarre dati, ma non significa che sia sicuro trasferirne integralmente il contenuto in produzione.
Conferma la data e il fuso orario, la copertura del backup, lo schema con cui è stato creato e l’esito dei controlli di integrità disponibili. Un backup non verificato non deve essere considerato una fonte affidabile per impostazione predefinita. Verifica inoltre se gli identificatori possono essere stati riutilizzati o se, durante l’indagine, ci sono processi che scrivono nelle tabelle interessate.
Ripristina il backup in un’istanza isolata, con accesso limitato e senza connessioni in scrittura verso la produzione. L’applicazione non dovrebbe puntare accidentalmente a quell’istanza né eseguire su di essa processi pianificati. Se i dati contengono informazioni personali o sensibili, limita l’accesso e applica le misure di protezione previste per tali dati. L’ambiente isolato consente di confrontare gli stati senza aggiungere rischi al database attivo.
Confrontare senza presumere che il backup rappresenti la verità attuale
Confronta le righe candidate del backup con quelle attuali usando le relative chiavi stabili. Per ciascuna, distingui tre situazioni: il record non esiste più, esiste ma presenta campi modificati oppure non mostra differenze rilevanti. Se sono disponibili timestamp di aggiornamento, cronologie degli eventi o audit, usali per capire quando e perché è cambiato. Un timestamp da solo non dimostra quale utente abbia effettuato la modifica né se questa debba essere conservata.
Il recupero selettivo richiede una precauzione essenziale: non copiare automaticamente un’intera riga meno recente quando alcuni dei suoi campi sono cambiati legittimamente nel tempo. Il confronto può mostrare, per esempio, che un record ha perso un campo descrittivo, mentre il suo stato, il proprietario o la relazione con un’altra entità sono cambiati in seguito. Recuperare solo il campo perso può essere più sicuro che sostituire l’intera riga, purché le regole di business lo consentano.
Verifica anche i conflitti di unicità, le chiavi esterne, le colonne obbligatorie, i valori predefiniti e le regole applicate dall’applicazione. Nei sistemi con soft delete, controlla se il record è contrassegnato come eliminato anziché assente. Le tabelle coinvolte nella stessa operazione di business potrebbero richiedere una riconciliazione congiunta, per evitare saldi, stati o riferimenti incoerenti.
Applicare un’operazione circoscritta e verificabile
Prepara un piano con l’elenco esatto delle chiavi e delle colonne da modificare. Prima di eseguirlo, conserva una copia dello stato attuale di quelle righe o predisponi un meccanismo equivalente di rollback. Prova il piano su una copia recente del database attivo e confronta il risultato con quello atteso. La prova deve includere i vincoli e le dipendenze effettivi, non limitarsi all’importazione di righe isolate.
Quando il motore e l’operazione lo consentono, esegui le modifiche all’interno di una transazione. Una transazione non sostituisce la revisione: alcune azioni di ripristino o importazione possono avere comportamenti specifici del motore e processi esterni possono aggiornare i dati contemporaneamente. Usa condizioni che rilevino modifiche inattese tra il confronto e la scrittura. Se la riga non corrisponde più allo stato esaminato, interrompi l’operazione e analizzala di nuovo, invece di sovrascriverla senza segnalarlo.
In un’applicazione PHP, un task controllato o un comando di manutenzione può convalidare gli input, limitare le chiavi interessate e registrare i risultati. Evita di costruire istruzioni SQL concatenando i valori. Usa query parametrizzate e il meccanismo transazionale dell’accesso ai dati adottato dall’applicazione. Mantieni l’operazione fuori dalle route pubbliche e non esporre credenziali o backup nei log di testo.
Prima di confermare le modifiche, verifica il numero di righe interessate, i vincoli e le relazioni rilevanti. In seguito, controlla i valori recuperati e il comportamento dell’applicazione nelle operazioni di business correlate. Se una convalida fallisce prima di confermare una transazione, annulla la transazione. Se la transazione è già stata confermata o si sono verificati effetti irreversibili, non improvvisare una nuova scrittura: attiva il piano di rollback o di recupero approvato prima dell’esecuzione, seguendo la procedura testata per ripristinare lo stato accettato e verificarlo. Se il piano non consente di recuperare uno stato coerente, interrompi ulteriori modifiche, conserva le evidenze e sottoponi la decisione alle persone responsabili.
Documentare la decisione e stabilire quando non automatizzare
Documenta l’incidente, il punto di ripristino utilizzato, le chiavi esaminate, i campi ripristinati e le modifiche successive conservate. Registra chi ha esaminato e approvato l’operazione, quando è stata eseguita, quali convalide sono state effettuate e qual è stato il risultato. Non includere nel log dati sensibili non necessari. Questa tracciabilità consente di spiegare la decisione e facilita eventuali indagini successive.
Scegli la riconciliazione manuale se mancano chiavi affidabili, ci sono conflitti tra operazioni di business, non è possibile distinguere una modifica accidentale da una legittima oppure il recupero riguarda relazioni il cui significato dipende dal contesto. Un ripristino completo può essere appropriato in caso di corruzione estesa, ma occorre valutarne l’impatto, l’interruzione, la perdita delle modifiche successive e la procedura di recupero. Non va scelto solo perché è più semplice da eseguire.
- Recupero selettivo: il danno è ben delimitato, le chiavi sono affidabili e le differenze possono essere verificate.
- Riconciliazione manuale: ci sono modifiche concorrenti o regole di business che richiedono il giudizio umano.
- Ripristino completo: il danno è esteso ed è disponibile un piano approvato per gestire l’indisponibilità e le modifiche che andrebbero perse.
Checklist prima di chiudere il recupero
- Preparazione: sono stati identificati l’ambito, le chiavi, le dipendenze e il risultato atteso? È stato scelto e verificato un punto di ripristino adeguato?
- Ambiente e approvazione: il backup è stato ripristinato in isolamento, l’accesso è stato limitato e la procedura è stata provata? Le persone responsabili hanno approvato l’operazione e il piano di rollback o di recupero?
- Esecuzione: lo stato attuale delle righe interessate è conservato, la scrittura è limitata alle chiavi e ai campi previsti e vengono rilevate le modifiche concorrenti?
- Verifica: sono state controllate le righe interessate, i vincoli, i riferimenti e il comportamento di business? Se un controllo fallisce, sono state interrotte ulteriori scritture e attivata la procedura approvata?
- Tracciabilità: sono stati registrati la decisione, l’esecuzione, le convalide, le modifiche conservate e il risultato, senza includere dati sensibili non necessari?
Se non puoi rispondere affermativamente ai punti pertinenti, rimanda la scrittura in produzione. La scelta tra recupero selettivo, riconciliazione manuale e ripristino completo deve basarsi sull’entità del danno, sull’affidabilità delle evidenze, sull’impatto operativo e sulla concreta possibilità di recuperare uno stato coerente.
