Il backup raccoglie il contenuto pubblico e i database attivi fotografati all'avvio del flusso. I file vengono archiviati in formato compresso; i database vengono esportati separatamente; uno snapshot protetto conserva identità, metadati, hash e credenziali storiche necessarie a ricostruire la fotografia.
Sono previsti due modi:
HOT è più comodo, ma file e database possono cambiare durante l'operazione. STOP riduce questo rischio sul canale web, ma non ferma automaticamente SFTP, processi già avviati o ogni possibile scrittura esterna. La scelta dipende dal tipo di progetto e dall'importanza della coerenza applicativa.
I backup correnti sono memorizzati nello spazio del servizio e partecipano alla sua quota. Non sono, da soli, una protezione fuori nodo contro la perdita dell'intero server o filesystem.
Il ripristino compatibile ricostruisce i file e i database descritti dal backup. Prima della fase distruttiva esegue un preflight su identità, artefatti, checksum, struttura dell'archivio, mapping dei database, spazio e condizioni operative. Se una condizione necessaria non è verificabile, il flusso si arresta.
Una volta iniziata la ricostruzione, i file correnti vengono rimossi e sostituiti dalla fotografia; i database attivi creati dopo il backup e non presenti nello snapshot vengono eliminati; i database storici del backup vengono ricreati con le credenziali fotografate. Non è un merge e non conserva automaticamente ciò che è stato aggiunto dopo.
Il restore non crea un backup preventivo della situazione corrente e non cambia automaticamente la versione PHP per riportarla a quella storica, anche se la versione associata al backup viene conservata come metadato. Per questo l'azione richiede una decisione consapevole.
