A proposito di backup
17 Marzo 2011
Come direbbe Barney Stinson, la prima regola del buon backup è “Prova il tuo backup!”. In altre parole, non saprai mai quanto è buono il tuo backup se non provi a farci un ripristino.
Qualche tempo fa ho iniziato a installare sui siti basati su WordPress il plugin wp-dbmanager: rispetto ai classici plugin che si occupano del backup di mySql, questo offriva una serie di optional interessanti (ad esempio l’ottimizzazione programmata del database e la possibilità di eseguire query). Cosa potrà mai andare storto nel fare un banale dump di un database?
Oggi dovevo provare delle modifiche sul tema di un sito, per cui ho recuperato dalla mail l’ultimo backup e ho cercato di ripristinarlo in locale:
- Tentativo #1: ripristina da phpMyAdmin, lettere accentate a ramengo.
- Tentativo #2: prova ad aprire il file .sql in TextMate, il programma si addormenta sistematicamente dopo poche righe (e TextMate non rientra certo nella categoria dei software instabili). Con “nano” o “tail” si riesce ad aprire il file, a quanto pare crea delle righe interminabili di testo.
- Tentativo #3: prova l’importazione da riga di comando forzando il charset UTF-8, lettere accentate sempre a ramengo.
- Tentativo #4: cerca sul forum di supporto del plugin o su Google, apparentemente nessuno ha questo problema. Il fatto che questo si verifichi con backup provenienti da Aruba, DreamHost e da un server dedicato mi fa pensare che il problema non sia dalla mia parte.
- Tentativo #5: butta via il plugin e installa wp-db-backup, tutto liscio al primo colpo (e nessun problema aprendo il file con TextMate).
Morale della favola: verificate sempre i vostri backup.
Visto che negli ultimi due mesi ho perso svariate ore su queste cose, qualche appunto in ordine sparso (che l’età avanza).
Se siete su DreamHost, il sistema di backup di database e siti funziona molto bene (ancora una volta, parlo per esperienza diretta). Questo non vuol dire che non dobbiate garantire l’incolumità dei vostri dati con soluzioni di backup alternative. Ad esempio potete crearvi dei batch shell ed eseguirli tramite il pannello di controllo (sezione Goodies) o crontab. La sintassi per fare il backup di un database è
mysqldump NOME_DATABASE > dumpdatabase.sql -u UTENTE -h HOST -pPASSWORD
La sintassi per il ripristino
mysql -u UTENTE -h HOST -pPASSWORD NOME_DATABASE < dumpdatabase.sql
Se dovete utilizzare in locale il backup del database di un sito, un modo rapido per correggere i riferimenti può essere questo (non è probabilmente la soluzione più sicura o elegante, ma funziona).
cat dumpdatabase.sql | sed 's|www.esempio.it|localhost/esempio|g' > dumpdatabase_locale.sql
Nello specifico tutte le occorrenze di “www.esempio.it” nel file dumpdatabase.sql vengono sostituite con “localhost/esempio” e salvate in dumpdatabase_locale.sql, risolvendo il problema dei parametri in wp_options ma anche di eventuali link all’interno dei post.
8 commenti/trackback a “A proposito di backup”
Trackback e pingback
- Nessun trackback o pingback disponibile per questo articolo
Non è possibile inserire nuovi commenti. I commenti vengono disattivati automaticamente dopo 60 giorni.
17 Marzo 2011 alle 19:07
Molto utile, grazie flod.
17 Marzo 2011 alle 19:09
il problema con phpmyadmin è 9 volte su 10 la collation di default, per il resto, wp-db-backup lo uso da quando esiste, ed ha sempre funzionato benissimo. mai neanche cercata un’alternativa, al punto che su wp i cronjob li uso solo per i file.
17 Marzo 2011 alle 20:11
Lettere a ramengo anche con i tuoi suggerimenti.
Devo verificare il charset probabilmente.
18 Marzo 2011 alle 00:46
Ed è esattamente quello che ho fatto io, paro paro 🙂
18 Marzo 2011 alle 08:46
Ok, per la serie quando mi ostino (grazie a Marco per avermi messo la pulce nell’orecchio).
Potrei scrivere una cavolata (non sarebbe la prima) ma una volta le tabelle venivano create con la collation di default, a partire dalle 2.2 vengono create con UTF-8 (parametro DB_CHARSET in wp-config.php).
Dopo essermi ricordato di questo, ho fatto una prova e rimosso quella riga da wp-config.php (in locale parto sempre dall’ultima versione pulita di WordPress): risultato, il dump di wp-db-backup si vede sbagliato, quello di wp-db-manager si vede correttamente (@capemaster forse è questo il tuo problema?). A questo preferisco comunque wp-db-backup.
La differenza nel dump sta nel fatto che wp-db-manager fa effettivamente un dump appoggiandosi all’eseguibile mysqldump, mentre wp-db-backup fa il backup tramite php. Il file con righe interminabili è generato da mysqldump (provato da terminale), l’unica maniera per evitarlo è aggiungere il parametro –skip-extended-insert o elaborare il file generato con sed (il file compresso è praticamente uguale, il file .sql nel mio caso è lievitato da 1.4MB a 5.4MB).
18 Marzo 2011 alle 17:00
Se tu avessi recitato un lungo scioglilingua in bresciano stretto sono sicuro che mi sarebbe stato meno oscuro. 😉
19 Marzo 2011 alle 17:41
È da qualche anno che sono passato a wp-db-backup, visto che wp-dbmanager a un certo punto aveva cominciato a crearmi archivi vuoti. Da quando lo uso, puntualmente ricevo archivi corretti e, per restare in tema col post, funzionanti.
Ciao!
21 Marzo 2011 alle 14:30
Controllo, ma credo tu abbia ragione.