Come fare il backup e ripristino di Immich su VPS

Cosa deve contenere un backup di Immich

Un backup di Immich comprende tre elementi acquisiti nello stesso momento. Gli originali in UPLOAD_LOCATION. Un dump SQL del database Postgres. .env e docker-compose.yml che descrivono lo stack. Il ripristino consiste nel reinserire il dump in un database nuovo mentre il server Immich è arrestato, quindi nell'avviare il resto dello stack solo dopo questa operazione. Se si inverte l'ordine, ci si ritrova con un'istanza Immich funzionante che mostra una timeline vuota sopra un disco pieno.

La separazione è importante perché Immich conserva lo stato in due posizioni che non hanno informazioni reciproche. Postgres contiene ogni album, ogni raggruppamento di volti, ogni link condiviso, ogni account utente e chiave API, oltre al percorso memorizzato di ogni asset. Il filesystem contiene i pixel. Se si ripristinano i file senza il database, Immich non mostra nulla. Se si ripristina il database senza i file, ogni asset si apre come immagine non disponibile.

I comandi riportati qui fanno riferimento a Immich v3.1.0, la release corrente all'inizio di agosto 2026. Al 2026-10-21 la release corrente è v3.3.4, pubblicata il 2026-10-20, e il relativo file compose, l'immagine del database e i passaggi documentati per il backup e il ripristino corrispondono a quelli usati in questa pagina. Il progetto rilascia nuove versioni rapidamente e la procedura di backup documentata è cambiata più volte. Controllare quindi la versione effettivamente in esecuzione prima di copiare qualsiasi elemento. Se lo stack non è ancora attivo, iniziare da la guida all'installazione di Immich e poi tornare qui.

Identifica la destinazione dei percorsi

Due variabili in .env determinano tutto il contenuto di questa pagina. UPLOAD_LOCATION è la directory principale in cui Immich scrive tutti i file multimediali. DB_DATA_LOCATION è la directory dei dati di Postgres.

Il file example.env predefinito imposta UPLOAD_LOCATION=./library. È un valore predefinito fuorviante, perché Immich crea quindi una directory chiamata library al suo interno. Gli originali finiscono in ./library/library. Imposta invece un percorso assoluto, così uno script di backup non dipenderà mai dalla directory da cui lo esegui.

UPLOAD_LOCATION=/srv/immich/data
DB_DATA_LOCATION=/srv/immich/postgres
DB_USERNAME=postgres
DB_DATABASE_NAME=immich
IMMICH_VERSION=v3.1.0

All'interno di UPLOAD_LOCATION, Immich crea diverse directory. Tre contengono dati che nessun job può ricostruire:

• library: gli originali, organizzati secondo il template di archiviazione
• upload: gli originali non ancora spostati nella struttura del template e i caricamenti in corso
• profile: le immagini del profilo degli utenti

Se perdi library, la foto è persa. Immich non conserva in alcun altro punto una seconda copia dell'originale.

Perché copiare la directory dei dati di Postgres non è un backup

DB_DATA_LOCATION sembra un obiettivo semplice. È una directory, rsync la copierà e la copia termina senza errori. Se la copiate mentre Postgres è in esecuzione, la copia non è un backup. Se la copiate con Postgres arrestato, è un backup, ma fragile. I motivi sono due e potete osservare il fallimento di entrambi.

Il primo è l'incoerenza dei dati. Postgres scrive prima ogni modifica nel write-ahead log (WAL), quindi la applica più tardi ai file delle tabelle, durante un checkpoint. In ogni istante, quindi, i file presenti sul disco possono trovarsi in una fase intermedia. Una copia progressiva che richiede quattro minuti legge il primo file alle 02:00 e l'ultimo alle 02:04. Questi due file non appartengono alla stessa transazione. Quando avviate Postgres usando il risultato, il server rifiuta la copia durante l'avvio con PANIC: could not locate a valid checkpoint record oppure si avvia e termina alla prima lettura di una pagina danneggiata con invalid page in block 1234 of relation base/16384/.... Nessuno dei due casi può essere risolto usando quella copia.

