finite le foto, sono passato a configurare WordPress. Mi ero fastto un backup del vecchio sito che è quello su cui stai leggendo l’articolo) e volevo ripristinarlo.

Il plugin utilizzato è fenomenale ! Salva tutto : All-in-One WP Migration and Backup

Dopo aver eseguito la configurazione del db (come per piwigo) ho detto al plgin di caricare il file di backup, ma la dimensione del file superava abbondantemente il limite di caricamento di un file via php.

Dopo una breve ricerca, ho trovato la soluzione (solo per il container wp1, ma fa scuola): inserire dei parametri “aggiuntivi” al container

      - ./php/uploads.ini:/usr/local/etc/php/conf.d/uploads.ini

il cui contenuto è

upload_max_filesize = 512M
post_max_size = 512M
memory_limit = 512M
max_execution_time = 300
max_input_time = 300

per far ricaricare la configurazione basta un

per verificare

docker restart wordpress1

docker exec -it wordpress1 php -i | grep upload_max_filesize
docker exec -it wordpress1 php -i | grep post_max_size

il cui output è

upload_max_filesize => 512M => 512M
post_max_size => 512M => 512M

in questo modo si risparmiano i 67$ per caricare il file e rendiamo molto più “smart” il nostro sistema. Nulla e nessuno ci vieta di eliminarlo in quanto serve solo per il caricamento del backup.

In definitiva, anche se abbiamo eseguito una nuova configurazione di WP., i dati di accesso sono i “veccji”.

Bisogna abilitare nel file di nginx il primo wp, generare il certificato ed infine abilitare il passaggio da http a https del sito con operazioni già viste precedentemente.

Tutto bello finora, ma se dovessi fare io qualche errore oppure voglio fare il restore di qualcosa. Si, è vero i dati non sono modificati in maniera fobica, ma un backup ?

Contabo per 0,75€ al mese (mi sembra) ti offre il backup, ma meglio prevenire ed allora cerco un modo.

Lo script utilizzato per il backup è

#!/bin/bash
BACKUP_DIR="/opt/docker/backups/$(date +%F)"
mkdir -p "$BACKUP_DIR"

# DB dump
docker exec mariadb sh -c \
  "mariadb-dump --all-databases -u root -p'$MYSQL_ROOT_PASSWORD' --single-transaction" \
  > "$BACKUP_DIR/db_$(date +%F).sql"
gzip "$BACKUP_DIR/db_$(date +%F).sql"

# WordPress and Piwigo files
tar czf "$BACKUP_DIR/wp1_files.tar.gz" /opt/docker/wp1/html
tar czf "$BACKUP_DIR/wp2_files.tar.gz" /opt/docker/wp2/html
tar czf "$BACKUP_DIR/wp3_files.tar.gz" /opt/docker/wp3/html
tar czf "$BACKUP_DIR/piwigo_gallery.tar.gz" /opt/docker/piwigo/gallery

echo "Backup completato in $BACKUP_DIR"

dove viene eseguito il backup di tutto il db e la parte

A casa ho un disco esterno, ma il server si trova (penso) in Germania quindi dobbiamo usare la rete per raggiungere il server: wireguard.

sia sul server che sul mio pc lancio un

sudo apt -y update
sudo apt -y install wireguard

Una volta installato, bisogna generare le chiavi per il saltaggio remoto

wg genkey | tee private.key | wg pubkey > public.key

sul server contabo , bisogna generare il file /etc/wireguard/wg0.conf

[Interface]
Address = 10.10.10.1/24
ListenPort = 51820
PrivateKey = <PRIVATE_KEY_CONTABO>

[Peer]
PublicKey = <PUBLIC_KEY_MINI_CED>
AllowedIPs = 10.10.10.2/32

e sul cliente remoto sempre il file /etc/wireguard/wg0.conf ma con il contenuto

[Interface]
Address = 10.10.10.2/24
PrivateKey = <PRIVATE_KEY_MINI_CED>

[Peer]
PublicKey = <PUBLIC_KEY_CONTABO>
Endpoint = IP_CONTABO:51820
AllowedIPs = 10.10.10.1/32
PersistentKeepalive = 25

abilitare il servizio su entrambe le macchine

systemctl enable wg-quick@wg0
systemctl start wg-quick@wg0

e fare un banale test dal server Contabo

ping 10.10.10.2

ma il ping non funziona (quasi sicuramente) in quanto la porta udp 51820 non è abilitata a passare. Bisogna eseguire

sudo ufw allow 51820/udp

e tutto andrà a posto.

Abilitare l’accesso SENZA password per ssh dal server Contabo:

ssh-keygen
ssh-copy-id backup@10.10.10.2

naturalmente l’utente sulla macchina remota

A questo punto lo script di backup diventa

#!/bin/bash
set -e

DATE=$(date +%G-W%V)
BACKUP_DIR="/opt/backup/$DATE"
REMOTE="backup@10.10.10.2:/data/contabo"

mkdir -p "$BACKUP_DIR"

echo "▶ DB dump"
docker exec mariadb \
  sh -c 'mariadb-dump --all-databases -u root -p"$MYSQL_ROOT_PASSWORD" --single-transaction' \
  | gzip > "$BACKUP_DIR/db.sql.gz"

echo "▶ Files"
tar czf "$BACKUP_DIR/wp1.tar.gz" /opt/docker/wp1/html/wp-content
tar czf "$BACKUP_DIR/wp2.tar.gz" /opt/docker/wp2/html/wp-content
tar czf "$BACKUP_DIR/piwigo.tar.gz" /opt/docker/piwigo/gallery

echo "▶ Sync verso mini-CED"
rsync -avz --delete "$BACKUP_DIR/" "$REMOTE/$DATE/"

echo "✔ Backup completato"

aggiungere nel crontab

0 3 * * 0 /opt/backup/weekly_backup.sh >> /var/log/backup.log 2>&1

e possiamo anche aggiungere nello script

find /opt/backup -maxdepth 1 -type d -mtime +56 -exec rm -rf {} \;

per la rotazione dei backup.

Per il restore dei dati:

rsync -av backup@10.10.10.2:/data/contabo/2026-W05/ /restore/
gunzip db.sql.gz
docker exec -i mariadb mysql < db.sql

a pensarci bene, non mi piace la soluzione: posso accedere dalla periferia verso il computer..

Facciamo che è il mio computer ad accedere il server su Contabo.

ssh-copy-id admin@10.10.10.1

e poi nel crontab del mio pc

0 4 * * 0 /usr/bin/rsync  -e "ssh -p 9999" -avzP admin@10.20.0.1:backup/ data/contabo/