DEV Community: minnogit

Come estrarre una singola tabella da un file dump MySQL

minnogit — Tue, 19 May 2026 09:08:59 +0000

Ti è mai capitato di dover ripristinare una sola tabella ma di avere a disposizione solo un file dump .sql gigante dell'intero database?

Invece di perdere tempo cercando di aprire un file da svariati gigabyte con un editor di testo, o peggio, importare tutto il database su un server locale solo per recuperare poche righe, c'è un trucco da riga di comando velocissimo che sfrutta sed:

sed -n -e '/DROP TABLE.*`nome_tabella`/,/UNLOCK TABLES/p' dump_completo.sql > backup_singola_tabella.sql

Otterrai un nuovo file chiamato backup_singola_tabella.sql contenente esclusivamente la struttura e i dati della tabella che ti interessa.

🔍 Come funziona?

-n: Dice a sed di non stampare nulla di default (evita di intasare il terminale).
-e: Specifica il pattern di espressione da eseguire.
'/DROP TABLE.*\tabella/,/UNLOCK TABLES/p': Definisce un intervallo di testo. Dice a sed: "Inizia a copiare quando trovi l'istruzione DROP TABLEper la tabella tabella e fermati non appena incontri il primoUNLOCK TABLES". La p finale sta per print (stampa).
>: Reindirizza tutto il testo estratto in un nuovo file pulito.

⚠️ Un dettaglio a cui fare attenzione

Questo metodo si basa sulla struttura standard di mysqldump, dove ogni tabella inizia con il blocco DROP TABLE ... e termina con UNLOCK TABLES.

Se il tuo dump è stato generato con tool di terze parti o con opzioni particolari (ad esempio disabilitando i blocchi delle tabelle o i drop), verifica i marker iniziali e finali nel file per adattare l'intervallo di sed.

Stabilizzazione dell'Infrastruttura: Gestire il Connection Pooling tra Proxy e Backend

minnogit — Mon, 18 May 2026 13:58:20 +0000

Nel mantenimento di architetture web complesse, l'ottimizzazione del dialogo tra il Proxy (nel nostro caso Apache) e i nodi di backend è un passaggio cruciale per garantire la fluidità dei servizi. Recentemente abbiamo analizzato una situazione di saturazione delle risorse che ci ha permesso di approfondire la gestione dei socket TCP, il comportamento dei pool di connessione e la complessa natura dei timeout multilivello.

In questo articolo vedremo come abbiamo identificato il problema, gli strumenti di monitoraggio utilizzati e come configurare correttamente i timeout per proteggere il proxy, senza penalizzare i portali che richiedono elaborazioni lunghe.

1. I primi segnali: Errori di Fork

Il punto di partenza della nostra analisi non è stato un crash, ma una serie di messaggi nei log di Apache che indicavano difficoltà nel gestire nuovi processi:

[error] (11)Resource temporarily unavailable: apr_thread_create: unable to create worker thread
[error] (11)Resource temporarily unavailable: fork: avocado_create: pool_task

Questi errori di fork compaiono quando il server raggiunge i limiti imposti dal sistema operativo o dalla configurazione dell'MPM (Multi-Processing Module). I worker esistenti rimangono occupati troppo a lungo, impedendo la creazione di nuovi thread per servire le nuove richieste in ingresso.

2. Monitoraggio e Analisi del Traffico

Per capire perché Apache stesse saturando i worker, abbiamo utilizzato alcuni comandi shell per analizzare lo stato delle connessioni di rete in tempo reale.

Analisi quantitativa per backend

Per osservare come variava il carico verso un nodo specifico (nel nostro caso il .106), abbiamo utilizzato un monitoraggio continuo:

watch -n 1 "netstat -atpn | grep 172.31.41.106 | wc -l"

Questo comando ci ha permesso di notare che il numero di connessioni non scalava verso il basso come previsto, indicando una persistenza anomala dei socket.

Analisi della distribuzione delle connessioni

Un altro comando fondamentale è stato quello per mappare la provenienza del traffico e identificare eventuali anomalie nella distribuzione dei client:

netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n

L'analisi dettagliata ha rivelato un numero elevato di connessioni in stato CLOSE_WAIT. Questo stato indica che il backend ha già terminato la sua parte di connessione, ma il proxy non ha ancora chiuso il socket lato suo. Un vero e proprio "limbo" TCP.

3. Disaccoppiare i Timeout: Applicazione vs Infrastruttura

Per risolvere questo scenario, è fondamentale fare chiarezza sulla differenza tra due concetti spesso confusi:

Timeout Applicativo: È il tempo richiesto dal codice sorgente per completare un'operazione (es. una query complessa o la generazione di un file pesante). Un timeout applicativo troppo lungo espone il server al pericolo di elaborazioni infinite, mantenendo il backend occupato e saturando le risorse computazionali.
Timeout Infrastrutturale (o di Rete): È il tempo massimo concesso per la trasmissione dei dati e la gestione dei socket tra i vari nodi della rete.

Il problema esaminato in questa analisi riguardava specificamente il timeout della comunicazione infrastrutturale tra il proxy e l'applicazione, ovvero i socket rimasti orfani che bloccavano i thread di Apache. L'implementazione applicativa interna al backend è ininfluente: che si tratti di un'architettura o di un'altra, se la gestione del socket TCP lato proxy fallisce, l'infrastruttura si satura.

4. Il Limite di Apache Balancer Manager: Timeout per Route

Durante le indagini abbiamo esplorato la possibilità di creare configurazioni di timeout differenziate a seconda della route (URL path), in modo da isolare i percorsi più lenti da quelli più veloci.

Tuttavia, abbiamo riscontrato un limite strutturale: il modulo Balancer Manager di Apache condivide il timeout del proxy per tutte le route. Non è un parametro sovrascrivibile o granularizzabile a livello di singolo membro del cluster o di specifico path all'interno dello stesso contesto di bilanciamento. Di conseguenza, la strategia di gestione dei timeout deve essere applicata in modo uniforme all'intero blocco del proxy.

5. La Soluzione: Il Ruolo di `connectiontimeout`

In molti dei nostri portali è indispensabile mantenere timeout globali alti per consentire l'esecuzione di script applicativi lunghi ed elaborazioni pesanti. Abbassare indiscriminatamente il timeout del proxy avrebbe interrotto servizi legittimi.

La soluzione definitiva che ha azzerato i CLOSE_WAIT e risolto gli errori di fork, pur mantenendo il supporto agli script lunghi, è stata il passaggio alla sintassi balancer:// sfruttando il parametro connectiontimeout.

Configurazione applicata:

<Proxy balancer://frontoffice>
    # node04 - Configurazione ottimizzata
    BalancerMember http://172.31.41.106:8080 route=4 connectiontimeout=2 retry=10 hcmethod=TCP hcinterval=5 hcpasses=2 hcfails=1

    ProxySet lbmethod=bybusyness
    ProxySet stickysession=ROUTEID
</Proxy>