Il secondo motivo riguarda la copia eseguita quando tutto è arrestato. PostgreSQL documenta una copia completa di una directory dei dati arrestata come backup valido, ma quella directory può essere aperta solo da binari che condividono il relativo formato di archiviazione. Immich fissa l'immagine del database tramite digest, attualmente ghcr.io/immich-app/postgres:14-vectorchord0.4.3-pgvectors0.2.0. Si tratta di Postgres 14 con le estensioni di ricerca vettoriale VectorChord, pgvector e pgvecto.rs integrate. Una release minor successiva di Postgres 14 può aprire la directory senza modificarla, ma una versione major diversa non può farlo. Devono inoltre essere presenti le estensioni da cui dipendono le tabelle, in versioni compatibili. L'host di ripristino deve eseguire un'immagine compatibile. Un dump SQL non ha questo vincolo: è testo e qualsiasi server compatibile può rieseguirlo.

pg_dump evita completamente il problema dell'incoerenza. Legge l'intero database all'interno di una singola snapshot MVCC (multi-version concurrency control), quindi vede il database esattamente come si trovava in un determinato istante, mentre le altre scritture continuano. Per questo non è necessario arrestare Postgres per eseguire il dump.

Cosa si può escludere dal backup

Questi elementi vengono rigenerati, quindi è possibile ometterli:

• thumbs: immagini di anteprima e miniature
• encoded-video: video transcodificati
• DB_DATA_LOCATION: ricostruito dal dump
• il volume Docker model-cache: modelli di machine learning, scaricati nuovamente quando necessario

Escluderli è un compromesso, non un vantaggio senza costi. Ricostruire miniature e transcodifiche per una libreria di grandi dimensioni richiede ore di CPU su un VPS di piccole dimensioni, mentre la timeline mostra segnaposto grigi per tutto il tempo. È possibile rieseguire queste operazioni da Administration > Jobs, impostando "Generate Thumbnails" e "Transcode Videos" in modo che vengano eseguite sulle risorse mancanti. Se la destinazione del backup ha spazio sufficiente, includerli evita di attendere la ricostruzione. Se si è vicini al limite di spazio, escluderli e pianificare la ricostruzione. Dimensionamento di una libreria Immich spiega quanto possono crescere queste directory rispetto agli originali.

È utile conoscere anche un'altra directory. UPLOAD_LOCATION/backups contiene i dump automatici del database creati da Immich, scritti ogni giorno alle 02:00 e conservati in numero massimo di 14; l'impostazione è disponibile in Administration > Settings > Database Dump Settings. Non comportano costi aggiuntivi e sono realmente utili. Si trovano però sullo stesso disco della libreria che proteggono, quindi sono utili in caso di una migrazione problematica, ma non in caso di guasto del server. Creare comunque un proprio dump, perché quello avviato manualmente viene creato nello stesso momento dello snapshot dei file a cui deve corrispondere.

Eseguire il dump del database

docker exec -t immich_postgres pg_dump --clean --if-exists \
  --dbname=immich --username=postgres \
  | gzip > /srv/immich/backup/immich.sql.gz

Sostituire immich e postgres con DB_DATABASE_NAME e DB_USERNAME se sono stati modificati. --clean --if-exists inserisce DROP ... IF EXISTS prima di ogni CREATE, quindi il dump viene ripristinato in un database che contiene già gli oggetti, invece di interrompersi al primo.

Ora vediamo il dettaglio che compromette silenziosamente gli script di backup. Questo comando è una pipeline e la shell restituisce lo stato di uscita dell'ultimo comando della pipeline. Se pg_dump non riesce, a causa di una password errata o perché il container non è in esecuzione, gzip riceve uno stream vuoto, scrive un file gzip perfettamente valido e termina con codice 0. Lo script registra il successo e ci si ritrova con un backup di 20 byte. Inserire pipefail all'inizio di ogni script di backup:

#!/usr/bin/env bash
set -euo pipefail

Controllare quindi il risultato, senza affidarsi al codice di uscita:

ls -lh /srv/immich/backup/immich.sql.gz
gunzip -c /srv/immich/backup/immich.sql.gz | head -n 3

La prima riga di un dump integro è -- PostgreSQL database dump. Un file di poche centinaia di byte indica un dump non riuscito, indipendentemente da quanto riportato dallo script.

Registrare quale release ha creato il dump, accanto al file, interrogando il server in esecuzione:

curl -fsS http://localhost:2283/api/server/version > /srv/immich/backup/immich-version.txt

