Il restore è distruttivo, quindi la regola centrale è semplice: validare prima di cancellare.
Prima di intervenire sui dati correnti, Fliclic controlla:
Se uno di questi controlli essenziali fallisce, file e database correnti non vengono distrutti. L'errore resta associato al servizio e al backup per la diagnosi.
Il preflight non può simulare ogni statement SQL o prevedere esattamente il futuro layout del database. Un dump integro può contenere elementi incompatibili con il motore corrente; una stima di spazio può non rappresentare ogni picco di importazione. Questi errori possono emergere soltanto dopo l'inizio e non vengono nascosti.
Dopo il preflight, il restore isola l'ambiente. La radice pubblica diventa non accessibile al normale tenant e al web; il vhost applicativo viene sostituito con una pagina tecnica; i processi preesistenti riconducibili all'ambiente vengono identificati e terminati in modo mirato.
Il pool, il socket e il master PHP-FPM condiviso restano invariati. Questa scelta evita un reload globale della versione PHP durante il restore. La correzione è stata motivata da un test in cui un altro tenant aveva mostrato una risposta HTTP 503 durante il reload; nella prova di regressione successiva, la rimozione del reload e il controllo mirato hanno mantenuto risposte corrette sul secondo ambiente.
Apache continua a ricevere un reload graceful per attivare e rimuovere il vhost tecnico. La garanzia va quindi formulata con precisione: il restore evita il reload globale PHP-FPM che aveva prodotto l'effetto osservato, ma non esegue “zero operazioni condivise” in senso assoluto.
I database descritti nello snapshot sono i TARGET della fotografia. Il restore richiede che ciascuno corrisponda alla stessa riga storica già conosciuta dal controllo centrale; non inventa nuove identità per adattarsi al backup.
Un database storico eliminato dopo il backup può essere ricreato. Una password cambiata nel frattempo viene riallineata al valore fotografato, perché file e database devono tornare alla stessa relazione storica.
I database attivi creati dopo il backup e non presenti nella fotografia sono EXTRA. Vengono eliminati all'interno del restore, con le transizioni e le verifiche previste, prima che il lavoro venga dichiarato concluso. Questa è la differenza tra un vero ripristino fotografico e un import che lascia accumulare dati successivi.
Creazione, eliminazione, importazione e aggiornamento dello stato non sono una transazione SQL unica. Se un import fallisce dopo la rimozione di alcuni database, il risultato può essere parziale e l'ambiente resta in errore e isolato per la gestione tecnica.
La directory pubblica corrente non riceve un semplice overwrite. Tutti i suoi discendenti vengono rimossi in modo confinato; la radice viene mantenuta per preservare identità, riferimenti e attributi di progetto; i membri dell'archivio vengono poi estratti in streaming.
La policy dell'archivio rifiuta percorsi assoluti, attraversamenti verso directory superiori, hard link e file speciali. I symlink sono ammessi soltanto se relativi e confinati logicamente nell'albero. Proprietari e permessi salvati nell'archivio non vengono considerati autorevoli: al termine, la policy corrente dell'ambiente normalizza i metadata.
Il restore non esegue ricerca e sostituzione di dominio, non modifica configurazioni WordPress e non interpreta file applicativi. Ciò che non era presente nel backup scompare; ciò che era presente viene ripristinato compatibilmente con le regole di sicurezza dell'infrastruttura.
