Come installare MySQL su un VPS: utenti, accesso remoto sicuro, meno RAM e backup

Installare MySQL richiede un comando. Il grosso del lavoro viene dopo: un utente per l'applicazione, un modo per raggiungere il database dal tuo computer senza esporre la porta 3306 su internet, impostazioni di memoria per un server piccolo e backup che girano senza di te. Questa guida copre tutte e quattro le cose su Ubuntu 24.04. Ogni passo è stato eseguito sulla nostra immagine Ubuntu 24.04, e i numeri qui sotto vengono da quel server.

Esegui i comandi con un utente che abbia sudo. La guida alla configurazione di Ubuntu ne crea uno.

1. Installa

sudo apt update
sudo apt install -y mysql-server
mysql --version

Sul nostro server l'installazione ha richiesto 51 secondi e ci ha dato MySQL 8.0.46. Parte subito, riparte a ogni avvio e ascolta solo sul server stesso: 127.0.0.1:3306 per le connessioni normali e 127.0.0.1:33060 per il protocollo X, più recente. Dall'esterno non si raggiunge ancora nulla.

2. Crea un database e un utente

Su Ubuntu l'account root di MySQL usa l'autenticazione tramite socket, quindi sudo mysql ti fa entrare senza password. Crea un database e un utente per la tua applicazione:

sudo mysql

CREATE DATABASE app CHARACTER SET utf8mb4;
CREATE USER 'app'@'localhost' IDENTIFIED BY 'a-long-random-password';
GRANT ALL PRIVILEGES ON app.* TO 'app'@'localhost';
EXIT;

Provalo nel modo in cui si collegherà l'applicazione:

mysql -u app -p app -e "SELECT CURRENT_USER();"

Dovrebbe stampare app@localhost. Una password sbagliata riceve ERROR 1045 (28000): Access denied for user 'app'@'localhost'. L'utente può fare tutto dentro app e niente fuori.

3. Collegati dal tuo computer: tunnel SSH

Per usare un client desktop come DBeaver, MySQL Workbench o la riga di comando mysql sulla tua macchina, non aprire nessuna porta. Inoltrane una tramite SSH:

ssh -L 3307:127.0.0.1:3306 deploy@YOUR.SERVER.IP

Su un piano NAT aggiungi -p e la porta SSH personale del pannello. Finché quella finestra resta aperta, punta il client sull'host 127.0.0.1, porta 3307, utente app. Sul lato locale abbiamo usato 3307 per non andare in conflitto con un MySQL che potresti avere sul tuo computer. Nel nostro test il server ha risposto subito attraverso il tunnel, mentre una connessione diretta al suo indirizzo sulla 3306 è stata rifiutata.

4. Accesso diretto per un altro server

A volte l'applicazione gira su un secondo server e deve collegarsi direttamente. Per questo il database ha bisogno di un piano con IPv4 propria, perché un piano NAT inoltra solo la tua porta SSH. Tre modifiche, tutte limitate all'indirizzo del server dell'applicazione (qui 203.0.113.20):

sudo sed -i 's/^bind-address.*/bind-address = 0.0.0.0/' /etc/mysql/mysql.conf.d/mysqld.cnf
sudo systemctl restart mysql
sudo ufw allow from 203.0.113.20 to any port 3306 proto tcp

CREATE USER 'app'@'203.0.113.20' IDENTIFIED BY 'a-long-random-password';
GRANT ALL PRIVILEGES ON app.* TO 'app'@'203.0.113.20';

Se ufw non è ancora attivo, consenti prima SSH (sudo ufw allow OpenSSH) e poi esegui sudo ufw enable. La guida a ufw ha i dettagli.

Abbiamo verificato le due serrature separatamente. Con la regola del firewall ma senza un utente MySQL corrispondente, il server ha rifiutato con error 1130: Host '…' is not allowed to connect to this MySQL server. Con l'utente aggiunto, la connessione è passata. Senza la regola del firewall, la connessione è semplicemente andata in timeout. Qualsiasi altro indirizzo su internet ottiene lo stesso timeout.