Questo endpoint non richiede autenticazione e restituisce la release in esecuzione come numero major, minor e patch, quindi 3, 1 e 0 corrispondono a v3.1.0. Non affidarsi a .env per questo scopo, né a docker inspect --format '{{.Config.Image}}' immich_server, che restituisce soltanto il riferimento all'immagine configurato. Il file standard imposta IMMICH_VERSION=v3, un tag mobile che segue ogni release 3.x; quindi un record che termina con :v3 non indica quale build abbia effettivamente creato il dump. Fissare il tag esatto anche in .env.

Mettere in pausa il server, quindi creare uno snapshot con restic

I file in UPLOAD_LOCATION non sono immutabili mentre Immich è in esecuzione. Il server scrive i nuovi upload e il job del template di storage sposta i file tra le directory. Se uno strumento di backup legge un file durante la scrittura, salva quei byte come se fossero l’intero file, senza segnalare errori. Arrestare il container del server per tutta la durata dell’operazione:

docker stop immich_server

Lasciare immich_postgres in esecuzione, perché il dump ne ha bisogno. L’interfaccia web e l’app mobile restano offline finché il server non viene riavviato; su un’istanza domestica, alle 03:00, di solito non è un problema.

restic è adatto in questo caso perché deduplica e cifra i dati prima che lascino il server. Configurarlo in modo che utilizzi un repository che non si trova su questo server:

export RESTIC_REPOSITORY=sftp:backup@backup.example.com:/srv/restic/immich
export RESTIC_PASSWORD_FILE=/root/.restic-password
restic init

Lo storage a oggetti funziona nello stesso modo ed è la scelta migliore se si vuole mantenere la copia completamente fuori dal proprio hardware:

export RESTIC_REPOSITORY=s3:https://s3.example.com/immich-backup
export AWS_ACCESS_KEY_ID=your-access-key
export AWS_SECRET_ACCESS_KEY=your-secret-key
restic init

L’endpoint può essere un bucket MinIO gestito autonomamente su una seconda macchina oppure qualsiasi provider compatibile con S3. Un repository sullo stesso disco della libreria protegge da una cancellazione accidentale, ma da nient’altro.

Quindi creare lo snapshot, includendo esattamente ciò che serve:

restic backup \
  /srv/immich/backup/immich.sql.gz \
  /srv/immich/backup/immich-version.txt \
  /srv/immich/data/library \
  /srv/immich/data/upload \
  /srv/immich/data/profile \
  /srv/immich/.env \
  /srv/immich/docker-compose.yml
docker start immich_server

restic legge l’intero albero a ogni esecuzione, ma carica solo i blocchi che non ha già rilevato. Il primo snapshot trasferisce quindi l’intera libreria; ogni snapshot successivo trasferisce solo le nuove foto della giornata.

Conservazione e chiavi che devono essere archiviate altrove

restic forget --prune --keep-daily 7 --keep-weekly 5 --keep-monthly 12

forget rimuove gli snapshot dall'indice. --prune è la parte che elimina i dati ai quali quegli snapshot facevano da ultimo riferimento. Eseguite forget senza --prune e il costo dello storage non diminuirà mai.

I controlli della struttura sono rapidi, quindi eseguitene uno ogni settimana:

restic check

Questo verifica che i metadati del repository siano coerenti. Non legge i dati. Una volta al mese, rileggete un campione e confrontatelo con gli hash registrati:

restic check --read-data-subset=5%

Questo è l'unico controllo che rileva la corruzione silenziosa sul backend di storage, perché scarica blocchi reali e ne ricalcola i checksum. Un --read-data completo su una libreria di foto richiede il download dell'intero repository. Su uno storage a oggetti con tariffazione a consumo, il costo può essere significativo. Per questo, nella pratica si usa un sottoinsieme a rotazione.

Ora veniamo alla parte che spesso viene ignorata. La password di un repository restic non è recuperabile. Non esiste una procedura di reimpostazione e non è possibile aprire un ticket al supporto. Se l'unica copia si trova in /root/.restic-password sul server che state cercando di ripristinare, i backup sono dati cifrati inutilizzabili. Lo stesso vale per la chiave di accesso allo storage a oggetti e per DB_PASSWORD da .env. Conservateli tutti in un luogo che non dipenda dal funzionamento di questa macchina: su carta e in un cassetto, oppure in un password manager eseguito su hardware diverso. Se anche quel password manager è self-hosted, deve essere protetto nello stesso modo e il backup di Vaultwarden è un'attività separata.

