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.

 

Tag Technorati: ,

8 commenti/trackback a “A proposito di backup”

  1. iacchi scrive:

    Molto utile, grazie flod.

  2. marco scrive:

    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.

  3. capemaster scrive:

    Lettere a ramengo anche con i tuoi suggerimenti.
    Devo verificare il charset probabilmente.

  4. Diego Russo scrive:

    Ed è esattamente quello che ho fatto io, paro paro 🙂

  5. flod scrive:

    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).

  6. Giuliano scrive:

    Se tu avessi recitato un lungo scioglilingua in bresciano stretto sono sicuro che mi sarebbe stato meno oscuro. 😉

  7. Aldo scrive:

    È 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!

  8. capemaster scrive:

    Controllo, ma credo tu abbia ragione.

Trackback e pingback

  1. Nessun trackback o pingback disponibile per questo articolo

Non è possibile inserire nuovi commenti. I commenti vengono disattivati automaticamente dopo 60 giorni.