ProxyPass "/" "balancer://frontoffice/"
ProxyPassReverse "/" "balancer://frontoffice/"

Perché questa configurazione è risolutiva?

Il segreto sta nella separazione tra il timeout di risposta globale e il timeout di connessione iniziale:

connectiontimeout=2 (La vera protezione): Questo parametro agisce solo sulla fase di handshake TCP iniziale. Se il backend è congestionato, bloccato o non risponde entro 2 secondi, Apache desiste immediatamente e libera il proprio worker. Questo previene l'accumulo di processi appesi in Apache che causavano gli errori di fork.
Mantenimento degli script lunghi: Una volta stabilita la connessione nei primi 2 secondi, il proxy concede all'applicazione tutto il tempo configurato nel timeout globale per terminare le sue elaborazioni pesanti.
Health Checks attivi (hcinterval=5): Apache interroga il backend ogni 5 secondi. Se un nodo fallisce i controlli TCP, viene temporaneamente isolato dal cluster, evitando di inviare traffico a un server saturo.

6. Conclusioni e Manutenzione Futura

La risoluzione degli errori di fork ci ha ricordato che la stabilità di un'infrastruttura non richiede di sacrificare le necessità dell'applicazione (come le elaborazioni lunghe), ma richiede di configurare correttamente i limiti della rete.

Per evitare derive configurative e mantenere l'uniformità su tutta la flotta di server, la distribuzione di queste direttive BalancerMember e la gestione dei relativi VirtualHost verrà centralizzata e gestita tramite Puppet Server. L'automazione è l'unica via per garantire che queste best practice rimangano stabili e documentate nel tempo.

Cheat Sheet di Emergenza per il futuro:

Isolamento rapido: netstat -atpn | grep CLOSE_WAIT per contare i socket orfani.
Analisi client: netstat -ntu | awk '{print $5}' ... per verificare la distribuzione degli IP.
Regola d'oro: Separare sempre il tempo concesso all'applicazione per elaborare i dati dal tempo concesso alla rete per aprire la connessione (connectiontimeout).

Watchdog Apache con Bash, Cron e Systemd: monitoraggio automatico di memoria, PID e socket close-wait

minnogit — Mon, 18 May 2026 11:18:27 +0000

In alcuni scenari ad alto carico o in presenza di problemi lato backend, Apache può degradare progressivamente fino a diventare lento, saturare le risorse o smettere di rispondere correttamente.

Per mitigare questo tipo di problemi è possibile implementare un watchdog leggero in Bash che:

monitora periodicamente lo stato del sistema;
verifica alcune metriche critiche;
esegue automaticamente un reload o un restart di Apache;
registra gli eventi tramite syslog e journalctl.

Questo approccio è particolarmente utile in ambienti:

con reverse proxy Apache;
con backend applicativi instabili;
con leak di connessioni;
dove è necessario un meccanismo di self-healing semplice e trasparente.

Obiettivo dello script

Lo script controlla:

RAM disponibile;
numero di PID usati dal servizio Apache;
connessioni TCP in stato close-wait verso un backend specifico;
health check HTTP locale;

In base alle soglie configurate:

esegue un reload di Apache;
oppure un restart completo;
scrive i dettagli nel journal di systemd.

Script completo

#!/bin/bash

# --- PARAMETRI DI SOGLIA ---
SOGLIA_RAM_FREE_MB=100
SOGLIA_PIDS_PERCENT=60
SOGLIA_close-wait=300

# --- RACCOLTA DATI ---
# Usiamo percorsi assoluti per cron e variabili pulite
RAM_DISPONIBILE_MB=$(/usr/bin/free -m | grep Mem | awk '{print $7}')

# Conteggio in tempo reale delle connessioni orfane in close-wait
close-wait_COUNT=$(/usr/bin/ss -H -tanp state close-wait | /usr/bin/wc -l)

# Gestione PIDs con controllo esistenza file (evita errori se Apache è spento)
PIDS_FILE="/sys/fs/cgroup/system.slice/apache2.service/pids.current"
MAX_FILE="/sys/fs/cgroup/system.slice/apache2.service/pids.max"

if [ -f "$PIDS_FILE" ]; then
    CURRENT_APACHE_PIDS=$(cat "$PIDS_FILE")
    MAX_APACHE_PIDS=$(cat "$MAX_FILE")

    # Se MAX è la stringa "max", o è 0, o è vuoto -> la percentuale è 0 (limite infinito)
    if [ "$MAX_APACHE_PIDS" = "max" ] || [ -z "$MAX_APACHE_PIDS" ] || [ "$MAX_APACHE_PIDS" -eq 0 ] 2>/dev/null; then
        PERCENTUAL_PIDS=0
    else
        PERCENTUAL_PIDS=$(( 100 * CURRENT_APACHE_PIDS / MAX_APACHE_PIDS ))
    fi
else
    PERCENTUAL_PIDS=0
fi

# --- LOGICA DI CONTROLLO ---
AZIONE_NECESSARIA=false
TIPO_AZIONE="reload" # Default

if [ "$RAM_DISPONIBILE_MB" -lt "$SOGLIA_RAM_FREE_MB" ]; then
    MOTIVO="RAM bassa (${RAM_DISPONIBILE_MB}MB)"
    AZIONE_NECESSARIA=true
    TIPO_AZIONE="restart" # Se la RAM è finita, il reload è troppo lento
elif [ "$PERCENTUAL_PIDS" -gt "$SOGLIA_PIDS_PERCENT" ]; then
    MOTIVO="PIDs al ${PERCENTUAL_PIDS}% (${CURRENT_APACHE_PIDS}/${MAX_APACHE_PIDS})"
    AZIONE_NECESSARIA=true
    TIPO_AZIONE="reload"
elif [ "$close-wait_COUNT" -gt "$SOGLIA_close-wait" ]; then
    MOTIVO="Rilevato leak di socket (${close-wait_COUNT} connessioni in close-wait)"
    AZIONE_NECESSARIA=true
    TIPO_AZIONE="reload" # Il reload è sufficiente a liberare i socket orfani
fi

# Check sopravvivenza: se Apache non risponde, forza RESTART a prescindere dalle soglie
if ! /usr/bin/curl -s --max-time 5 http://127.0.0.1/ > /dev/null; then
    MOTIVO="Apache non risponde (Health Check fallito)"
    AZIONE_NECESSARIA=true
    TIPO_AZIONE="restart"
fi

# --- AZIONE ---
if $AZIONE_NECESSARIA; then
    echo "$(date): Allarme: ${MOTIVO}. Eseguo ${TIPO_AZIONE}."
    /usr/bin/logger -t apache_health_watchdog "Allarme: ${MOTIVO}. Eseguo ${TIPO_AZIONE}."

    if [ "$TIPO_AZIONE" == "reload" ]; then
        /usr/bin/systemctl reload apache2

        # Se il reload fallisce (es. kernel già in fork rejected), prova il restart
        if [ $? -ne 0 ]; then
            /usr/bin/logger -t apache_health_watchdog "Reload fallito, forzo restart."
            /usr/bin/systemctl restart apache2
        fi
    else
        /usr/bin/systemctl restart apache2
    fi