Ripristinare Immich nell'ordine corretto

È l'ordine di ripristino a trasformare i buoni backup in timeline vuote. Seguire questa sequenza sul nuovo host.

Ripristinare prima la configurazione. Indica quale versione eseguire e a quali percorsi fare riferimento.

restic restore latest --target /restore \
  --include /srv/immich/.env \
  --include /srv/immich/docker-compose.yml \
  --include /srv/immich/backup

Bloccare la versione prima di avviare qualsiasi componente. Leggere immich-version.txt, impostare IMMICH_VERSION in .env sulla release esatta (v3.1.0 per major 3, minor 1, patch 0) e lasciare da parte per ora la release più recente. Immich non supporta il downgrade, nemmeno tra patch release. Se un server più recente viene avviato con un dump più vecchio ed esegue le relative migration, non è possibile tornare indietro.

Ripristinare i file multimediali.

restic restore latest --target /restore --include /srv/immich/data

Spostare quindi library, upload e profile in modo che si trovino direttamente all'interno del percorso indicato da UPLOAD_LOCATION su questo host. Il percorso dell'host può cambiare, perché il file compose associa quella directory a un percorso fisso all'interno del container. La struttura al suo interno non può cambiare.

Avviare solo il database. Lasciare DB_DATA_LOCATION vuoto affinché Postgres inizializzi un cluster nuovo.

cd /srv/immich
docker compose pull
docker compose create
docker start immich_postgres
docker exec immich_postgres pg_isready --username=postgres

pg_isready stampa accepting connections al termine della configurazione iniziale, che richiede alcuni secondi. docker compose create crea ogni container senza avviarlo, ed è proprio questo lo scopo del passaggio: il server Immich non deve ancora essere in esecuzione. Un server avviato con un database vuoto applica le migration, crea uno schema nuovo e chiede di creare un nuovo account amministratore. A quel punto si starebbe reinserendo un dump sotto un'applicazione già in esecuzione.

Reinserire il dump.

gunzip --stdout /restore/srv/immich/backup/immich.sql.gz \
  | sed "s/SELECT pg_catalog.set_config('search_path', '', false);/SELECT pg_catalog.set_config('search_path', 'public, pg_catalog', true);/g" \
  | docker exec -i immich_postgres psql --dbname=immich --username=postgres \
      --single-transaction --set ON_ERROR_STOP=on

Due elementi della procedura svolgono un lavoro essenziale. sed è presente perché pg_dump scrive un search_path vuoto nell'output come misura di sicurezza. In questo modo i nomi non qualificati presenti nel dump non possono risolversi in uno schema inatteso. I tipi per la ricerca vettoriale di Immich si trovano in public. Con un search path vuoto, il ripristino raggiunge la prima colonna dichiarata con un tipo vettoriale e psql si interrompe con ERROR: type "vector" does not exist. Ripristinare public nel search path risolve il problema.

--single-transaction --set ON_ERROR_STOP=on racchiude l'intero ripristino in una singola transazione che si interrompe al primo errore. Si ottiene un database completo oppure un database invariato. Senza questa opzione, un errore a metà procedura lascia un database che si avvia, accetta il login e ha perso un numero imprecisato di album, un problema che potrebbe essere scoperto settimane dopo.

Avviare ora tutti i componenti.

docker compose up -d
docker compose ps
docker logs -f immich_server

Attendere una riga di avvio simile a Immich Server is listening on, quindi aprire la porta 2283 ed effettuare il login con le credenziali precedenti, perché gli account utente sono stati ripristinati insieme al dump. Se invece la pagina di login propone di creare il primo account amministratore, il database non è stato ripristinato. Arrestare la procedura e leggere di nuovo l'output di psql.

Un'avvertenza sulle istruzioni ufficiali per il ripristino dalla riga di comando, che iniziano con docker compose down -v. -v rimuove i volumi con nome. Nel file compose predefinito UPLOAD_LOCATION e DB_DATA_LOCATION sono bind mount, quindi sopravvivono all'operazione. Se uno dei due è stato modificato trasformandolo in un volume con nome, quel comando elimina le foto. Leggere il file compose prima di eseguirlo.

