10 ore per trasferire un sito.

[aex]

Un vero e proprio calvario.Pensavo di aver visto quasi tutto ma non pensavo di trovare venditori di pesce che si spacciano per tecnici.

E in un giorno ho cambiato due hoster.
Avevo problemi con il ripristino tramite akeeba e mi fa "ci penso io".
Lo lascio fare, saprà come si fa.

Dopo mezz'ora mi fa: Fatto. Devi solo cambiare qualche impostazione nel file configuration.

Poi mi accorgo che il DB era completamente vuoto.
Secondo me ha estratto il jpa.

Servirebbe un organismo che anche per le società di hosting attribuisca un grado di conoscenza da parte del supporto.
Perché 3/4 delle offerte sul web, hanno solo hw e niente di più.

[radu81]

Sinceramente non penso che un sistemista debba sapere come funziona akeeba e i suoi file di backup. Se un provider fornisce l'importazione lo fa tramite un file esportato dal proprio account cpanel. Alcuni si spingono oltre e lo fanno da un'esportazione del database e dei file ftp, anche se non è un loro compito.

Il mio suggerimento è quello di tenere diviso il fornitore del dominio e quello del spazio web, in questo caso si è più liberi di spostarsi da un fornitore all'altro riducendo al minimo i tempi di trasferimento.

Una settimana fa ho trasferito un sito da un provider all'altro e ho avuto meno di 10 minuti di "down", parlo di un sito con 1GB di database e 7-8 GB di file ftp. Con un hosting condiviso sarebbe impossibile, ma con una vps si apre un nuovo mondo.

[jeckodevelopment]

Premesso che le ore dipendono anche da altri fattori.... quando abbiamo migrato Joomla.it sulla nuova infrastruttura di hosting abbiamo seguito questa procedura:

• creato un clone (per gli amici backup)
• trasferito il sito (file e db) sulla nuova macchina
• modificato il puntamento sulla macchina locale al nuovo server (file "hosts" in Windows) in modo da potersi assicurare che il tutto funzionasse correttamente.
• Una volta terminate le verifiche ed attivato HTTPS, modificato il puntamento DNS del dominio alla nuova macchina
• Lasciata accesa anche l'altra macchina per le ore necessarie all'aggiornamento DNS.

Disservizio pari a 0.
Diverso è il discorso del forum che ha richiesto qualche ora in più.
E per ricollegarmi a quello che dice radu81, Joomla.it ha un DB che supera il GB.

[danielecr]

5. Lasciata accesa anche l'altra macchina per le ore necessarie all'aggiornamento DNS.Disservizio pari a 0.

Ma infatti...non vedo perchè puntare i dns verso il nuovo sito come primo step: questo è sicuramente il percorso corretto.Anche io ho cambiato datacenter con lo stesso hosting e allo stesso modo e disservizi pari a 0.Aggiungo che di solito c'è anche un dominio temporaneo, su cui si possono fare tutti i test.

[aex]

Quando un tecnico (o dicesi tale) estrae un jpa per conto suo e dice che ha ripristinato tutto, lasciando il database vuoto e insistendo per modificare le impostazioni sul configuration file.....


Beh, cascano le braccia.

[radu81]

Diverso è il discorso del forum che ha richiesto qualche ora in più.
E per ricollegarmi a quello che dice radu81, Joomla.it ha un DB che supera il GB.

il sito che ho trasferito era proprio un forum e non servono più di 10 minuti di "down" se il passaggio viene programmato prima.