fi

Installazione

Salvare lo script in:

/usr/local/sbin/check_system_health.sh

Rendere il file eseguibile:

chmod +x /usr/local/sbin/check_system_health.sh

Configurazione del cron

Aggiungere in /etc/crontab:

*/2 * * * * root flock -n /tmp/apache_watchdog.lock /usr/local/sbin/check_system_health.sh >> /var/log/apache_health_watchdog.log 2>&1

Questo esegue il controllo ogni 2 minuti.

Perché usare `flock`

flock evita esecuzioni concorrenti dello script.

In condizioni di degrado del sistema:

un controllo potrebbe impiegare più tempo del previsto;
il cron successivo potrebbe partire mentre il precedente è ancora attivo;
si rischiano reload o restart multipli contemporanei.

Con:

flock -n /tmp/apache_watchdog.lock

solo una istanza dello script può essere eseguita alla volta.

Analisi delle metriche monitorate

1. RAM disponibile

free -m

Lo script utilizza:

awk '{print $7}'

che corrisponde alla colonna available.

Se la memoria disponibile scende sotto:

SOGLIA_RAM_FREE_MB=100

viene eseguito un restart completo di Apache.

Questo è utile perché:

il reload può richiedere fork aggiuntivi;
in condizioni di memoria critica il reload potrebbe peggiorare la situazione;
un restart libera immediatamente worker e memoria frammentata.

2. Saturazione PID Apache

Lo script legge direttamente i contatori cgroup di systemd:

/sys/fs/cgroup/system.slice/apache2.service/pids.current

/sys/fs/cgroup/system.slice/apache2.service/pids.max

Questo approccio è molto più affidabile rispetto al parsing di ps.

Se il servizio supera:

SOGLIA_PIDS_PERCENT=60

viene eseguito un reload.

Questo permette di:

rigenerare worker;
liberare processi stuck;
evitare il raggiungimento del limite massimo PID.

3. Socket close-wait

Lo stato close-wait indica:

il peer remoto ha chiuso la connessione;
il processo locale non ha ancora rilasciato il socket.

Molte connessioni in close-wait possono indicare:

leak applicativi;
backend instabili;
worker Apache bloccati;
timeout mal configurati.

Lo script utilizza:

ss -tanp state close-wait

Questo approccio è preferibile rispetto a netstat perché:

ss è più moderno;
usa meno CPU;
legge direttamente dal kernel tramite netlink;
è più affidabile sotto alto carico;
evita dipendenze da net-tools.

Se il numero supera:

SOGLIA_close-wait=300

viene eseguito un reload.

Logging e monitoraggio

Lo script utilizza:

logger -t apache_health_watchdog

Quindi gli eventi sono consultabili tramite:

journalctl -t apache_health_watchdog

Esempio:

May 18 10:42:01 server apache_health_watchdog: Allarme: Rilevato leak di socket (182 connessioni in close-wait). Eseguo reload.

Per seguire i log in tempo reale:

journalctl -f -t apache_health_watchdog

Quando usare questo approccio

Questo watchdog è particolarmente utile quando:

Apache funge da reverse proxy;
i backend possono bloccarsi o degradare;
non è disponibile un orchestratore avanzato;
si vuole una soluzione semplice e immediata;
si desidera un meccanismo di self-healing leggero.

Limiti della soluzione

Questo approccio non sostituisce:

un monitoraggio completo;
metriche Prometheus/Grafana;
tracing applicativo;
analisi root cause;
tuning corretto di Apache e backend.

Il watchdog serve principalmente come:

mitigazione automatica;
protezione operativa;
recovery rapido.

Eseguire Backup grandi su Debian: Compressione, Split e Sessioni Persistenti

minnogit — Fri, 23 Jan 2026 15:52:34 +0000

Gestire dataset massivi (100GB+) su un server remoto presenta due sfide principali: la gestione delle risorse (RAM/CPU) e la stabilità della connessione. Se la sessione SSH cade mentre stai creando un archivio enorme, il processo viene interrotto bruscamente, obbligandoti a ricominciare da capo.

In questa guida vedremo come usare 7-Zip per creare archivi multi-volume e come proteggere il processo con screen.

1. Il problema della disconnessione SSH

Quando avvii un comando tramite SSH, questo è legato alla tua sessione. Se la tua connessione internet vacilla o chiudi il terminale, il sistema invia un segnale di "hangup" (SIGHUP) e interrompe il lavoro. Per un backup di molto grande che può richiedere ore, questo è un rischio inaccettabile.

La soluzione: GNU Screen

screen è un multiplexer di terminale che permette di avviare un processo in una sessione virtuale che sopravvive anche se ti disconnetti.

Installazione:

sudo apt update && sudo apt install screen p7zip-full

2. Flusso di lavoro con Screen

Prima di lanciare il comando di compressione, crea una sessione dedicata:

Crea una sessione: screen -S backup_cliente
Lancia il comando di compressione (vedi sezione successiva).
Scollegati (Detach): Premi CTRL + A e poi il tasto D. Ora puoi chiudere il terminale e spegnere il tuo PC; il server continuerà a lavorare.
Ricollegati (Resume): Quando vuoi controllare l'avanzamento, torna nel terminale e scrivi:

screen -r backup_cliente

3. Il comando 7-Zip ottimizzato (Low RAM)

Per evitare che il server vada in crash per esaurimento memoria (OOM Error), utilizziamo parametri che limitano l'uso della RAM e della CPU:

7z a -v1g -mx=1 -md=16m -mmt=2 -p -mhe=on archive_name.7z ./source_folder/

Analisi dei parametri:

a: Aggiunge i file all'archivio.
-v1g: Divide l'archivio in parti da 1GB (ideale per upload/download FTP stabili).
-mx=1: Compressione minima (ultra-rapida). Fondamentale per risparmiare tempo.
-md=16m: Riduce il "dizionario" di compressione a 16MB per mantenere basso l'uso della RAM.
-mmt=2: Limita l'uso a 2 thread della CPU.
-p: Richiede una password in modo sicuro (non apparirà in chiaro nei log).
-mhe=on: Cifra anche i nomi dei file (senza password non si vede il contenuto).

5. Verifica e Consegna al Cliente

Una volta terminato, verifica l'integrità dei volumi prima di caricarli sull'FTP:

7z t archive_name.7z.001

Istruzioni per il cliente:
Comunica al destinatario che per estrarre i dati dovrà:

Scaricare tutti i file (.001, .002, ... fino al file .7z).
Usare software come 7-Zip (Windows).
Aprire esclusivamente il primo file della serie; il programma ricomporrà automaticamente l'intero archivio.

Ripristinare il backup di un database PostgreSQL su AWS senza accesso diretto al server DB

minnogit — Tue, 20 Jan 2026 18:25:27 +0000

