Dopo la ricostruzione, Fliclic verifica nuovamente struttura, tipi di file, proprietari, permessi e Project ID degli inode. Confronta i database fisici e logici con il set TARGET, controlla che gli EXTRA siano assenti e verifica che processi e configurazioni condivise siano rimasti coerenti.
Prima della riapertura applica una barriera di persistenza sul filesystem, quindi imposta proprietario e permessi finali della radice pubblica e ne sincronizza i metadata. Soltanto dopo ripristina il vhost applicativo e finalizza gli stati del servizio e del backup.
La barriera riguarda il filesystem che ospita anche altri servizi e può produrre I/O condiviso. Non rende atomici filesystem, MySQL locale, database centrale e Apache; chiede invece al sistema operativo di persistere i dati ricostruiti prima di renderli nuovamente disponibili.
Il progetto ha misurato i colli di bottiglia del restore su uno scenario DEV specifico. Una prima implementazione dell'archivio compresso impiegava circa dodici minuti e venticinque secondi perché effettuava accessi ripetuti e non sequenziali. Lo streaming ha eliminato quella patologia.
Altri benchmark hanno mostrato circa cinquanta secondi spesi in migliaia di subprocess per verificare gli attributi di progetto e circa 12,8 secondi in sincronizzazioni per-file. La verifica diretta tramite filesystem e la barriera finale hanno ridotto questi costi. Nello scenario finale documentato, il restore TAR.GZ è stato riportato intorno a 16,36 secondi, con un artefatto di circa 49 MB rispetto a circa 149 MB non compressi.
Questi numeri appartengono a build, dati e macchina di test specifici. Dimostrano il metodo — misurare, isolare il collo di bottiglia, correggerlo e verificare gli effetti sugli altri tenant — non un tempo garantito per ogni restore.
Il backup corrente resta sullo stesso nodo e filesystem del servizio. Non protegge dalla perdita dell'intera VPS o del disco e non è un backup off-site.
I backup privi dello snapshot richiesto non sono ripristinabili automaticamente con il flusso fotografico. Il restore non deduce credenziali da WordPress o da valori correnti potenzialmente cambiati.
Non viene creato un backup automatico prima del restore. Non esiste un retry o resume automatico da qualsiasi checkpoint. Un crash può lasciare stati intermedi e richiede diagnosi; una finestra tra riapertura tecnica e aggiornamento centrale può perfino lasciare il sito servibile con stato ancora in esecuzione.
La versione PHP storica viene registrata, ma il runtime non viene cambiato automaticamente durante il ripristino. Questo evita di richiamare un workflow con effetti condivisi senza un motore tenant-safe, ma può richiedere una valutazione manuale di compatibilità dopo il restore.
Questi confini sono parte del contratto tecnico. Rendono chiaro quando Fliclic può ricostruire una fotografia e quando serve una strategia ulteriore.
