Questa pagina concentra i limiti che hanno conseguenze pratiche. Non è un elenco di difetti: è la base per scegliere lo strumento giusto, preparare una prova significativa e non attribuire a una funzione garanzie che non possiede.
Le versioni ammesse dipendono dal nodo e dalla policy dell'ambiente. La documentazione di una famiglia major.minor non garantisce:
Il cambio versione preserva il pool e riallinea i parametri gestiti, ma non esegue test funzionali dell'applicazione. Le versioni legacy disponibili nell'ambiente DEV servono a compatibilità e migrazione e possono non essere previste in altri ruoli.
La versione storica associata a un backup viene registrata come metadato. Il restore non cambia automaticamente il runtime corrente.
L'installazione e la riconfigurazione automatica riguardano WordPress nei workflow previsti. Temi, plugin, codice personalizzato e servizi esterni restano responsabilità applicativa.
La duplicazione WordPress aggiorna configurazione e riferimenti della copia. Il restore è invece CMS-agnostico: non riscrive credenziali, URL o contenuti. Lo stesso principio vale per altri CMS e applicazioni PHP.
Fliclic non promette oggi un importatore one-click universale. File e database possono essere caricati con gli strumenti disponibili, ma la compatibilità del progetto importato deve essere verificata.
Il restore fotografico richiede uno snapshot valido e gli artefatti completi associati. Sono supportati i formati di archivio riconosciuti dal reader corrente e gli snapshot della versione prevista, inclusi quelli compatibili senza il metadato PHP introdotto successivamente.
Non sono ripristinabili automaticamente:
Un archivio integro può comunque contenere SQL non eseguibile sul motore corrente. Il preflight non è un interprete completo del dump.
HOT non è atomico tra filesystem, database diversi e metadati. STOP riduce le nuove scritture HTTP ma non ferma ogni sorgente di modifica.
Per applicazioni con transazioni lunghe, code, cron, importazioni o scritture esterne, l'utente deve valutare se arrestare manualmente tali attività o usare una strategia specifica prima del backup.
Il restore sostituisce l'albero pubblico e il set di database attivi con la fotografia selezionata. File e database creati dopo il backup vengono eliminati se non appartengono allo snapshot.
Non viene eseguito:
Prima di confermare, creare una copia separata se la situazione corrente deve essere conservata.
Project Quota limita spazio e inode dell'albero dell'ambiente, inclusi i backup. Non include automaticamente datadir MySQL, CPU, RAM, processi e aree temporanee globali.
Una riduzione di quota sotto l'uso corrente non elimina dati, ma può bloccare nuove allocazioni. Il backup usa spazio della stessa quota e un'area di lavoro incompleta può continuare a consumarlo finché non viene gestita.
Le metriche di uso possono essere periodiche e non coincidono sempre con l'enforcement kernel. La dimensione apparente dei file, i blocchi allocati e lo spazio database sono misure differenti.
Il sistema usa stati, claim e lock specifici, ma non dispone di un lock universale per ambiente. Una corretta interfaccia deve impedire azioni incompatibili mentre un workflow è in corso.
Uno stato stale non deve essere azzerato automaticamente. Prima di intervenire occorre verificare processi, configurazioni, filesystem e database: il processo principale può essere terminato mentre un figlio continua, oppure una fase tecnica può essere conclusa prima della finalizzazione centrale.
Utenti, gruppi, pool PHP-FPM, socket e database sono separati per ambiente. Kernel, filesystem, Apache e master PHP-FPM restano componenti condivisi.
Il restore evita reload PHP-FPM e usa controllo mirato dei processi. Altri workflow conservano reload condivisi. Una sincronizzazione del filesystem o un reload graceful di Apache può produrre I/O o lavoro comune pur senza equivalere a un riavvio globale.
Gli artefatti di backup risiedono nello stesso perimetro storage del servizio. Proteggono da errori o modifiche recuperabili con il workflow, ma non dalla perdita dell'intero nodo o filesystem.
Non sono dichiarati SLA, RPO, RTO, replica geografica o retention garantita.
La presenza di una funzione nel motore non garantisce che sia disponibile a ogni account o in ogni fase del servizio.
Canali e tempi di assistenza non vanno dedotti dai contatti generali. In caso di errore, usare il canale pubblicato nella pagina “Segnala un problema”.
Il progetto non include oggi un installer pubblico, un updater autonomo completo o una guida di amministrazione per trasformare un server generico in un nodo Fliclic. Le pagine Server spiegano architettura e metodo, non concedono una procedura operativa.