In molte infrastrutture AWS ben progettate, il server PostgreSQL non è esposto su Internet:
non ha un IP pubblico statico e non è accessibile direttamente via SSH.

Il database risiede in una subnet privata all’interno di una VPC, mentre l’accesso avviene tramite un server ponte (jump host / bastion host) con IP pubblico.

In questo articolo vediamo come ripristinare un database PostgreSQL partendo da un file .sql presente sul proprio PC, analizzando le diverse soluzioni possibili, i pro e contro, e raccogliendo in fondo una serie di comandi PostgreSQL di uso comune come note operative.

Scenario di riferimento

PC locale: Debian Linux, con file db.sql
Server ponte: accessibile via SSH con chiave (serverponte.dominioaziendale.it)
Server PostgreSQL:
- Debian
- IP privato statico (es. serverpostgresql.ipprivato.domioaziendale.it)
- Accessibile solo dalla VPC
Utenti DB disponibili:
- postgres (superuser)
- admin (utente applicativo)
Obiettivo: ripristinare il database NomeDB da script SQL

Problema tipico

Lo script SQL non viene eseguito correttamente usando DBeaver con l’utente admin e produce errori come:

permessi insufficienti
impossibilità di creare estensioni
errori su OWNER TO postgres
messaggi legati a pg_hba.conf

👉 Questo accade perché un file .sql spesso contiene operazioni da superuser, anche se il database esiste già.

Le possibili soluzioni

✔️ Soluzione 1 – Tunnel SSH + `psql` locale (consigliata)

È la soluzione più pulita, sicura e professionale.
Non richiede di copiare file sui server e sfrutta il port forwarding SSH.

Schema logico

PC locale → tunnel SSH → server ponte → rete privata → PostgreSQL

Apertura del tunnel

Dal PC locale:

ssh -L 5433:serverpostgresql.ipprivato.domioaziendale.it:5432 serverponte.dominioaziendale.it

5433 → porta locale
5432 → porta PostgreSQL remota
il tunnel resta attivo finché la sessione SSH è aperta

Ripristino del database

In un secondo terminale locale:

psql -h localhost -p 5433 -U admin -d NomeDB < db.sql

⚠️ In questo scenario l’utente admin deve essere SUPERUSER, altrimenti lo script potrebbe fallire.

✔️ Soluzione 2 – Promuovere temporaneamente `admin` a superuser

Se pg_hba.conf blocca le connessioni dell’utente postgres da remoto (caso molto comune in ambienti gestiti con Puppet), la soluzione più pragmatica è:

ALTER USER admin WITH SUPERUSER;

Dopo il ripristino:

ALTER USER admin WITH NOSUPERUSER;

✔️ Veloce
✔️ Non richiede modifiche a pg_hba.conf
✔️ Adatta a interventi manuali controllati

✔️ Soluzione 3 – Copiare il file sul server DB ed eseguire localmente

Indicata per file molto grandi o connessioni instabili.

scp db.sql serverponte.dominioaziendale.it:/tmp/
# poi dal jump host verso il DB
scp /tmp/db.sql serverpostgresql.ipprivato.domioaziendale.it:/tmp/

Sul server DB:

su - postgres
psql NomeDB < /tmp/db.sql

✔️ Massima affidabilità
❌ Più passaggi manuali

Perché DBeaver spesso non basta

DBeaver funziona bene per:

restore da dump binari
operazioni standard
utenti applicativi

Ma fallisce con script SQL complessi che contengono:

CREATE EXTENSION
ALTER OWNER
SET ROLE
operazioni su schemi di sistema

👉 In questi casi psql è lo strumento giusto.

Note operative – Comandi PostgreSQL di uso comune

Creare un database

CREATE DATABASE NomeDB;

Creare una copia da un database esistente

CREATE DATABASE testCopia WITH TEMPLATE 'NomeDB';

Assegnare tutti i permessi a un utente

GRANT ALL PRIVILEGES ON DATABASE NomeDB TO admin;

Collegarsi a un database con un utente specifico

psql -U admin -d NomeDB -h localhost

Eliminare un database

$ psql -U postgresql -h localhost
DROP DATABASE database_da_eliminare WITH (FORCE);

Backup con `pg_dump`

Creare un dump SQL

pg_dump -f /tmp/nome_database_dump.sql -U postgres -W nome_database

Significato opzioni:

-f → file di output
-U postgres → utente DB
-W → richiede password
nome_database → nome database

Evitare la richiesta password (automazioni)

Metodo consigliato: `.pgpass`

File ~/.pgpass:

hostname:port:database:username:password

Permessi obbligatori:

chmod 600 ~/.pgpass

Metodo rapido (meno sicuro)

export PGPASSWORD='password'

Ripristino di un database PostgreSQL: scegliere il comando giusto

Il comando da usare per il ripristino dipende dal formato del backup, ovvero da come è stato creato con pg_dump.

È un aspetto fondamentale: usare lo strumento sbagliato porta a errori o a ripristini incompleti.

1️⃣ Ripristino da file SQL (Plain Text)

Se il backup è stato creato senza opzioni di formato (output leggibile, .sql):

pg_dump nome_database > backup.sql

oppure:

pg_dump -f /tmp/pnd_dump.sql nome_database

il ripristino va fatto con psql, che esegue sequenzialmente le istruzioni SQL contenute nel file.

psql -U postgres -d nome_database -f /tmp/nome_database_dump.sql

Note importanti:

Il database di destinazione deve già esistere
Il file è leggibile e modificabile
Su database molto grandi può essere più lento

2️⃣ Ripristino da file Custom o Directory (`.dump`, `.bak`)

Se il backup è stato creato con:

pg_dump -Fc nome_database > backup.dump

oppure:

pg_dump -Fd nome_database -f backup_dir

si tratta di un formato binario/speciale, che non può essere eseguito con psql.

In questo caso va usato pg_restore:

pg_restore -U postgres -d nome_database -v backup.dump

Opzioni utili:

-v → modalità verbose
--clean → elimina gli oggetti prima di ricrearli
--if-exists → evita errori se gli oggetti non esistono

Ripristino in parallelo (solo con `pg_restore`)

Uno dei grandi vantaggi dei formati custom o directory è la possibilità di usare più core CPU:

pg_restore -j 4 -U postgres -d nome_database backup.dump

👉 Ideale per database grandi in ambienti server.

Tabella rapida di riferimento

Formato backup	Strumento	Quando usarlo
`.sql` (plain text)	`psql`	Backup leggibile, semplice
`.dump` (custom)	`pg_restore`	Backup compresso, selettivo
directory	`pg_restore`	Ripristino veloce e parallelo

Nota operativa importante

Se il database di destinazione è già in uso, il ripristino può fallire per:

connessioni attive
oggetti già esistenti
lock sulle tabelle

In questi casi è consigliabile:

ripristinare su un database vuoto
oppure usare --clean con attenzione

Conclusione

In ambienti AWS con PostgreSQL in subnet private:

non si espone mai il DB su Internet
il jump host è la chiave
psql è lo strumento più affidabile
i permessi contano più della GUI

Il tunnel SSH + psql resta la soluzione più solida, ripetibile e sicura per ripristinare database PostgreSQL in infrastrutture cloud ben progettate.

Inizializzare GIT e configurare autenticazione SSH GitHub

minnogit — Thu, 08 May 2025 08:54:46 +0000

git --version

git config --global color.ui true
git config --global user.name 'Mario Rossi'
git config --global user.email emailAccount

git config --global core.editor nano
O questo per usare vscode:
git config --global core.editor "code --wait"

git config --global gui.editor gedit
git config --global init.defaultBranch main

Se non si mette --global la configurazione sarà relativa al repository.

Creare chiave ssh:

ssh-keygen -t ed25519 -C "your_email@example.com"
cat ~/.ssh/id_ed25519_sk.pub

Aggiungere al profilo Github la chiave pubblica.

Clonare il repository con ssh
Ad es.: git clone git@github.com:organizzazione/progetto.git
Si può fare anche da VSCode.

Se si ottiene errore Permission denied (publickey) vuol dire che il comando git non trova o non può usare la chiave SSH per parlare con GitHub.
Mi è successo in ambiente di sviluppo Dev Container con Docker Rootless in cui il Dev Container cerca di passare le chiavi dall'host al container.
Per risolvere, verificare se l'agente SSH è vivo:

echo $SSH_AUTH_SOCK

Se l'output è vuoto: VS Code non sta passando l'agente SSH al container.
Se vedi un percorso (es. /tmp/vscode-ssh-auth...): L'agente è passato, ma dobbiamo vedere se possiamo usarlo.

ssh-add -l

Se dice "The agent has no identities": L'agente è collegato ma "vuoto" (devi fare ssh-add sul tuo host Linux).

Verificare la connessione con ssh -vT git@github.com.

Elenco in Conky di applicazioni con l'uso della swap

minnogit — Thu, 20 Apr 2023 15:30:00 +0000

In continuazione del precedente post, adesso vediamo come stampare in Conky un elenco di programmi con la relativa quantità di swap usata.

Prepariamo uno script bash che restituisce il testo che vogliamo visualizzare in Conky basato sul comando spiegato in precedenza ma con una differenza in particolare: ci possono essere più processi in esecuzione dello spesso comando (ad esempio 5 processi per Chrome) ma quello che voglio visualizzare in Conky, è la somma della swap usata da tutti i processi dello stesso comando.

unioneTest=""
for file in /proc/*/status; do
  if [[ -f "$file" ]]; then
    test=$(awk '/^(Name:)/ {awk_name=$2} /^(VmSwap:)/ {awk_vmswap=$2" "$3} /^(Pid:)/ {awk_pid=$2} END { if (awk_vmswap && substr(awk_vmswap,1,1) != '0' ) print awk_name" "awk_pid" "awk_vmswap}' $file)
    if [ -n "$test" ]; then
      unioneTest+=$test"\n"
    fi
  fi
done

A differenza del comando precedente, alla fine dell'analisi awk di ogni file, viene verificato se la variabile awk_vmswap non è vuota e se il primo carattere non è "0". Se queste condizioni sono soddisfatte, viene creato un nuovo record di informazioni sul processo, che viene memorizzato nella variabile test.
Se la variabile test non è vuota, viene aggiunto alla variabile unioneTest e viene inserito un carattere di nuova linea ("\n") per separare i record.
Alla fine, $unioneTest conterrà l'elenco dei processi che usano la swap.

Il passo successivo, è sommare tra loro i valori di swap degli stessi comandi.
Per farlo, creo un array associativo denominato somma mediante il comando declare -A.
Questo array verrà utilizzato per accumulare i valori della terza colonna (ovvero la quantità di swap usata) dei processi che hanno lo stesso nome.

dati=$unioneTest
declare -A somma

while read -r linea; do
  nome=$(echo "$linea" | cut -d ' ' -f1)
  valore=$(echo "$linea" | cut -d ' ' -f3)
  ((somma[$nome] += valore))
done <<<"$(echo -e "$unioneTest")"

Il ciclo while viene alimentato con un here-string (<<<) che contiene l'output di un comando echo -e che converte una stringa contenente i dati da elaborare.

Infine, stampiamo l'elenco dall'array somma inserendo in ogni riga il numero di spazi necessario ad avere una lunghezza prestabilita. Gli spazi vengono inseriti tra il nome del comando e la quantità di swap usata.
La lunghezza delle righe, verrà specificata da un parametro dello script.

elenco=""
  for nome in "${!somma[@]}"; do
    tmp="$nome${somma[$nome]} kB\n"
    nrSpacesToAdd=$(expr $spaces - ${#tmp})
    elenco+="$nome$(printf '%*s' $nrSpacesToAdd)${somma[$nome]} kB\n"
  done
  echo -e "$elenco" | sort -k 2 -n -r

nrSpacesToAdd calcola il numero di spazi da aggiungere ad una stringa, in modo da ottenere una stringa di una lunghezza specifica.
La variabile $spaces rappresenta il numero totale di spazi che si desidera avere nella stringa finale.
La variabile ${#tmp} rappresenta la lunghezza della stringa tmp.

(printf '%*s' $nrSpacesToAdd) viene utilizzato per generare una stringa di spazi della lunghezza $nrSpacesToAdd.

Questo è lo script completo:

#!/bin/bash

if [ $# -eq 0 ]; then
  echo "Specificare la lunghezza delle stringhe"
  exit 1
fi

# Lunghezza voluta delle stringhe
spaces=$1

unioneTest=""
for file in /proc/*/status; do
  if [[ -f "$file" ]]; then
    test=$(awk '/^(Name:)/ {awk_name=$2} /^(VmSwap:)/ {awk_vmswap=$2" "$3} /^(Pid:)/ {awk_pid=$2} END { if (awk_vmswap && substr(awk_vmswap,1,1) != '0' ) print awk_name" "awk_pid" "awk_vmswap}' $file)
    if [ -n "$test" ]; then
      unioneTest+=$test"\n"
    fi
  fi
done