Perché la timeline è vuota dopo un ripristino

La timeline viene ricavata dalle righe del database. Immich non esegue la scansione di upload/ all'avvio per riscoprire le foto, perché un file senza una riga non ha proprietario, data o album. Pertanto, il ripristino incompleto più comune consiste nel ripristinare i file ma non il database. Immich si avvia, crea uno schema vuoto e fornisce un'istanza funzionante che non contiene nulla, mentre il disco è pieno di foto. Non è stato perso nulla. Tuttavia, non è visibile nulla. La correzione consiste nel riprodurre il dump con il server arrestato, esattamente come indicato sopra.

La seconda variante è meno evidente. Il database viene ripristinato, la timeline si riempie di elementi, ma ogni risorsa non viene aperta. Questo significa che le righe puntano a file che il container non riesce a vedere, in genere perché library, upload e profile si trovano a un livello di directory di troppo dopo un restic restore --target /restore che nessuno ha spostato nella posizione corretta. Controlla dall'interno del container invece di procedere per tentativi:

docker exec immich_server ls /data

Il file compose fornito di serie monta UPLOAD_LOCATION in /data, quindi l'elenco dovrebbe mostrare library, upload e profile. Se mostra una directory vuota o una cartella srv estranea, il bind mount punta al livello sbagliato e le righe sono corrette.

Corrispondenza della versione tra backup e ripristino

Immich viene rilasciato frequentemente e lo schema cambia insieme al software. Un dump contiene quindi lo schema del server che lo ha creato.

Il ripristino di un dump precedente su un server più recente in genere funziona, perché il server applica all'avvio le migrazioni in sospeso e aggiorna progressivamente lo schema. Questo percorso viene verificato nella sequenza delle release. I problemi si verificano quando si saltano diverse versioni principali in un solo passaggio. Il progetto concentra le modifiche incompatibili nelle versioni principali e le documenta nel changelog.

Il ripristino di un dump più recente su un server precedente non funziona. Il dump contiene tabelle e colonne che il codice più vecchio non riconosce. Immich dichiara inoltre che il downgrade non è supportato nemmeno tra versioni patch. Non esiste un comando di rollback da utilizzare.

Il ripristino sicuro è quindi semplice. Esegui la versione esatta che ha creato il dump, ripristinalo, accedi e verifica che la timeline sia completa. Esegui l'upgrade solo dopo questi controlli. Aggiorna una release alla volta, incrementando IMMICH_VERSION ed eseguendo docker compose pull && docker compose up -d dopo ogni aggiornamento. Conservare i dump di una settimana è utile anche in questo caso: se l'ultimo è stato creato durante un upgrade non riuscito, quello del giorno precedente è ancora disponibile nel repository.

Verifica il backup ogni mese

Un backup che non hai mai ripristinato è solo un’ipotesi. Una volta al mese, ripristinalo in un’istanza temporanea e controlla una foto. La verifica richiede circa venti minuti ed è l’unico passaggio che trasforma il resto di questa pagina in un piano di ripristino.

restic snapshots
restic stats latest

snapshots dovrebbe elencare l’esecuzione della scorsa notte. stats latest dovrebbe riportare una dimensione vicina a quella della tua libreria, non pochi megabyte.

Ripristina il backup in una directory temporanea, preferibilmente su un host di riserva:

restic restore latest --target /tmp/immich-drill

Copia docker-compose.yml e .env fuori dall’insieme ripristinato, quindi modifica tre elementi nella copia. Imposta UPLOAD_LOCATION e DB_DATA_LOCATION su directory sotto /tmp/immich-drill. Pubblica la porta web su un’altra porta, 12283:2283 invece di 2283:2283. Elimina le righe container_name:, perché il file compose predefinito codifica nomi come immich_server: un secondo stack sullo stesso host entrerebbe in conflitto con il primo e Docker rifiuterebbe di crearlo.

Esegui la procedura di ripristino descritta sopra: solo il database, riproduci il dump, quindi docker compose up -d. Ora esegui i quattro controlli che dimostrano che il ripristino è riuscito.

