InnoMarts logo
InnoMarts
Fast websites
← Back to course

Backup, restore e manutenzione base: proteggere i tuoi dati PostgreSQL

Backup, restore e manutenzione base: proteggere i tuoi dati PostgreSQL

Bentornato.

Nella lezione precedente hai imparato come PostgreSQL si collega alle applicazioni reali.

Hai imparato:

Molto bene.

Ora il tuo database può lavorare con applicazioni reali.

Questo è potente.

Ma la potenza porta responsabilità.

E a volte panico.

Perché quando la tua applicazione salva dati reali, una domanda diventa molto importante:

Cosa succede se qualcosa va storto?

Una tabella viene eliminata.

Un server va in crash.

Una migration sbagliata viene eseguita.

Uno sviluppatore scrive DELETE senza WHERE.

Un laptop muore.

Un disco si rompe.

Qualcuno dice:

Ho cambiato solo una piccola cosa.

Frase molto pericolosa.

Oggi parleremo di backup, restore e manutenzione base.

Questa non è la parte più glamour dei database.

Nessuno apre un corso PostgreSQL dicendo:

Non vedo l’ora di imparare la strategia di backup.

Ma i backup sono noiosi solo fino al giorno in cui ti servono.

Poi diventano bellissimi.

Come un paracadute.

Non emozionante mentre cammini normalmente.

Molto importante mentre stai cadendo.

Cosa imparerai

In questa lezione imparerai:

Alla fine di questa lezione capirai come proteggere i tuoi dati PostgreSQL.

Perché creare dati è buono.

Usare dati è utile.

Perdere dati forma il carattere.

Ma cerchiamo di evitare troppa formazione del carattere.

Perché i backup sono importanti

Un backup è una copia del tuo database che puoi usare se qualcosa va storto.

Idea semplice.

Molto importante.

Senza backup, la perdita di dati può essere permanente.

Esempi di problemi:

Qualcuno elimina righe per errore.
Una migration rompe le tabelle.
Un disco del server si guasta.
Un database si corrompe.
Un comando sbagliato elimina una tabella.
Un deploy va male.
Un database di produzione viene sovrascritto.

Alcune cose sembrano drammatiche.

Alcune sembrano stupide.

Nella vita reale succedono entrambe.

I computer falliscono.

Gli esseri umani falliscono.

Gli sviluppatori falliscono creativamente.

Un backup ti dà una strada di ritorno.

Non è magia.

Ma è speranza in formato file.

Un backup non è reale finché il restore non funziona

Regola molto importante:

Un backup che non hai mai testato è solo una teoria.

Puoi avere un file di backup.

Ma riesci a ripristinarlo?

Contiene i dati che ti aspetti?

È completo?

È troppo vecchio?

Richiede una password che hai dimenticato?

Si ripristina in un database funzionante?

Se non lo sai, non hai davvero una strategia di backup.

Hai un portafortuna.

E PostgreSQL non è impressionato dai portafortuna.

Quindi ricorda sempre:

Backup è il primo passo.
Test del restore è il secondo passo.

Entrambi contano.

Preparare un database demo

Apri PostgreSQL:

sudo -iu postgres psql

Crea un database demo:

CREATE DATABASE backup_demo_db;

Collegati:

\c backup_demo_db

Crea una tabella:

CREATE TABLE notes (
  id SERIAL PRIMARY KEY,
  title VARCHAR(150) NOT NULL,
  content TEXT,
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Inserisci alcuni dati:

INSERT INTO notes (title, content)
VALUES
  ('First Note', 'This is the first note.'),
  ('Backup Note', 'This row should survive backup and restore.'),
  ('PostgreSQL Note', 'Databases remember things. Sometimes too well.');

Controlla i dati:

SELECT * FROM notes;

Ora abbiamo un piccolo database da salvare.

Non dati molto importanti.

Ma buoni per fare pratica.

Fai pratica con dati finti.

Non con produzione.

La produzione non è un parco giochi.

La produzione è dove piccoli errori indossano scarpe costose.

Cos’è pg_dump?

pg_dump è uno strumento PostgreSQL che crea un backup di un database.

Può esportare:

struttura delle tabelle
dati
indici
constraint
sequenze
oggetti del database

Di default non fa il backup dell’intero server PostgreSQL.

Fa il backup di un database.

Idea base:

pg_dump legge un database e scrive un file di backup.

Esegui pg_dump dal terminale.

Non dentro psql.

Questo è importante.

Dentro psql scrivi comandi SQL.

Nel terminale esegui strumenti come:

pg_dump
psql
createdb
dropdb
pg_restore

Posti diversi.

Strumenti diversi.

Stessa avventura database.

Creare un backup SQL semplice

Prima esci da psql:

\q

Ora esegui dal terminale:

pg_dump -U postgres -d backup_demo_db > backup_demo_db.sql

Questo crea un file:

backup_demo_db.sql

Questo è un backup SQL semplice.

Contiene comandi SQL che possono ricreare struttura e dati del database.

Puoi ispezionarlo:

less backup_demo_db.sql

Potresti vedere comandi come:

CREATE TABLE
COPY
ALTER TABLE
CREATE SEQUENCE

Un backup SQL semplice è leggibile da un essere umano.

Questo è bello.

Può essere ripristinato con psql.

Semplice.

Utile.

Molto adatto ai principianti.

Backup con host e porta

A volte devi specificare host e porta:

pg_dump -h localhost -p 5432 -U postgres -d backup_demo_db > backup_demo_db.sql

Questo significa:

-h localhost      collegati a localhost
-p 5432           usa la porta 5432
-U postgres       collegati come utente postgres
-d backup_demo_db fai il backup di questo database

Se usi un utente applicativo, sostituisci postgres con quell’utente.

Esempio:

pg_dump -h localhost -p 5432 -U app_user -d app_db > app_db.sql

L’utente deve avere il permesso di leggere il database.

PostgreSQL non può fare il backup di ciò che l’utente non può vedere.

Molto giusto.

Molto severo.

Molto PostgreSQL.

Ripristinare un backup SQL semplice

Ora ripristiniamo il backup in un nuovo database.

Crea un nuovo database:

createdb -U postgres backup_demo_restore_db

Ora ripristina:

psql -U postgres -d backup_demo_restore_db < backup_demo_db.sql

Questo legge il file SQL e lo esegue dentro il nuovo database.

Ora collegati:

psql -U postgres -d backup_demo_restore_db

Controlla i dati:

SELECT * FROM notes;

Dovresti vedere le righe.

Bene.

Hai creato un backup.

Lo hai ripristinato.

Lo hai testato.

Questa è la strada corretta.

Backup senza test di restore è teatro della sicurezza.

Test del restore è realtà.

La realtà conta.

Fastidioso ma vero.

Esempio di drop e restore

Simuliamo un disastro.

Collegati al database ripristinato:

psql -U postgres -d backup_demo_restore_db

Elimina la tabella:

DROP TABLE notes;

Ora controlla:

SELECT * FROM notes;

PostgreSQL si lamenterà:

relation "notes" does not exist

Molto triste.

Molto educativo.

Esci:

\q

Ripristina di nuovo:

psql -U postgres -d backup_demo_restore_db < backup_demo_db.sql

Se la tabella esiste già, potresti ricevere errori, a meno che il backup includa comandi di drop.

Per fare pratica in modo più pulito, puoi ricreare il database:

dropdb -U postgres backup_demo_restore_db
createdb -U postgres backup_demo_restore_db
psql -U postgres -d backup_demo_restore_db < backup_demo_db.sql

Poi controlla di nuovo:

psql -U postgres -d backup_demo_restore_db

SELECT * FROM notes;

I dati sono tornati.

Questa è la sensazione magica dei backup.

Non vera magia.

Meglio.

Procedura testata.

Creare un backup con --clean

Puoi creare un backup che include comandi per eliminare oggetti esistenti prima di ricrearli.

Esempio:

pg_dump -U postgres --clean --if-exists -d backup_demo_db > backup_demo_clean.sql

Opzioni:

--clean       include comandi DROP
--if-exists   evita errori se gli oggetti non esistono

Questo può rendere più facile ripristinare sopra un database esistente.

Ma attenzione.

Un backup con comandi DROP può rimuovere oggetti esistenti durante il restore.

Magari è ciò che vuoi.

Oppure è il modo in cui la tua giornata diventa molto emozionante.

Devi sempre sapere cosa fa il tuo file di backup.

I file SQL non sono decorazioni.

Si eseguono.

PostgreSQL obbedisce.

Supporto emotivo non incluso.

Backup in formato custom

PostgreSQL supporta anche backup in formato custom.

Creane uno con:

pg_dump -U postgres -F c -d backup_demo_db -f backup_demo_db.dump

Qui:

-F c              formato custom
-f nome_file      file di output

Questo crea:

backup_demo_db.dump

Questo file non è SQL leggibile direttamente.

Ma è flessibile.

Si ripristina con pg_restore.

Il formato custom è utile perché puoi:

ripristinare tabelle selezionate
ripristinare con più opzioni
usare restore parallelo in casi più grandi
elencare il contenuto del backup

Per molti progetti reali, il formato custom è una buona scelta.

Meno leggibile.

Più potente.

Come una cassetta degli attrezzi database compressa.

Ripristinare un backup custom

Crea un nuovo database:

createdb -U postgres backup_demo_custom_restore_db

Ripristina con pg_restore:

pg_restore -U postgres -d backup_demo_custom_restore_db backup_demo_db.dump

Ora collegati:

psql -U postgres -d backup_demo_custom_restore_db

Controlla i dati:

SELECT * FROM notes;

Dovresti vedere i tuoi dati.

Bene.

Ora conosci entrambi gli stili:

backup SQL semplice -> restore con psql
backup custom       -> restore con pg_restore

Regola semplice.

Molto utile.

SQL semplice vs formato custom

Backup SQL semplice:

pg_dump -U postgres -d backup_demo_db > backup_demo_db.sql

Restore:

psql -U postgres -d new_db < backup_demo_db.sql

Buono per:

backup semplici
apprendimento
file leggibili
database piccoli
ispezione facile

Backup in formato custom:

pg_dump -U postgres -F c -d backup_demo_db -f backup_demo_db.dump

Restore:

pg_restore -U postgres -d new_db backup_demo_db.dump

Buono per:

database più grandi
restore più flessibile
ripristino di oggetti selezionati
workflow più vicini alla produzione

Entrambi sono utili.

Non trasformare questa cosa in una guerra religiosa.

I database hanno già abbastanza dramma.

Elencare il contenuto di un backup custom

Puoi ispezionare un backup custom:

pg_restore -l backup_demo_db.dump

Questo elenca cosa c’è dentro il backup.

Potresti vedere tabelle, sequenze, constraint e sezioni dati.

È utile se vuoi capire cosa contiene il backup.

Perché “spero che ci sia la tabella” non è una strategia.

Controlla.

Verifica.

Poi dormi meglio.

Forse.

Nomi dei file di backup

Usa nomi chiari.

Male:

backup.sql
new_backup.sql
backup_final.sql
backup_final_REAL.sql
backup_please_work.sql

Bene:

backup_demo_db_2026-05-03.sql
shop_db_2026-05-03_22-30.dump
portfolio_db_before_migration_2026-05-03.dump

Includi:

nome del database
data
ora se utile
motivo se utile

Esempio:

pg_dump -U postgres -F c -d shop_db -f shop_db_2026-05-03.dump

Nomi buoni salvano cervelli.

Nomi cattivi creano archeologia.

E nessuno vuole scavare file di backup alle 2 di notte.

Comprimere un backup SQL semplice

I backup SQL semplici possono essere grandi.

Puoi comprimerli:

pg_dump -U postgres -d backup_demo_db | gzip > backup_demo_db.sql.gz

Ripristinare backup compresso:

gunzip -c backup_demo_db.sql.gz | psql -U postgres -d backup_demo_restore_db

Questo è utile per risparmiare spazio su disco.

Ma ricorda:

Anche i file compressi devono essere testati.

Un backup compresso ma rotto è comunque rotto.

Solo più piccolo.

Tristezza molto efficiente.

Backup prima di modifiche pericolose

Prima di operazioni rischiose, crea un backup.

Esempi di operazioni rischiose:

migration grande
eliminare colonne
cambiare tipi di dato
mass update
mass delete
ridisegno dello schema
deploy in produzione
importare dati esterni

Esempio di backup:

pg_dump -U postgres -F c -d shop_db -f shop_db_before_migration_2026-05-03.dump

Poi fai la modifica pericolosa.

Se qualcosa va male, hai un punto di ritorno.

Questo è professionale.

Questo è calmo.

Questo è come evitare di fare storia del database nel modo sbagliato.

L’esempio pericoloso di DELETE

Questo è pericoloso:

DELETE FROM customers;

Elimina tutte le righe da customers.

Forse intendevi:

DELETE FROM customers
WHERE id = 5;

Piccola differenza.

Risultato enorme.

Prima di eseguire comandi pericolosi, usa una transazione quando possibile:

BEGIN;

Esegui il comando:

DELETE FROM customers
WHERE id = 5;

Controlla:

SELECT * FROM customers;

Se è corretto:

COMMIT;

Se è sbagliato:

ROLLBACK;

Le transazioni possono salvarti da alcuni errori.

I backup possono salvarti da errori più grandi.

Entrambi sono utili.

Come cintura di sicurezza e airbag.

Non sceglierne solo uno perché ti senti coraggioso.

Strategia base di backup

Una strategia semplice di backup deve rispondere a:

Quanto spesso facciamo backup?
Dove salviamo i backup?
Per quanto tempo li conserviamo?
Chi può accedere ai backup?
Come facciamo il restore?
Abbiamo testato il restore?

Per un piccolo progetto potresti fare:

backup giornaliero
conservare gli ultimi 7 backup giornalieri
conservare backup settimanale per 1 mese
salvare i backup fuori dal server
testare il restore regolarmente

Per progetti più seri serve un piano più forte.

Ma anche un semplice piano testato è molto meglio di:

Penso che il provider del server abbia qualcosa.

Forse sì.

Forse no.

Forse costa extra.

Forse non è mai stato attivato.

Forse ripristina tutto il server ma non il singolo database che ti serve.

Controlla.

Non presumere.

La supposizione è cugina del disastro.

Conservare i backup in un posto sicuro

Se database e backup sono sullo stesso server e il server muore, potresti perdere entrambi.

Male.

Posti migliori per i backup:

altro server
storage esterno
cloud storage sicuro
storage backup cifrato
copia offline per dati importanti

Come minimo, evita di tenere l’unico backup accanto al database originale.

È come tenere la chiave di riserva dentro la casa che sta bruciando.

Tecnicamente una chiave di riserva.

Praticamente poco utile.

Proteggere i file di backup

I backup contengono dati.

A volte dati sensibili.

Questo significa che i file di backup devono essere protetti.

Regole:

non esporre backup pubblicamente
limitare l’accesso
usare permessi forti
considerare la cifratura
eliminare vecchi backup in modo sicuro
non inviare dump del database via email con leggerezza

Un backup può essere sensibile quanto il database live.

A volte di più.

Perché la gente dimentica che esiste.

Gli attaccanti no.

Molto maleducato da parte loro.

Ma vero.

Manutenzione base: VACUUM

PostgreSQL usa un sistema in cui righe aggiornate o eliminate lasciano vecchie versioni delle righe.

Questo fa parte del modo in cui PostgreSQL gestisce la concorrenza.

Molto intelligente.

Ma significa che PostgreSQL ha bisogno di pulizia.

Questa pulizia si chiama:

VACUUM

Esegui:

VACUUM;

Questo pulisce le righe morte nel database corrente.

La maggior parte delle installazioni PostgreSQL ha autovacuum attivo.

Autovacuum gira automaticamente.

Bene.

Perché ricordare tutto manualmente è il modo in cui gli esseri umani perdono.

Comunque è utile sapere cosa fa VACUUM.

Aiuta PostgreSQL a mantenere sane le tabelle.

Come pulire un’officina.

Non glamour.

Molto necessario.

VACUUM ANALYZE

Puoi eseguire:

VACUUM ANALYZE;

Questo fa due cose:

VACUUM pulisce vecchie versioni di righe.
ANALYZE aggiorna le statistiche del planner.

Le statistiche del planner aiutano PostgreSQL a scegliere buoni piani di query.

Se le statistiche sono vecchie, PostgreSQL può fare scelte sbagliate.

Come usare l’indice sbagliato.

O scansionare troppo.

O comportarsi generalmente confuso.

ANALYZE aiuta PostgreSQL a capire meglio i dati.

Un database con statistiche aggiornate è un database più felice.

Probabilmente.

PostgreSQL non sorride.

Ma le prestazioni possono migliorare.

ANALYZE da solo

Puoi eseguire:

ANALYZE;

Questo aggiorna le statistiche senza fare vacuum.

Puoi anche analizzare una sola tabella:

ANALYZE products;

È utile dopo grandi modifiche ai dati.

Esempio:

hai importato molte righe
hai eliminato molte righe
hai aggiornato molte righe
è cambiata la distribuzione dei dati

PostgreSQL usa le statistiche per decidere come eseguire query.

Statistiche cattive possono produrre piani cattivi.

Piani cattivi producono query lente.

Query lente producono sviluppatori tristi.

La catena è chiara.

REINDEX

Gli indici a volte possono gonfiarsi o aver bisogno di essere ricostruiti.

PostgreSQL ha:

REINDEX

Esempio:

REINDEX DATABASE backup_demo_db;

Oppure un solo indice:

REINDEX INDEX index_name;

Oppure una tabella:

REINDEX TABLE table_name;

Non eseguire REINDEX a caso ogni cinque minuti.

Non è lavarsi i denti.

Usalo quando serve.

Per principianti basta sapere:

REINDEX ricostruisce gli indici.

Nella manutenzione reale, devi capire perché lo stai facendo.

Manutenzione cieca resta cieca.

Anche se indossa un cappello serio.

Controllare la dimensione del database

Puoi controllare la dimensione del database:

SELECT pg_size_pretty(pg_database_size('backup_demo_db'));

Controllare dimensioni delle tabelle:

SELECT
  relname AS table_name,
  pg_size_pretty(pg_total_relation_size(relid)) AS total_size
FROM pg_catalog.pg_statio_user_tables
ORDER BY pg_total_relation_size(relid) DESC;

Questo ti aiuta a capire cosa occupa spazio.

A volte la tabella più grande è prevista.

A volte è una tabella di log che nessuno ha pulito per tre anni.

I database raccolgono storia.

A volte troppa storia.

Come un cassetto pieno di vecchi cavi.

Controllare le connessioni attive

Puoi vedere le connessioni attive:

SELECT
  pid,
  usename,
  datname,
  state,
  query
FROM pg_stat_activity;

Questo mostra chi è collegato e cosa sta facendo.

Utile per debug.

Magari un’applicazione ha troppe connessioni.

Magari una query è bloccata.

Magari qualcuno ha aperto psql ed è andato a pranzo.

PostgreSQL lo sa.

PostgreSQL ricorda.

PostgreSQL giudica in silenzio.

Trovare query lente

PostgreSQL può registrare query lente se configurato.

Un’impostazione comune è:

log_min_duration_statement

Idea esempio:

loggare query più lente di 1000 ms

Di solito si configura nei file di configurazione PostgreSQL.

Per principianti, l’idea importante è:

Le query lente vanno osservate, non indovinate.

Usa strumenti come:

EXPLAIN ANALYZE
log
monitoring
pg_stat_statements

pg_stat_statements è un’estensione che può aiutare a tracciare le prestazioni delle query.

È più avanzata.

Ma è bene conoscerla.

Lavorare sulle prestazioni senza osservazione è astrologia da database.

E già non ci fidiamo dell’astrologia da database.

Checklist backup e manutenzione

Una checklist semplice:

Creare backup regolari.
Salvare backup fuori dal server del database.
Proteggere i file di backup.
Testare il restore.
Fare backup prima delle migration.
Usare utenti specifici per applicazione.
Tenere PostgreSQL aggiornato.
Monitorare lo spazio su disco.
Osservare query lente.
Lasciare attivo autovacuum.
Eseguire ANALYZE dopo grandi importazioni se necessario.
Documentare i passi di restore.

La documentazione conta.

Una procedura di restore non dovrebbe vivere solo nella tua testa.

Specialmente se la tua testa è stanca.

O in vacanza.

O sta bevendo caffè mentre la produzione brucia.

Scrivi i passi.

Il tuo io futuro merita pietà.

Errori comuni con i backup

Non testare mai il restore

Questo è l’errore più grande.

Un file di backup non basta.

Devi sapere che si ripristina.

Testa il restore su un altro database.

Esempio:

createdb -U postgres restore_test_db
pg_restore -U postgres -d restore_test_db shop_db_2026-05-03.dump

Poi controlla i dati.

Fidati, ma verifica.

Anzi, con i backup:

Non fidarti.
Verifica.

Tenere backup solo sullo stesso server

Se il server muore, puoi perdere database e backup insieme.

Male.

Salva copie altrove.

Un backup deve sopravvivere al guasto della macchina originale.

È questo il punto.

Fare backup troppo raramente

Se fai backup una volta al mese, potresti perdere un mese di dati.

Forse accettabile per un progetto giocattolo.

Non accettabile per un negozio reale.

Scegli la frequenza dei backup in base a quanti dati puoi permetterti di perdere.

Questa domanda ha un nome serio:

Recovery Point Objective

Versione semplice:

Quanta perdita di dati è accettabile?

Se la risposta è “quasi nessuna”, serve una strategia seria.

Non sapere quanto dura il restore

Un backup può esistere.

Ma il restore può richiedere tempo.

Per piccoli database, magari secondi.

Per database enormi, magari ore.

Se l’applicazione è giù, il tempo di restore conta.

Questa domanda ha un altro nome serio:

Recovery Time Objective

Versione semplice:

Per quanto tempo il sistema può restare offline?

Qui le persone di business diventano improvvisamente molto interessate ai database.

Curioso come funziona.

Fare backup del database sbagliato

Errore classico.

Pensi di aver fatto backup della produzione.

In realtà hai fatto backup dello sviluppo locale.

Il backup contiene tre utenti di test e un prodotto chiamato “banana”.

Controlla:

SELECT current_database();

Controlla i nomi dei file backup.

Controlla il risultato del restore.

Non presumere.

Pratica

Crea un backup di backup_demo_db:

pg_dump -U postgres -d backup_demo_db > backup_demo_db.sql

Crea un database di restore:

createdb -U postgres backup_demo_restore_db

Ripristina:

psql -U postgres -d backup_demo_restore_db < backup_demo_db.sql

Controlla:

psql -U postgres -d backup_demo_restore_db

SELECT * FROM notes;

Crea un backup custom:

pg_dump -U postgres -F c -d backup_demo_db -f backup_demo_db.dump

Crea un altro database di restore:

createdb -U postgres backup_demo_custom_restore_db

Ripristina:

pg_restore -U postgres -d backup_demo_custom_restore_db backup_demo_db.dump

Controlla:

psql -U postgres -d backup_demo_custom_restore_db

SELECT * FROM notes;

Esegui manutenzione:

VACUUM ANALYZE;

Controlla la dimensione del database:

SELECT pg_size_pretty(pg_database_size(current_database()));

Questo è pratico.

Non è glamour.

È utile.

Come un buon cacciavite.

Di nuovo.

I database amano i cacciaviti.

Metaforicamente.

Mini sfida

Crea un piano di backup per un piccolo database blog.

Supponi:

nome database: blog_app_db
i dati cambiano ogni giorno
il blog è piccolo
perdere più di un giorno di dati è male
fai deploy ogni settimana

Scrivi un semplice piano di backup:

Frequenza backup:
Formato backup:
Posizione backup:
Conservazione:
Frequenza test restore:
Backup prima delle migration:
Chi può accedere ai backup:

Esempio di risposta:

Frequenza backup: giornaliera
Formato backup: formato custom con pg_dump -F c
Posizione backup: storage esterno sicuro
Conservazione: tenere backup giornalieri per 7 giorni e settimanali per 1 mese
Frequenza test restore: una volta al mese
Backup prima delle migration: sempre
Chi può accedere ai backup: solo l’amministratore

Ora crea un comando backup:

pg_dump -U postgres -F c -d blog_app_db -f blog_app_db_2026-05-03.dump

Crea un comando test restore:

createdb -U postgres blog_app_restore_test_db
pg_restore -U postgres -d blog_app_restore_test_db blog_app_db_2026-05-03.dump

Poi scrivi la query di controllo:

SELECT COUNT(*) FROM posts;

Così inizi a pensare come qualcuno responsabile dei dati.

Un po’ spaventoso.

Molto utile.

Molto adulto.

Riassunto

Oggi hai imparato:

Questa lezione è estremamente importante.

Forse non appariscente.

Ma importante.

Uno sviluppatore che sa creare tabelle è utile.

Uno sviluppatore che sa interrogare dati è meglio.

Uno sviluppatore che sa proteggere e ripristinare dati è molto più affidabile.

Perché i progetti reali non riguardano solo costruire.

Riguardano anche sopravvivere agli errori.

E i backup sono uno dei modi migliori per sopravvivere.

Riassunto del corso

Sei arrivato alla fine di questo corso PostgreSQL.

Hai imparato:

È tanto.

Non hai imparato solo comandi.

Hai imparato a pensare ai dati.

Questo conta.

Perché le applicazioni vanno e vengono.

I framework cambiano.

Le mode frontend cambiano ogni quindici minuti.

Ma i dati restano importanti.

PostgreSQL è uno strumento serio.

Ora sai abbastanza per iniziare a usarlo seriamente.

Con attenzione.

In modo pratico.

E con backup.

Sempre con backup.

Parole finali

PostgreSQL non sarà sempre facile.

A volte si lamenterà.

A volte rifiuterà la tua query.

A volte dirà:

syntax error at or near...

e tu fisserai una virgola per dieci minuti.

È normale.

Stai imparando uno strumento reale.

Uno strumento potente.

Uno strumento usato in applicazioni reali, aziende reali, API reali, dashboard reali e sistemi reali dove i dati contano.

Continua a praticare.

Crea piccoli progetti.

Rompi cose.

Ripristinale.

Scrivi query.

Usa EXPLAIN ANALYZE.

Fai backup.

Testa i backup.

Rispetta i dati.

E ricorda:

I browser dimenticano.
I database ricordano.
I backup perdonano.

Molto PostgreSQL.

Molto pratico.

Molto bene.