if [ -n "$unioneTest" ]; then
  dati=$unioneTest
  declare -A somma

  while read -r linea; do
    nome=$(echo "$linea" | cut -d ' ' -f1)
    valore=$(echo "$linea" | cut -d ' ' -f3)
    ((somma[$nome] += valore))
  done <<<"$(echo -e "$unioneTest")"

  elenco=""
  for nome in "${!somma[@]}"; do
    tmp=" $nome${somma[$nome]} kB\n"
    nrSpacesToAdd=$(expr $spaces - ${#tmp})
    elenco+="$nome$(printf '%*s' $nrSpacesToAdd)${somma[$nome]} kB\n"
  done
  echo -e "$elenco" | sort -k 2 -n -r
fi

Esempio di output:

$ ./swapUsed.sh 41
java                           94708 kB
apache2                        16188 kB
gnome-software                  8792 kB
chrome                           632 kB
pipewire-pulse                   564 kB
dbus-launch                      452 kB
exim4                            388 kB
dbus-daemon                      388 kB
postgres                          72 kB
(sd-pam)                          64 kB
containerd                        60 kB
spotify                           52 kB

Per usare il comando in Conky, ho aggiunto al file di configurazione .conkyrc le seguenti linee nella sezione conky.text:

...
$hr
${color grey}Name                          Swap used
${color lightgrey}${execi 30 ~/swapUsed.sh 41 | head -n 10}

Questo fa si che il comando venga eseguito ogni 30 secondi con il parametro 41 che specifica la lunghezza delle stringhe corretta per la mia configurazione Conky.
Con head -n 10, indico di stampare solo le prime 10 righe.

Qui il file .conkyrc completo:

-- Conky, a system monitor https://github.com/brndnmtthws/conky
--
-- This configuration file is Lua code. You can write code in here, and it will
-- execute when Conky loads. You can use it to generate your own advanced
-- configurations.
--
-- Try this (remove the `--`):
--
--   print("Loading Conky config")
--
-- For more on Lua, see:
-- https://www.lua.org/pil/contents.html

conky.config = {
    alignment = 'top_right',
    background = false,
    border_width = 1,
    cpu_avg_samples = 2,
    default_color = 'white',
    default_outline_color = 'white',
    default_shade_color = 'white',
    double_buffer = true,
    draw_borders = false,
    draw_graph_borders = true,
    draw_outline = false,
    draw_shades = false,
    extra_newline = false,
    font = 'DejaVu Sans Mono:size=8',
    gap_x = 60,
    gap_y = 60,
    minimum_height = 5,
    minimum_width = 5,
    net_avg_samples = 2,
    no_buffers = true,
    out_to_console = false,
    out_to_ncurses = false,
    out_to_stderr = false,
    out_to_x = true,
    own_window = true,
    own_window_colour = '000000',
    own_window_class = 'Conky',
    own_window_type = 'desktop',
    own_window_transparent = true,
    own_window_argb_visual = true,
    own_window_hints = 'undecorated,below,sticky,skip_taskbar,skip_pager',
    show_graph_range = false,
    show_graph_scale = false,
    stippled_borders = 0,
    update_interval = 5.0,
    uppercase = false,
    use_spacer = 'none',
    use_xft = true,
}

conky.text = [[
${color grey}Uptime:$color $uptime
${color grey}RAM Usage:$color $mem/$memmax - $memperc% ${membar 8}
${color grey}Swap Usage:$color $swap/$swapmax - $swapperc% ${swapbar 8}
${color grey}CPU Usage:$color $cpu% ${cpubar 8}
${color grey}Processes:$color $processes  ${color grey}Running:$color $running_processes
$hr
${color grey}File systems:
 root $color${fs_used /}/${fs_size /} ${fs_bar 8 /}
 ec2-free $color${fs_free /mnt/ec2_export}/${fs_size /mnt/ec2_export} ${fs_bar 8 /mnt/ec2_export}
 qnap $color${fs_used /mnt/u_rsync}/${fs_size /mnt/u_rsync} ${fs_bar 8 /mnt/u_rsync}
${color grey}Networking:
Up:$color ${upspeed} ${color grey} - Down:$color ${downspeed}
$hr
${color grey}Name              PID     CPU%   MEM%
${color lightgrey} ${top name 1} ${top pid 1} ${top cpu 1} ${top mem 1}
${color lightgrey} ${top name 2} ${top pid 2} ${top cpu 2} ${top mem 2}
${color lightgrey} ${top name 3} ${top pid 3} ${top cpu 3} ${top mem 3}
${color lightgrey} ${top name 4} ${top pid 4} ${top cpu 4} ${top mem 4}
${color lightgrey} ${top name 5} ${top pid 5} ${top cpu 5} ${top mem 5}
$hr
${color grey}Name                          Swap used
${color lightgrey}${execi 30 ~/swapUsed.sh 41 | head -n 10}
]]

Gestire la cache di npm e considerazioni per Docker

minnogit — Mon, 17 Apr 2023 09:06:54 +0000

Quando si richiede di installare un pacchetto npm, questo viene scaricato da internet e salvato nella cartella di cache, se non è già presente, e poi installato nell'applicazione che lo richiede.
Dalla versione 5 di npm, la gestione della cache è self-healing per cui dovrebbe riconoscere eventuali pacchetti incompleti, danneggiati o obsoleti e, in tal caso, scaricarli nuovamente cercando anche di risolvere automaticamente le dipendenze nel modo migliore.
Tuttavia in alcuni casi, anche per risolvere problemi di installazione, è utile pulire la cache di npm con il comando:

$ npm --global cache verify
Cache verified and compressed (~/git/.npm/_cacache)
Content verified: 9127 (1525196266 bytes)
Content garbage-collected: 3491 (5398705346 bytes)
Index entries: 9129
Finished in 34.248s

La cartella della cache normalmente è ~/.npm (nell'es. sopra è ~/git/.npm) ma è possibile spostarla.
Possono esserci diversi motivi per cui si potrebbe voler controllare il percorso della cache:

la cartella può arrivare a occupare uno spazio considerevole e si potrebbe volerla spostare.
si vuole usare una cartella di cache condivisa tra più host per velocizzare le installazioni.
si vuole una cache condivisa tra gli utenti della stessa macchina.

Il comando per spostare la cartella di cache è:

npm config set cache nuovaCartella --global

Al posto di modificare la configurazione del file di configurazione di npm, è anche possibile impostare il percorso della cache in una variabile di ambiente:

export npm_config_cache=/path/to/cache

Dopo aver spostato la cache, lanciare il comando di verifica:

npm --global cache verify`

E' possibile vedere la configurazione attuale con il comando:

npm config list

Il comando di verifica non cancella pacchetti scaricati ma non più usati, perciò si potrebbe voler cancellare tutta la cache con il comando:

npm cache clean

Considerazioni per Docker

Se stiamo usando Docker, è possibile impostare la cartella della cache con:

docker run -e npm_config_cache=/path/to/cache mydockerimage:tag

In questo modo, il comando docker run consente di eseguire un container Docker configurato per utilizzare una specifica directory per la cache dei pacchetti npm.
Controllando dove i pacchetti vengono salvati, si può condividere la cache tra diversi container o host, ad esempio per ridurre il tempo di download dei pacchetti npm o per evitare di scaricare i pacchetti più volte.
Inoltre, ci permette di usare la stessa cartella di cache anche quando si avvia il container con un utente diverso da quello attuale (ogni utente ha la sua cartella di cache).

Dividere il monitor in 4 terminali con Terminator

minnogit — Thu, 13 Apr 2023 10:56:31 +0000

Una delle prime cose che faccio quando la mattina entro nel pc al lavoro, è aprire alcuni terminali.

Di solito uso Terminator che è un emulatore di terminale per Linux che consente di aprire e gestire più finestre di terminale all'interno di una sola finestra.
Ha diverse caratteristiche interessanti, anche se la sua configurazione non è molto intuitiva per certi aspetti.

La suddivisione in 4 terminali della finestra di Terminator è definita come un layout nel suo file di configurazione.
Ho quindi aggiunto un layout personalizzato server dalla finestra delle preferenze.

Si può anche modificare direttamente il file di configurazione:

$ nano ~/.config/terminator/config

[global_config]
  enabled_plugins = CustomCommandsMenu, APTURLHandler
  suppress_multiple_term_dialog = True
[keybindings]
[profiles]
  [[default]]
    background_darkness = 0.85
    font = Monospace 9
    scrollback_lines = 2000
    use_system_font = False
[layouts]
  [[default]]
    [[[child1]]]
      parent = window0
      type = Terminal
      command = ""
    [[[window0]]]
      parent = ""
      type = Window
  [[servers]]
    [[[child0]]]
      type = Window
      parent = ""
      order = 0
      position = 0:0
      maximised = True
      fullscreen = False
      size = 1920, 995
      title = admin@node01: ~
      last_active_term = 428ce1c8-9aed-4acf-a481-45a18c5f54a9
      last_active_window = True
    [[[child1]]]
      type = HPaned
      parent = child0
      order = 0
      position = 958
      ratio = 0.5002610966057441
    [[[child2]]]
      type = VPaned
      parent = child1
      order = 0
      position = 495
      ratio = 0.5
    [[[terminal3]]]
      type = Terminal
      parent = child2
      order = 0
      profile = default
      uuid = a1b21c6d-82fa-4907-9b35-838b3743bb62
      command = ""
    [[[terminal4]]]
      type = Terminal
      parent = child2
      order = 1
      profile = default
      uuid = 9a8f88b6-22e6-49f4-865f-d100a84fa56e
      command = ""
    [[[child5]]]
      type = VPaned
      parent = child1
      order = 1
      position = 496
      ratio = 0.5
    [[[terminal6]]]
      type = Terminal
      parent = child5
      order = 0
      profile = default
      uuid = 716efc36-9385-4b79-898f-a437165c439b
      command = ""
    [[[terminal7]]]
      type = Terminal
      parent = child5
      order = 1
      profile = default
      uuid = 428ce1c8-9aed-4acf-a481-45a18c5f54a9
      command = ""
[plugins]

Adesso è possibile avviare Terminator specificando di usare il layout server:

terminator --layout=servers

Infine, ho creato un launcher apposito per gnome-shell con MenuLibre per eseguire il comando sopra.

Stampare un elenco dei processi ordinato per la quantità di swap che usano

minnogit — Wed, 15 Mar 2023 22:21:24 +0000

Cercando su internet possiamo trovare questo comando per stampare l'elenco dei processi ordinato per uso del file di Swap:

for file in /proc/*/status ; do awk '/VmSwap|Name/{printf $2 " " $3}END{ print ""}' $file; done | sort -k 2 -n -r | less

Poiché per me è abbastanza magico, ho cercato di capire come funziona:

for file in /proc/*/status - Ciclo su tutti i file di stato dei processi attualmente in esecuzione. La variabile "file" assume il valore di ogni percorso di file corrispondente. Il contenuto del file di stato ad es. può essere:

cat /proc/6377/status
Name:   gnome-software
Umask:  0022
State:  S (sleeping)
Tgid:   6377
Ngid:   0
Pid:    6377
PPid:   6154
TracerPid:  0
Uid:    1000    1000    1000    1000
Gid:    1000    1000    1000    1000
FDSize: 256
Groups: 24 25 27 29 30 33 44 46 106 109 112 114 999 1000 
NStgid: 6377
NSpid:  6377
NSpgid: 6154
NSsid:  6154
VmPeak:  2922312 kB
VmSize:  2791180 kB
VmLck:         0 kB
VmPin:         0 kB
VmHWM:    459088 kB
VmRSS:    163004 kB
RssAnon:      130664 kB
RssFile:       32340 kB
RssShmem:          0 kB
VmData:   621548 kB
VmStk:       728 kB
VmExe:       368 kB
VmLib:    184796 kB
VmPTE:      1384 kB
VmSwap:   218708 kB
HugetlbPages:          0 kB
CoreDumping:    0
THP_enabled:    1
Threads:    36
SigQ:   2/63374
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000001000
SigCgt: 0000000100000000
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 000001ffffffffff
CapAmb: 0000000000000000
NoNewPrivs: 0
Seccomp:    0
Seccomp_filters:    0
Speculation_Store_Bypass:   thread vulnerable
SpeculationIndirectBranch:  conditional enabled
Cpus_allowed:   f
Cpus_allowed_list:  0-3
Mems_allowed:   00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001
Mems_allowed_list:  0
voluntary_ctxt_switches:    83533
nonvoluntary_ctxt_switches: 8663

do awk '/VmSwap|Name/{printf $2 " " $3}END{ print ""}' $file; done - Per ogni percorso del file ($file), viene eseguito il comando awk. Il comando awk cerca le righe che contengono "VmSwap" o "Name" nel file di stato del processo e quindi utilizza il comando "printf" per stampare il secondo e il terzo campo di ogni riga. Nell' esempio del file di stato sopra, troviamo prima Name e poi VmSwap che verranno quindi trovati da awk in questo ordine. Quando la riga contiene Name, il secondo campo corrisponde al nome del processo e il terzo è vuoto. Quando la riga contiene VmSwap, il secondo campo contiene la memoria usata e il terzo l'unità di misura. Alla fine, la clausola "END" viene utilizzata per stampare una riga vuota per separare l'output dei diversi processi.
sort -k 2 -n -r - Ordina l'output in base al secondo campo (-k 2) in ordine numerico (-n) in ordine inverso (-r).
Significa che la quantità di swap usata dai processi è ordinata dal più grande al più piccolo.
less - Visualizzare l'output paginato nel terminale.

Es. di output del comando:

for file in /proc/*/status ; do awk '/VmSwap|Name/{printf $2 " " $3}END{ print ""}' $file; done | sort -k 2 -n -r | less
gnome-software 218708 kB
mariadbd 155576 kB
code 147548 kB
code 134844 kB
firefox 111212 kB
WebExtensions 71236 kB
java 70472 kB

Se vogliamo aggiungere la stampa del Pid possiamo modificare il comando in questo modo:

for file in /proc/*/status ; do awk '/^(VmSwap:|Name:|Pid:)/ {printf $2 " " $3}END{ print ""}' $file; done | sort -k 3 -n -r | less

Adesso, il pattern di ricerca usa il carattere ^ che specifica che la corrispondenza deve iniziare esattamente con una delle stringhe specificate.
In questo modo, le righe che iniziano ad es. con "PPid" non vengono selezionate da awk.
Adesso il secondo campo stampato sarà il Pid del processo e il terzo la swap usata.
Il sort lo facciamo quindi sul terzo campo.

Es. di output del comando:

for file in /proc/*/status ; do awk '/^(VmSwap:|Name:|Pid:)/ {printf $2 " " $3}END{ print ""}' $file; done | sort -k 3 -n -r | less
gnome-software 6377 218708 kB
mariadbd 46522 155576 kB
code 41703 147548 kB
code 40429 134844 kB
firefox 8840 111212 kB

Modificare allarme di spazio libero per un disco in Netdata

minnogit — Mon, 13 Mar 2023 14:01:40 +0000

Dall'interfaccia web di Netdata, in alto a destra, si vedono gli allarmi e, nei dettagli di ognuno, sono specificati i relativi file di configurazione.

Ad es., dai dettagli sopra si vede che l'allarme è configurato nel file /opt/netdata/usr/lib/netdata/conf.d/health.d/disks.conf

Se vogliamo che l'allarme per il disco /mnt/disco_utenti abbia regole diverse rispetto a quelle per gli altri dischi, possiamo modificare la configurazione così:

nano /opt/netdata/usr/lib/netdata/conf.d/health.d/disks.conf

Escludo il disco /mnt/disco_utenti dalla configurazione attuale modificando la lista families:

# -----------------------------------------------------------------------------
# low disk space

# checking the latest collected values
# raise an alarm if the disk is low on
# available disk space

 template: disk_space_usage
       on: disk.space
    class: Utilization
     type: System
component: Disk
       os: linux freebsd
    hosts: *
 families: !/mnt/disco_utenti !/mnt/disco_utenti !/dev !/dev/* !/run !/run/* *
     calc: $used * 100 / ($avail + $used)
    units: %
    every: 1m
     warn: $this > (($status >= $WARNING ) ? (80) : (90))
     crit: $this > (($status == $CRITICAL) ? (90) : (98))
    delay: up 1m down 15m multiplier 1.5 max 1h
     info: disk ${label:mount_point} space utilization
       to: sysadmin

Aggiungo alla configurazione una nuova sezione per l'allarme del disco /mnt/disco_utenti:

# -----------------------------------------------------------------------------
# low disk space

# checking the latest collected values
# raise an alarm if the disk is low on
# available disk space

 template: disk_space_usage
       on: disk.space
    class: Utilization
     type: System
component: Disk
       os: linux freebsd
    hosts: *
 families: /mnt/disco_utenti
     calc: $used * 100 / ($avail + $used)
    units: %
    every: 10m
     warn: $this > (($status >= $WARNING ) ? (96) : (98))
     crit: $this > (($status == $CRITICAL) ? (98) : (99))
    delay: up 1m down 15m multiplier 1.5 max 1h
     info: disk ${label:mount_point} space utilization
       to: sysadmin

 template: disk_inode_usage
      on: disk.inodes
    class: Utilization
     type: System
component: Disk
       os: linux freebsd
    hosts: *
 families: !/dev !/dev/* !/run !/run/* *
     calc: $used * 100 / ($avail + $used)
    units: %
    every: 1m
     warn: $this > (($status >= $WARNING)  ? (80) : (90))
     crit: $this > (($status == $CRITICAL) ? (90) : (98))
    delay: up 1m down 15m multiplier 1.5 max 1h
     info: disk ${label:mount_point} inode utilization
       to: sysadmin

Riavviare Netdata:

systemctl restart netdata

DEV Community: minnogit

Come estrarre una singola tabella da un file dump MySQL

🔍 Come funziona?

⚠️ Un dettaglio a cui fare attenzione

Stabilizzazione dell'Infrastruttura: Gestire il Connection Pooling tra Proxy e Backend

1. I primi segnali: Errori di Fork

2. Monitoraggio e Analisi del Traffico

Analisi quantitativa per backend

Analisi della distribuzione delle connessioni

3. Disaccoppiare i Timeout: Applicazione vs Infrastruttura

4. Il Limite di Apache Balancer Manager: Timeout per Route

5. La Soluzione: Il Ruolo di connectiontimeout

Perché questa configurazione è risolutiva?

6. Conclusioni e Manutenzione Futura

Cheat Sheet di Emergenza per il futuro:

Watchdog Apache con Bash, Cron e Systemd: monitoraggio automatico di memoria, PID e socket close-wait

Obiettivo dello script

Script completo

Installazione

Configurazione del cron

Perché usare flock

Analisi delle metriche monitorate

1. RAM disponibile

2. Saturazione PID Apache

3. Socket close-wait

Logging e monitoraggio

Quando usare questo approccio

Limiti della soluzione

Eseguire Backup grandi su Debian: Compressione, Split e Sessioni Persistenti

1. Il problema della disconnessione SSH

La soluzione: GNU Screen

2. Flusso di lavoro con Screen

3. Il comando 7-Zip ottimizzato (Low RAM)

Analisi dei parametri:

5. Verifica e Consegna al Cliente

Ripristinare il backup di un database PostgreSQL su AWS senza accesso diretto al server DB

Scenario di riferimento

Problema tipico

Le possibili soluzioni

✔️ Soluzione 1 – Tunnel SSH + psql locale (consigliata)

Schema logico

Apertura del tunnel

Ripristino del database

✔️ Soluzione 2 – Promuovere temporaneamente admin a superuser

✔️ Soluzione 3 – Copiare il file sul server DB ed eseguire localmente

Perché DBeaver spesso non basta

Note operative – Comandi PostgreSQL di uso comune

Creare un database

Creare una copia da un database esistente

Assegnare tutti i permessi a un utente

Collegarsi a un database con un utente specifico

Eliminare un database

Backup con pg_dump

Creare un dump SQL

Evitare la richiesta password (automazioni)

Metodo consigliato: .pgpass

Metodo rapido (meno sicuro)

Ripristino di un database PostgreSQL: scegliere il comando giusto

1️⃣ Ripristino da file SQL (Plain Text)

2️⃣ Ripristino da file Custom o Directory (.dump, .bak)

Ripristino in parallelo (solo con pg_restore)

Tabella rapida di riferimento

Nota operativa importante

Conclusione

Inizializzare GIT e configurare autenticazione SSH GitHub

Elenco in Conky di applicazioni con l'uso della swap

Gestire la cache di npm e considerazioni per Docker

Considerazioni per Docker

Dividere il monitor in 4 terminali con Terminator

Stampare un elenco dei processi ordinato per la quantità di swap che usano

Modificare allarme di spazio libero per un disco in Netdata

5. La Soluzione: Il Ruolo di `connectiontimeout`

Perché usare `flock`

✔️ Soluzione 1 – Tunnel SSH + `psql` locale (consigliata)

✔️ Soluzione 2 – Promuovere temporaneamente `admin` a superuser

Backup con `pg_dump`

Metodo consigliato: `.pgpass`

2️⃣ Ripristino da file Custom o Directory (`.dump`, `.bak`)

Ripristino in parallelo (solo con `pg_restore`)