Andiamo un po' off-topic, ma i passi che ho fatto sono:
- 1 giorno prima del trasferimento ho impostato i DNS (campo A) da 24 ore a 1 ora e prima di iniziare il lavoro li ho impostati a 5 minuti
- in quest'ora ho fatto tutti i backup necessari, configurato la nuova vps, ecc ecc
- ho copiato tutti i file dal vecchio VPS al nuovo VPS (ho verificato anche se l'ultimo allegato fosse già presente)
- ho importato una copia del database tanto per avere un forum funzionante e mostrare l'avviso di manutenzione sulla vps nuova
Da qui inizia il momento di "down", ma avevo tutto a portata di mano: pagina aperta dove cambiare i DNS, entrambi i file di configurazione aperti e modificati pronti da essere salvati, creato il nuovo db e scritti in un file di testo tutti i comandi necessari per l'importazione, ecc ecc
- messo il forum in manutenzione su entrambe le VPS (dal file di configurazione php)
- aggiornato i DNS (< 1 minuto)
- esportazione db e copia database da vps a vps (circa 3 minuti)
- importazione db da riga di comando ( circa 3-4 minuti)
- disattivata la modalità manutenzione sul forum "nuovo"
A questo punto il dominio puntava già al nuovo server e avevo già il forum online.  Qui mi sono accorto che mancava il certificato ssl e ho impiegato altri 3-4 minuti per configurarlo. Il tempo di down è stato di 10 minuti, ma in totale avevo impiegato 2 ore circa.

[danielecr]

Puntare i dns è comunque l'ultimo step: bisogna tenere conto che se anche imposti il ttl molto basso i dns devono propagarsi in tutto il mondo, i fattori sono molteplici, e questo richiede fino a 72 ore (nel caso proprio di sfiga); il ttl è nella cache, quindi se hanno un valore molto alto in cache tu puoi mettere anche un secondo, ma questo è ininfluente; comunque qualche ora ci va sicuramente.

[radu81]

Fino a qualche anno fa la propagazione DNS era lenta, negli ultimi anni vedo che è migliorata parecchio. Non sto negando ciò che hai scritto sopra, è tutto vero, comunque il forum è abbastanza attivo e una volta trasferito ho visto subito altri utenti collegati e nuovi messaggi pubblicati. Non so quanto sia preciso, ho usato questo tool per verificare la propagazione DNS https://www.whatsmydns.net/ e vedevo già il nuovo IP propagato.
Inoltre ho fatto tutto il lavoro dopo mezzanotte quando il sito è meno frequentato...

[danielecr]

Sicuramente le cose sono migliorate, bisogna tenere però in conto che i server dns sono molteplici: i dns di google per esempio si aggiornano subito, come quelli di open dns, pochi minuti (ttl permettendo), altri si aggiornano più lentamente. Ho giusto fatto recentemente un test di comparazione tra dns google e dns di telecom e questi ultimi si sono aggiornati solo dopo qualche ora. I tool online danno sicuramente una mano, e si ha un'idea globale di ciò che accade, soprattutto per vedere che non si sia combinata qualche cazzata nelle impostazioni, ma non contengono tutti i dns pubblici, che sono più di 15 mila; magari il poveretto che vive in una zona poco tecnologica se li vede aggiornati dopo qualche giorno. Poi ovviamente il tutto dipende anche dal target di utenza. Leggo che ci sono varie scuole di pensiero a riguardo, tra cui anche puntare i dns come primo step, quindi non è che sia sbagliato, ma da un punto di vista logico io lo farei come ultimo step.Questo perchè, se cambio subito i dns, e dopo 5 minuti google li aggiorna, io che ho impostato i dns di google vengo indirizzato al nuovo spazio, ma se non c'è alcun file sul nuovo spazio vedo solamente una pagina di cortesia; se poi per trasferire files e database impiego "più di qualche minuto", le cose si aggravano.
Al contrario, se ho già i files e il database piazzati, e ho tutti e due gli hosting attivi credo non avrei problemi di downtime, c'è chi punterà di qua e c'è chi punterà di là: a propagazione completata potrò quindi spegnere l'hosting vecchio.

[radu81]

Per la gestione dei dns uso Hurricane Electric Free DNS Management (dns.he.net)
In passato ho usato anche i DNS Linode, Ovh, CloudFlare però mi trovo bene con il servizio free offerto da HE, interfaccia semplice, ping basso e propagazione rapida.

[aex]

Puntare i dns è comunque l'ultimo step: bisogna tenere conto che se anche imposti il ttl molto basso i dns devono propagarsi in tutto il mondo, i fattori sono molteplici, e questo richiede fino a 72 ore (nel caso proprio di sfiga); il ttl è nella cache, quindi se hanno un valore molto alto in cache tu puoi mettere anche un secondo, ma questo è ininfluente; comunque qualche ora ci va sicuramente.

Come fanno ad essere l'ultimo step?
Se non cambi i dns non puoi accedere alla root del nuovo hosting, dove di solito io uso akeeba keekstart.
Io faccio tutto da remoto.

[danielecr]

Avere il dominio che punta al nuovo spazio non è l'unico modo per accedervi, come ho scritto sopra si può avere un dominio temporaneo.