5. Usa meno RAM

A riposo, senza dati propri, MySQL 8.0 usava 383 MB sul nostro server. Gran parte è il Performance Schema, una funzione di diagnostica che riserva memoria in anticipo. Su un VPS piccolo disattivalo e imposta tu la dimensione della cache principale:

sudo tee /etc/mysql/mysql.conf.d/zz-small-vps.cnf >/dev/null <<'EOF'
[mysqld]
performance_schema = OFF
innodb_buffer_pool_size = 256M
max_connections = 50
EOF
sudo systemctl restart mysql
ps -o rss= -C mysqld

Dopo il riavvio usava 165 MB. Il buffer pool tiene in cache dati e indici, e 256 MB vanno bene per un server da 2 GB che esegue anche l'applicazione. Aumentalo se il database è la cosa principale sul server e ha superato la dimensione della cache. max_connections = 50 basta e avanza per un'applicazione con un pool di connessioni. Perdi le statistiche di performance_schema. Riattivalo se un giorno devi analizzare a fondo le query lente.

6. Backup notturni

mysqldump --single-transaction fa una copia coerente delle tabelle InnoDB senza bloccare l'applicazione. Mettilo in un piccolo script:

sudo tee /usr/local/bin/mysql-backup >/dev/null <<'EOF'
#!/bin/bash
set -euo pipefail
umask 077
mkdir -p /var/backups/mysql
mysqldump --single-transaction --routines --triggers app | gzip > /var/backups/mysql/app-$(date +%F).sql.gz
find /var/backups/mysql -name 'app-*.sql.gz' -mtime +14 -delete
EOF
sudo chmod 755 /usr/local/bin/mysql-backup
echo '0 3 * * * root /usr/local/bin/mysql-backup' | sudo tee /etc/cron.d/mysql-backup
sudo /usr/local/bin/mysql-backup && sudo ls -l /var/backups/mysql

Ogni riga ha il suo motivo:

• umask 077 rende il dump leggibile solo da root (-rw-------), perché contiene tutti i tuoi dati.
• pipefail fa fallire l'intero script se fallisce mysqldump. Senza, gzip scriverebbe un archivio minuscolo e vuoto e direbbe che è andato tutto bene. Abbiamo rotto il comando apposta e lo script è uscito con codice 2, come deve.
• find … -mtime +14 -delete conserva due settimane di copie.
• Lo script gira come root, quindi mysqldump accede tramite il socket e nessuna password resta in un file.

Un backup mai ripristinato non conta ancora. Ripristinalo in un database temporaneo e guarda i dati:

sudo mysql -e "CREATE DATABASE app_restore"
gunzip -c /var/backups/mysql/app-2026-10-25.sql.gz | sudo mysql app_restore
sudo mysql -e "SHOW TABLES FROM app_restore"
sudo mysql -e "DROP DATABASE app_restore"

Nel nostro test la tabella ripristinata aveva le stesse righe dell'originale. Le copie sullo stesso disco non ti proteggono se perdi il server, quindi portale ogni tanto su un'altra macchina con scp o restic. Managed Backups aggiunge in più punti di ripristino giornalieri dell'intero server.

Quale piano

Micro (2 vCPU, 2 GB, 25 GB, $5/mese) regge MySQL regolato come sopra più un'applicazione web. Se il database stesso supera qualche gigabyte, Small con 4 GB e 35 GB a $8/mese ti permette di dare 1 GB o più al buffer pool. Sono entrambi piani NAT, e il tunnel SSH del passo 3 funziona su di essi. Il passo 4 richiede una IPv4 propria: Micro-IP costa $10/mese.

Preferisci PostgreSQL? La guida a PostgreSQL segue lo stesso schema. Tutti i piani sono in VPS, e il pagamento è in USDT, USDC o ETH su Base, Ethereum o Polygon.