1. Accedi con la password che usavi prima della verifica. Se gli account funzionano, il dump è stato ripristinato.
2. Apri la timeline e scorri fino al mese più remoto. Se sono presenti risorse sull’intero intervallo di date, significa che sono state ripristinate tutte le righe, non solo quelle recenti.
3. Apri una foto a dimensione originale e scarica il file originale.
4. Confrontalo con lo stesso file nella libreria in produzione usando sha256sum. Se gli hash corrispondono, i byte hanno superato correttamente il ciclo di ripristino tramite restic.

Al termine, rimuovi l’ambiente della verifica con docker compose down -v nella directory usata per la verifica ed elimina /tmp/immich-drill. Annota la data in un punto visibile, perché il valore di questa procedura dipende interamente dal ripeterla il mese prossimo. Se stai ancora decidendo quale photo server adottare, il confronto tra PhotoPrism e Immich spiega in che modo i due prodotti differiscono proprio su questo aspetto.

FAQ

Devo arrestare Immich per eseguire il backup?

Arrestare immich_server e lasciare immich_postgres in esecuzione. Il database non deve essere messo in pausa, perché pg_dump legge all'interno di uno snapshot MVCC e vede un singolo istante coerente, indipendentemente dalle altre operazioni di scrittura. Il motivo per cui è necessario arrestare il server riguarda i file: il server scrive i nuovi upload e il job del template di storage sposta i file tra le directory. Uno strumento di backup può quindi leggere un file mentre è ancora in scrittura e salvare una copia troncata senza segnalare errori. Eseguire docker stop immich_server prima dello snapshot e docker start immich_server dopo lo snapshot elimina questa condizione di gara.

Posso copiare la directory dei dati di Postgres invece di eseguire pg_dump?

Non mentre Postgres è in esecuzione. Una copia progressiva di una directory dati attiva legge file diversi in istanti diversi. Il risultato non rappresenta quindi uno stato coerente. Postgres la rifiuta all'avvio con PANIC: could not locate a valid checkpoint record oppure rileva in seguito una pagina danneggiata. Una copia completa eseguita con Postgres arrestato è un backup valido, ma può essere aperta solo dalla stessa versione major di Postgres e con estensioni compatibili. Immich fissa un'immagine Postgres 14 che include VectorChord, pgvector e pgvecto.rs. La directory non può essere aperta con una versione major diversa. Un dump SQL è testo normale e può essere riprodotto su qualsiasi server compatibile. È quindi questa la copia da conservare.

Perché la timeline di Immich è vuota dopo un ripristino?

Perché la timeline viene costruita a partire dalle righe del database e hai ripristinato i file senza il database. Immich non esegue mai la scansione di upload/ per riscoprire le foto. I file privi di righe corrispondenti rimangono quindi invisibili. Le foto non sono state modificate. Arresta il server, riproduci il dump in un Postgres appena inizializzato, quindi avvia lo stack. Se invece la timeline è completa ma ogni foto non si apre, il problema è opposto: library, upload e profile non si trovano direttamente all'interno della directory associata al container. Verificalo con docker exec immich_server ls /data.

Quali directory di Immich posso escludere dal backup?

thumbs e encoded-video possono essere rigenerate dagli originali, mentre DB_DATA_LOCATION viene ricostruita dal dump. Nessuna di queste directory deve quindi essere inclusa nel set di backup. Escluderle sposta il tempo necessario dopo il ripristino invece di consumare spazio prima del ripristino. Per una libreria di grandi dimensioni, infatti, la ricostruzione di anteprime e transcodifiche richiede ore di CPU. L'operazione viene eseguita da Administration > Jobs sugli asset mancanti. Non puoi mai escludere library, upload e profile, che contengono l'unica copia di ogni originale.

Posso ripristinare un dump di Immich in una versione più recente?

Di solito sì, perché il server applica all'avvio le migrazioni in sospeso e aggiorna progressivamente lo schema. Il percorso inverso non funziona: Immich non supporta il downgrade, nemmeno tra release di patch. Un dump proveniente da una release più recente non può quindi essere caricato in un server più vecchio. Esegui il ripristino con IMMICH_VERSION fissato alla release che ha creato il dump, verifica che la timeline sia completa, quindi esegui l'upgrade. Registra la release accanto a ogni dump con curl -fsS http://localhost:2283/api/server/version, perché docker inspect visualizza soltanto il riferimento all'immagine configurato e IMMICH_VERSION=v3, il valore predefinito, è un tag mobile che non fornisce alcuna informazione utile.