La progettazione e la configurazione corretta del processo di backup fanno la differenza tra un ripristino pulito e veloce e la perdita di dati con conseguente downtime prolungato del sito.
Questo vale per ogni genere di attivitá e lo avrai provato sulla tua pelle quando si è rotto l’hard disk del pc e non avevi una copia di sicurezza o l’ultima l’avevi fatta due anni fa ed hai perso interi giga di foto, musica, film e documenti.
Parlando nello specifico di Wordpress, dobbiamo considerare nel nostro backup:
• Il contenuto della cartella root, includendo il file di configurazione (la WordPress Core Installation)
• Temi e plugin utilizzati
• Immagini e file caricati durante l’utilizzo del sito
• File Javascript e file PHP, soprattutto se customizzati.
• Eventuali pagine statiche create al di fuori di Wordpress
• Il database
Sicuramente ti starai chiedendo se non fai prima a copiare l’intera cartella (nel nostro esempio /blog) per stare piú tranquillo e ripristinare in maniera veloce.
Scoprirai che non è cosí…
Comprendere il processo di backup
La risposta è no, perché se sei stato vittima di malware e di backdoor installate all’interno di file modificati in fase di attacco, non sempre riuscirai a debellarli per ripristinare tutto cosí velocemente.
Ripristinare tutto in massa non fará altro che rimettere i file infetti sul sito.
Se hai avuto la possibilitá di spostare il file di configurazione e la cartella wp-content al di fuori della cartella radice di wordpress li faresti fuori dal processo di backup.
Copiando tutto ti porteresti dietro anche una montagna di file di log che non servono, sprecando parte della banda messa a disposizione dell’hosting e spazio su disco a disposizione)
Quindi, per iniziare bene, individua gli elementi chiave ed assicurati di salvarli in un posto diverso da dove viene ospitato il sito.
Molti plugin che fanno i backup automatici salvano tutto all’interno della vostra zona di hosting.
Questo non è corretto ai fini del processo di backup, perché i dati vanno conservati fisicamente in un luogo differente di quello di origine.
Il database puó essere esportato manualmente (lo abbiamo giá fatto in altri post) tramite l’interfaccia di PhpMyAdmin.
Se vuoi avere una procedura automatica o il tuo fornitore di servizi all’interno del pannello di controllo dell’hosting ti permette di schedulare cron jobs (attivitá automatiche ripetute nel tempo) e salvarle in un posto diverso (sfruttando servizi come Dropbox, Google Drive o One Drive i piú famosi), o ti affidi ad un plugin che faccia il backup di quello che tu andrai ad indicare, lo compatti in un file zippato per risparmiare spazio e lo invii ad uno dei servizi citati poco fa.
Lo stesso vale se amministri un VPS. Creare uno script automatico che faccia il backup di MySQL e lo salvi in locale puó essere emozionante se non hai mai fatto utilizzo del linguaggio di scripting e vuoi iniziare, ma il backup sullo stesso server non è un backup sicuro, quindi assicurati di spostare con cadenza almeno settimanale il backup dal VPS al tuo PC o ad un servizio Cloud.
La cadenza del backup
Pianificare la cadenza del backup.
Questo è importante.
Ma è una risposta che devi darti da solo.
Ogni quanto aggiorni il tuo blog?
Se scrivi tutti i giorni dei grandi articoli (beato te) e li infiocchetti con immagini accattivanti vuol dire che il tuo database viene alimentato giornalmente e la cartella uploads in wp-content cresce sempre di piú.
In questo caso il backup dovrá essere giornaliero, o non sarai in grado di ripristinare il sito al cento per cento.
Nella peggiore delle ipotesi andresti a perdere solo l’articolo scritto oggi se il backup è girato prima della scrittura.
Quindi scegli la cadenza giornaliera, settimanale o mensile in base all’utilizzo che fai di Wordpress.
Ma avere un solo backup non basta. Per tua sicurezza tieni piú di copie salvate a disposizione, magari con la data inclusa nel titolo del backup, perché non puoi avere la certezza in caso di ripristino, della data del fault (al netto di attacchi pesanti, di utilizzo di strumenti come il WAF con consultazione dei log e via dicendo)
Avere più backup non basta, se non sono verificati.
Eh si, hai capito bene.
Sai quante persone ho consociuto che al momento del ripristino si sono accorte che mancava qualcosa (per loro dimenticanza, non per le procedure automatiche) ed hanno visto andare in fumo il loro lavoro?
La macchina virtuale che l’abbiamo fatta a fare allora? Puoi sempre pensare di creare una nuova istanza di Wordpress e testare il backup in ogni sua parte, ed avere così la certezza della sostanza della copia di sicurezza.
Nel processo di backup la verifica è uno dei punti cardine, altrimenti si parla di backup inconsistente.
Terminata la fase di ripristino in seguiro ad attacco bisogna sempre, sempre, sempre ricordarsi di cambiare le password di tutti gli utenti amministratori, perché molto probabilmente sono compromesse.
Un Backup va sempre verificato
Quanto vale un backup se non funziona? Meno di zero. Non è opinabile.
Quanto impatta un backup non funzionante nel nostro progetto? Molto, perché senza avere la possibilità di ripristinare in caso di errore o di attacco, abbiamo perso tutto.
Come facciamo a verificare se un backup di Wordpress è funzionante?
Installando il file di backup del database in un ambiente in locale, copiando le cartelle del nostro blog sempre in locale (per avere le immagini caricate negli articoli, i plugin ed i temi) ed effettuando delle modifiche all’interno del database e del file wp-config.
Nel database e nel file di configurazione sono scolpiti gli URL a cui fanno riferimento per il sito.
Abbiamo creato due macchine virtuali e possiamo instanziare una nuova cartella per una nuova installazione di Wordpress. La cartella in htdocs la chiamiamo testbackup, quindi l’URL che uitlizzeremo sarà http://localhost/testbackup
Se nell’utilizzo di tutti i giorni non vuoi utilizzare le macchine virtuali puoi fare ricorso ad uno strumento molto potente che ti permette di sviluppare in locale, MAMP (https://www.mamp.info/en/downloads/), disponibile per Windows ed OS X.
Collegati tramite PhpMyAdmin (http://localhost/phpMyAdmin) e tramite il tab importa carichiamo il file di backup del database.
La procedura dura qualche istante, subito dopo il db è presente nella colonna di sinistra.
La tabella del database che ci interessa è quella delle opzioni (wp_option di default, altrimenti il suffisso sarà quello che hai inserito in fase di hardening).
Le colonne che contengono i dati relativi all’indirizzo del blog sono siteurl e home.
PhpMyAdmin incorpora un editor SQL che ti permette di modificare il valore di una tabella. Clicca su Edit alla voce siteurl ed aprirai l’editor per modificarlo con http://localhost/testbackup
Con il database abbiamo finito, copiamo il backup delle cartelle di Wordpress e modifichiamo il file di configurazione per far girare il nostro sito in locale, dobbiamo dirgli che l’indirizzo del database è cambiato o non riuscirà a connettersi, perché tenterà di farlo puntando al nostro sito ufficiale.
Le voci da modificare sono nel file wp.config.php sono:
/** MySQL database username */
define('DB_USER', 'root'); //se utilizzi MAMP puoi usare l’utenza di root del db MySQL
/** MySQL database password */
define('DB_PASSWORD', 'root'); //se utilizzi MAMP la password di default è root
/** MySQL hostname */
define('DB_HOST', 'localhost:3306'); //Qui c’era l’indirizzo del database del tuo hosting, ora diventa localhost
Se hai rinominato la cartella wp-content dovrai modificare anche quella direttiva.
define ('WP_CONTENT_DIR', ABSPATH . 'special'); //se hai rinominato la cartella wp-content in special, altrimenti inserisci il nome che hai scelto
define ('WP_CONTENT_URL', 'http://localhost/testbackup/special'); //indirizzo nuovo della cartella special (ex wp-content)
Ora apri il browser che preferisci e digita http://localhost/testbackup
Bravo!
Il tuo backup funziona alla grande e con una certa soddisfazione starai guardando il tuo blog che gira in locale… Magari ora potrai utilizzare testbackup per scrivere prima articoli e pagine, vedere come rendono e poi portarle online, o magari sviluppare plugin custom ed avere il vantaggio di verificarne il funzionamento.
Se invece riscontri qualche problema verifica nei log di Apache cosa manca o cosa genera un errore e corri subito al riparo, perché in questo momento non hai un backup funzionale e saresti scoperto in caso di emergenza.
arulajeh.id Situs Berita Terbaru Dan Terbaik




Tambahkan Komentar