Open Your Eyes, Open Your Mind

Backup per webapp

Backup per webapp: copertina

Come creare una copia di sicurezza database compreso in ambiente LAMP\LEMP?

Ancora oggi sono molto diffuse applicazioni web che girano in ambiente LAMP (Linux, Apache, MySQL, Perl) o LEMP (Linux, Enginx, MySQL, Perl) come, ad esempio, WordPress, Joomla, Drupal, NextCloud, ecc...
Vediamo come fare un backup procedendo a mano e come procedere per un ripristino.
La tipologia di ambiente permette di ospitare le applicazioni su server privati (fisici o virtuali) o di farli girare su web hosting a cui, spesso, viene dato anche un accesso ssh.

Ambiente

Prima di procedere vediamo la configurazione del nostro server:

  • directory root:: /srv/www/example.com
  • directory del server:
    html
    data
    conf
    log
  • database:
    Tipo: MariaDB
    Nome del Database: exampleWebApp1

Questa configurazione è caratteristica in molti server. Utile da sapere:

  • html: contiene i file PHP delle nostre webapp
  • data: contiene i file caricati nelle webapp (es. i file caricati in NextCloud)
  • conf: contiene eventuali configurazioni aggiuntive custom per Apache o Enginx.

Per MariaDB l'utente che usiamo per il collegamento SSH, tramite sudo, ci permette di avere i privilegi di root.

Per il nostro backup completo ci serve:

  • copiare tutti i file contenuti in html, data e conf
  • il database exampleWebApp1 come stringhe SQL.

MySQL, MariaDB o PostgreSQL?

Storicamente le soluzioni LAMP usano MySQL. MariaDB nasce come spin-off di MySQL. Inizialmente identico a MariaDB si sta diversificando sempre di più anche se continua a restare equivalente a MySQL. I comandi sono diversi (es.: mysql vs mariadb, mysql-dump vs mariadb-dump), ma con poca differenza si passa dall'uno all'altro.
Diverse webapp hanno scelto PostgreSQL come database. Diverse supportano nativamente MySQL, MariaDB e PostgreSQL.
PostgreSQL è molto diverso dagli altri due. Se è più semplice il backup ed il restore è anche una procedura completamente diversa.
In questa guida non lo tratteremo.

Backup

Passiamo all'azione:

  • tramite un collegamento SSH apriamo un terminale sul nostro webserver
  • creiamo il backup delle directory html, data e conf

tar cfz log/20260816_example.com-html.tgz html
tar cfz log/20260816_example.com-data.tgz data
tar cfz log/20260816_example.com-conf.tgz conf

NB 1: "20260816" è la data del momento del backup scritta nel formato YYYYMMDD
NB 2: i backup li mettiamo temporaneamente nella directory log perché normalmente la root non è scrivibile

  • creiamo il backup del database

sudo maiadb-dump -u root --databases exampleWebApp1 --result-file=./log/20260816_example.com-exampleWebApp1.sql

  • creiamo un file unico di backup:

cd log
tar cfz 20260816_example.com.tgz 20260816_example.com-html.tgz 20260816_example.com-data.tgz 20260816_example.com-conf.tgz 20260816_example.com-exampleWebApp1.sql
rm 20260816_example.com-html.tgz 20260816_example.com-data.tgz 20260816_example.com-conf.tgz 20260816_example.com-exampleWebApp1.sql

A questo punto abbiamo il nostro backup completato da spostare su un device locale (un disco, un NAS, il nostro PC), magari con SFTP o altro strumento e da rimuovere sul server in modo da contenere il consumo di spazio.

Restore

Il ripristino di un backup è distruttivo, ovvero:

  • riporta la webapp allo stato del momento del backup
  • ogni aggiornamento o cambio successivo verrà distrutto.

NB: durante il restore per la durata dell'operazione la webapp non sarà funzionante. Potrebbe essere buono creare una pagina di cortesia del tipo "Aggiornamento in corso" per gli utenti.

Passiamo all'azione:

  • Copiamo il nostro file di backup "20260816_example.com.tgz" sul server dentro òa directory log
  • tramite un collegamento SSH apriamo un terminale sul nostro webserver
  • estraiamo il backup

cd log
tar xfz 20260816_example.com.tgz
rm 20260816_example.com.tgz

  • svuotiamo le directory dai vecchi file

rm -R ../html/*
rm -R ../data/*
rm -R ../conf/*

  • ripristiniamo i backup

tar xfz 20260816_example.com-html.tgz -C ../
tar xfz 20260816_example.com-data.tgz -C ../
tar xfz 20260816_example.com-conf.tgz -C ../

  • ripristianiamo anche il backup del database

sudo mariadb < 20260816_example.com-exampleWebApp1.sql

  • rimuoviamo i backup

rm 20260816_example.com-html.tgz 20260816_example.com-data.tgz 20260816_example.com-conf.tgz 20260816_example.com-exampleWebApp1.sql

Conclusione

Il metodo di backup qui presentato è stato illustrato nella sua forma base.
Con una piccola integrazione, magari inserita in uno script controllato da un cron, permette di backuppare più webapp e più siti ospitati sul nostro server. Al rovescio possiamo focalizzarlo per salvare una sola webapp ed un solo database.
Facendo un backup integrale permette un ripristino certo, veloce con l'incomodo che dobbiamo ricordarci i comandi.
Con alcune webapp è una metodologia che né permette anche la migrazione da un server ad un altro.
Infine questa procedura old style può essere la base per backup di ambienti diversi, più moderni e complessi, come soluzioni NodeJS, Rust, ecc... o per porzioni della nostra workstation Linux, BSD o anche Mac.