Immich self-hosting: RAM minima e guida agli upgrade

Cosa stai configurando

Immich è un servizio self-hosted per il backup di foto e video, una vera alternativa a Google Photos. Dispone di un'app per smartphone che carica in background il rullino fotografico, di una timeline, degli album, del riconoscimento dei volti e di una ricerca basata sul machine learning, che trova "beach" o una persona senza richiedere l'aggiunta manuale di tag. Lo esegui su un VPS di tua proprietà, i file originali restano sul tuo disco e nessuno li analizza per venderti prodotti. Se stai ancora confrontandolo con l'altro candidato più ovvio, il nostro confronto tra PhotoPrism e Immich mette a confronto requisiti minimi di RAM, app per smartphone e comandi di backup.

L'installazione consiste in quattro container definiti dal file Docker Compose del progetto. Questa parte richiede dieci minuti. Il resto di questa guida riguarda gli aspetti più problematici: il container di machine learning richiede molta memoria su una macchina di piccole dimensioni, gli originali consumano rapidamente lo spazio su disco, l'app mobile richiede l'URL esatto del server e vuoi configurare HTTPS davanti al servizio prima di esporlo al di fuori della tua rete; inoltre, Immich introduce breaking change abbastanza spesso da permettere a un docker compose pull eseguito senza attenzione di impedire l'avvio del server. Gestisci seriamente questi quattro aspetti e Immich sarà molto stabile. Ignorali e perderai un fine settimana.

Prerequisiti e aspetti da considerare

• RAM: la documentazione ufficiale indica 6 GB come minimo e 8 GB come quantità consigliata; considera 4 GB più swap come limite minimo assoluto. I container immich-server e Postgres hanno consumi contenuti. Il container immich-machine-learning è quello che utilizza più memoria: carica in RAM i modelli CLIP e di riconoscimento facciale per creare gli indici di ricerca e, su un server con 2 GB, il kernel lo termina. Aggiungi lo swap anche se disponi di 4 GB.
• Disco: dimensiona lo spazio per l'intera libreria e aggiungi un margine. Gli originali vengono copiati integralmente e Immich genera anche miniature e immagini di anteprima, con un consumo aggiuntivo di circa il 10–20%. Una raccolta fotografica di 200 GB richiede un volume da 300 GB. Postgres occupa molto meno spazio.
• CPU: qualsiasi VPS KVM moderno è adatto, ma il machine learning eseguito sulla CPU è lento. L'indicizzazione per la ricerca intelligente di una grande importazione può richiedere ore ed essere eseguita in background. È normale; non è necessaria una GPU.
• Un nome di dominio che punti al VPS. L'app mobile preferisce nettamente un endpoint HTTPS e conviene usare un reverse proxy davanti al servizio. La struttura è la stessa di una istanza Nextcloud self-hosted con Docker, TLS e backup: Immich è l'equivalente per le foto di quel server per i file.
• Docker e il plugin Compose installati: Docker Engine e il plugin Compose v2 provenienti dal repository apt ufficiale di Docker, esattamente come descritto nella nostra guida introduttiva a Docker Compose.

Passaggio 1: aggiungere lo swap prima di qualsiasi altra operazione

Il problema più comune di Immich su un VPS di piccole dimensioni è la terminazione forzata del container ML per esaurimento della memoria. Prima di procedere, mettete a disposizione del kernel memoria aggiuntiva.

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
free -h

free -h dovrebbe ora mostrare una riga Swap: di 4.0Gi. Questo non renderà ML più veloce e rappresenta un buffer, non una garanzia, ma riduce notevolmente la probabilità che il container si arresti durante l'indicizzazione su una macchina con 4 GB.

Passaggio 2: Scarica i file compose ed env ufficiali e usa quelli, senza copiarli

Immich blocca le versioni dei servizi e, soprattutto, l'immagine del database nei file inclusi nei rilasci. Non usare come riferimento un file compose copiato da un blog, incluso questo. Scarica gli asset del rilascio:

sudo mkdir -p /opt/immich && cd /opt/immich
sudo wget -O docker-compose.yml https://github.com/immich-app/immich/releases/latest/download/docker-compose.yml
sudo wget -O .env https://github.com/immich-app/immich/releases/latest/download/example.env

Questi file provengono dal rilascio contrassegnato, quindi i riferimenti alle immagini sono coerenti. Il file compose definisce quattro servizi. Prima di modificarlo, è utile sapere a cosa serve ciascuno:

• immich-server (ghcr.io/immich-app/immich-server, container immich_server), l'API e l'interfaccia web, in ascolto sulla porta 2283. Monta i caricamenti nel percorso /data.
• immich-machine-learning (ghcr.io/immich-app/immich-machine-learning, container immich_machine_learning), per la ricerca CLIP e il riconoscimento facciale. Memorizza nella cache i modelli scaricati in un volume model-cache. È il servizio che utilizza più memoria.
• database (container immich_postgres), Postgres con l'estensione vettoriale VectorChord, che abilita la ricerca per similarità. Il tag dell'immagine è bloccato tramite digest direttamente nel file compose, ad esempio ghcr.io/immich-app/postgres:14-vectorchord0.4.3-pgvectors0.2.0@sha256:.... Le configurazioni meno recenti usavano pgvecto.rs; il supporto è stato rimosso in Immich v3.0, quindi tutte le installazioni attuali usano VectorChord. Non modificare manualmente questo tag.
• redis (container immich_redis), un'istanza Valkey/Redis per le code dei job.

Passaggio 3: configura .env, dove risiedono le foto e il database

Apri .env e imposta quattro valori. Lascia invariato tutto ciò che si trova sotto la riga contrassegnata.

# Where original uploads are stored on the host
UPLOAD_LOCATION=/opt/immich/library

# Where the Postgres data lives. NEVER put this on an NFS/network share.
DB_DATA_LOCATION=/opt/immich/postgres

# "v3" is a floating tag that tracks the latest v3.x. Pin a full tag like
# v3.0.2 instead; then you upgrade on purpose, not by surprise.
IMMICH_VERSION=v3.0.2

# Change this to a long random string. Letters and digits only.
DB_PASSWORD=REPLACE_WITH_A_LONG_RANDOM_STRING

# Set your timezone so timestamps and "on this day" line up
TZ=Europe/London

###################################################################################
DB_USERNAME=postgres
DB_DATABASE_NAME=immich

Due regole evitano problemi. UPLOAD_LOCATION deve puntare al disco più capiente. Se in seguito colleghi un volume dati, impostalo fin dall'inizio sul relativo percorso di mount, perché spostarlo successivamente significa trasferire le miniature e aggiornare i percorsi degli asset. Inoltre, DB_DATA_LOCATION deve trovarsi su un disco locale: PostgreSQL si danneggia se utilizza una condivisione NFS o SMB, come indicato chiaramente nella documentazione. Usa solo lettere e cifre in DB_PASSWORD per evitare una classe di problemi di escape nelle stringhe di connessione.

Passaggio 4: primo avvio e creazione dell'utente amministratore

cd /opt/immich
sudo docker compose up -d
sudo docker compose ps

Il risultato corretto è costituito da quattro container, tutti running e infine healthy:

NAME                      STATUS
immich_machine_learning   Up (healthy)
immich_postgres           Up (healthy)
immich_redis              Up (healthy)
immich_server             Up (healthy)

Il primo up scarica diversi gigabyte di immagini, quindi attendi il completamento. Monitora l'avanzamento con sudo docker compose logs -f immich-server; quando è pronto, il server registra nei log che è in ascolto sulla porta 2283. Ora apri http://YOUR_SERVER_IP:2283 in un browser. Alla prima visita viene visualizzata una procedura guidata Getting Started. Il primo account creato è l'account amministratore. Imposta una password complessa: questo account gestisce le impostazioni del server, gli utenti e la configurazione ML che ti servirà più avanti.

Passaggio 5: app mobile e backup in background

Installa "Immich" dall'App Store o dal Play Store. Nella schermata di accesso viene richiesto un URL endpoint del server. Inserisci l'URL completo, incluso lo schema, ad esempio https://photos.example.com (l'app aggiunge automaticamente /api). Accedi con l'account appena creato, quindi apri la schermata Backup dell'app, seleziona gli album da proteggere, in genere Camera e Screenshots, e attiva Backup in background. Su iOS il backup in background è limitato dal sistema operativo. I caricamenti in primo piano vengono sempre eseguiti, mentre quelli in background vengono eseguiti quando il sistema operativo lo consente.

È proprio in questo punto che molti utenti incontrano problemi. Leggi il Passaggio 6 prima di cercare di risolverli nell'app.

Passaggio 6: HTTPS tramite un reverse proxy e regola dell'URL completo

L'app mobile richiede HTTPS quando lascia la rete domestica. Posiziona un reverse proxy davanti alla porta 2283 e termina lì TLS. Se esegui già diversi container, Traefik con TLS automatico per più applicazioni Docker è l'opzione più ordinata: un unico blocco di label instrada photos.example.com al container immich-server e recupera automaticamente il certificato. Se preferisci nginx, la guida Let's Encrypt con Certbot e nginx consente di ottenere un certificato e un blocco proxy_pass http://127.0.0.1:2283;. Una volta configurato il proxy, aggiungere il servizio successivo richiede soprattutto un nuovo sottodominio. È così che un'interfaccia multimediale come Halcyon, il tema da videonoleggio anni 90 per Jellyfin può affiancarsi a Immich sullo stesso server. Lo stesso vale per un HarnessRouter self-hosted che espone Codex e Claude Code tramite un'unica API, che si associa volutamente all'interfaccia di loopback e diventa raggiungibile soltanto quando il proxy termina TLS davanti al servizio. Modifica quindi il login predefinito prima di associargli un sottodominio. Tuttavia, non tutti i container devono avere un hostname pubblico. Uno strumento riservato agli amministratori, come uno scanner di sicurezza open-kritt self-hosted, è preferibile lasciarlo completamente fuori dal proxy e raggiungerlo tramite un tunnel SSH nelle rare occasioni in cui apri la relativa interfaccia. Altri servizi non usano il proxy perché HTTP non è il protocollo previsto. Un server relay RustDesk self-hosted è l'esempio più chiaro: resta in ascolto su alcune porte TCP e UDP non incapsulate e richiede regole del firewall, non un sottodominio. Per Immich è importante un'impostazione del proxy: aumenta il limite delle dimensioni di upload, perché i video acquisiti dal telefono possono essere grandi. In nginx l'impostazione è client_max_body_size 50000M; all'interno del blocco server. Il valore predefinito di 1 MB rifiuta i caricamenti video con 413 Request Entity Too Large. Se il proxy risponde anche alle challenge HTTP-01 di Let's Encrypt, verifica che /.well-known/immich continui a essere instradato verso Immich e non verso il gestore delle challenge.

La regola applicata dall'app è la seguente: l'endpoint deve essere raggiungibile esattamente all'URL immesso. L'app accetta un semplice http://YOUR_SERVER_IP:2283, come indicato dal relativo suggerimento di login http://your-server-ip:port, ma tutto ciò che attraversa Internet deve usare HTTPS. Lo schema errato, oppure un indirizzo IP diretto senza specificare la porta, causa l'errore "l'app non riesce a raggiungere il server", descritto più avanti come problema specifico.

Passaggio 7: librerie esterne e caricamenti, importare un albero di foto esistente

Esistono due modalità per importare le foto in Immich e non sono equivalenti.

• I caricamenti sono risorse gestite da Immich. L'applicazione o il caricatore web copia il file in UPLOAD_LOCATION. Immich può rinominarli, spostarli ed eliminarli.
• Le librerie esterne sono importazioni in sola lettura di file già presenti in una directory del server, in un vecchio albero Pictures o in un'esportazione da un NAS. Immich li indicizza nella posizione originale e li mostra nella timeline, ma non modifica né elimina mai gli originali.

Per importare un albero esistente, montalo in sola lettura nel container del server. Modifica docker-compose.yml in immich-server: e aggiungi un volume:

  immich-server:
    volumes:
      - ${UPLOAD_LOCATION}:/data
      - /etc/localtime:/etc/localtime:ro
      - /srv/photos:/mnt/media/photos:ro

:ro garantisce che Immich non possa mai modificare gli originali. Ricrea il container con sudo docker compose up -d, quindi nell'interfaccia web vai al tuo avatar → Amministrazione → Librerie esterne → Crea libreria, seleziona l'utente proprietario, fai clic su Aggiungi nella sezione Cartelle e inserisci il percorso nel container, /mnt/media/photos, non il percorso dell'host /srv/photos. Fai clic su Scansiona. Usare il percorso dell'host invece di quello del container è l'errore più comune con le librerie esterne: la scansione non trova nulla e segnala zero risorse. Se il tuo albero è organizzato in sottocartelle annidate, non aspettarti di ritrovarle come sottoalbum, perché Immich non li supporta: le alternative agli album annidati in Immich spiega come ricostruire quella struttura con la vista Cartelle, i tag gerarchici o album creati a partire dalle cartelle.

Passaggio 8: La disciplina degli aggiornamenti richiesta da Immich

Questa è la parte che distingue un'istanza Immich funzionante da una non funzionante. Immich rilascia rapidamente e non esegue il backport delle correzioni né supporta i downgrade. Il tag v3 mobile, che si sposta automaticamente sull'ultima versione v3.x disponibile, è un metodo ufficialmente supportato per seguire le release. Immich cerca di limitare le modifiche incompatibili alle versioni principali, ma esegue l'aggiornamento ogni volta che effettui un pull, indipendentemente dal fatto che tu abbia letto o meno le note. Un aggiornamento non pianificato non può essere annullato. La stessa abitudine di fissare una versione e leggere le note conviene applicarla a ogni container a lunga esecuzione sul server. Per questo un agente KiroCrew self-hosted viene fissato a un tag noto e verificato invece di consentirgli di cambiare versione al successivo riavvio. La procedura è questa:

1. Fissa una versione. Mantieni IMMICH_VERSION impostato su un tag concreto come v3.0.2, non su v3, che esegue sempre il pull della versione v3.x più recente.
2. Leggi sempre le note di rilascio prima di eseguire l'aggiornamento. Le modifiche incompatibili, in particolare quelle relative al database o alle estensioni vettoriali, sono indicate nelle note. La release v3.0 è l'esempio più evidente: ha rimosso completamente pgvecto.rs, quindi chi utilizzava ancora la vecchia estensione doveva completare la migrazione a VectorChord, introdotta già nella v1.133, prima di poter eseguire l'aggiornamento.
3. Esegui prima il backup del database (Passaggio 9). Sempre, ma a maggior ragione quando le note fanno riferimento al database.
4. Scarica anche il nuovo file compose. IMMICH_VERSION fissa soltanto le immagini del server e di ML. L'immagine Postgres è fissata tramite digest all'interno di docker-compose.yml. Di conseguenza, una versione che richiede un'estensione del database più recente viene distribuita con un nuovo file compose. Scarica nuovamente entrambi gli asset della release, riapplica i valori di .env, quindi esegui l'aggiornamento.
5. Aggiorna prima i client mobili. Il server comunica soltanto con la versione principale corrispondente, mentre l'app è in genere compatibile con la versione principale corrente e con quella precedente. Quando il server è più recente dell'app, le release correnti (v3.3.1, verificate il 2026-10-10) mostrano sul telefono l'avviso È disponibile un aggiornamento dell'app con un pulsante Aggiorna. Immich raccomanda di aggiornare tutti i client mobili prima del server.

I comandi effettivi, dopo aver collocato i nuovi file:

cd /opt/immich
sudo docker compose pull
sudo docker compose up -d
sudo docker image prune

Passaggio 9: backup, dump del database e file originali, quindi test del ripristino

Un backup di Immich comprende due elementi, e uno senza l’altro è inutilizzabile. Il database contiene la struttura degli album, i volti, gli indici di ricerca e la corrispondenza tra ogni risorsa e il relativo file. La directory degli originali contiene le foto effettive. Se ripristini un elemento senza l’altro, ottieni foto prive di organizzazione oppure una struttura vuota che punta a file mancanti. Questa struttura in due parti non è una particolarità di Immich: un help desk Chatwoot self-hosted richiede la stessa combinazione di un dump Postgres e della relativa directory degli upload, altrimenti la posta in arrivo ripristinata torna con tutti gli allegati mancanti. Copiare la directory dei dati di Postgres come albero di file sembra una scorciatoia per evitare il dump, ma non costituisce un backup utilizzabile: è una trappola che la guida completa al backup e al ripristino di Immich illustra insieme all’errore di ripristino che lascia una timeline vuota.

Esegui il dump del database con pg_dump dall’interno del container Postgres, specificando il database immich, non l’intero cluster:

sudo docker exec -t immich_postgres pg_dump --clean --if-exists \
  --dbname=immich --username=postgres | gzip > /opt/immich/immich-db-$(date +%F).sql.gz

Esegui quindi il backup di UPLOAD_LOCATION, dell’intero albero /opt/immich/library e in particolare delle sottodirectory library/, upload/ e profile/, usando restic, rsync o borg verso un’altra macchina o un object storage. Qualunque sistema pianifichi questo lavoro, un cron entry o un timer systemd, deve avere un punto in cui segnalare gli errori. Un’unità systemd OnFailure= configurata per usare il tuo server push ntfy invia un messaggio al telefono quando un dump non riesce, invece di lasciarti scoprire il problema durante un ripristino. Esegui prima il backup del database e poi quello dei file, così il dump non farà mai riferimento a una foto che il backup dei file non ha ancora copiato. Esegui il backup delle librerie esterne separatamente, alla loro origine effettiva: Immich non ne è il proprietario.

Ora arriva la parte che tutti saltano: testa il ripristino. Il ripristino deve essere eseguito su uno stack nuovo, il cui server non sia mai stato avviato, usando un’immagine Postgres con un’estensione vector compatibile con il dump. È esattamente per questo che non devi improvvisare il tag dell’immagine DB. Su una macchina di test con lo stesso compose e .env, elimina ogni stato precedente, avvia solo il database, quindi carica il dump:

cd /opt/immich
sudo docker compose down -v
sudo docker compose pull
sudo docker compose create
sudo docker start immich_postgres
sleep 10
gunzip --stdout immich-db-2026-07-15.sql.gz |
  sed "s/SELECT pg_catalog.set_config('search_path', '', false);/SELECT pg_catalog.set_config('search_path', 'public, pg_catalog', true);/g" |
  sudo docker exec -i immich_postgres psql --dbname=immich --username=postgres --single-transaction --set ON_ERROR_STOP=on
sudo docker compose up -d

La riscrittura di search_path con sed non è facoltativa su un database VectorChord: se la ometti, il ripristino si interrompe a metà. Quando lo stack torna operativo con gli originali al loro posto, apri la web UI: se le foto e gli album sono presenti, il backup funziona. Se non hai mai eseguito questa procedura, non hai un backup: hai solo una speranza.

Modalità di errore e stringhe visualizzate

Il container ML viene terminato per esaurimento della memoria. sudo docker compose logs immich-machine-learning si interrompe bruscamente, docker compose ps mostra Restarting e il codice di uscita è 137. sudo dmesg | grep -i oom lo conferma: Out of memory: Killed process ... (python3). I processi di ricerca e riconoscimento facciale rimangono quindi bloccati. La causa è una quantità insufficiente di RAM per i modelli. Procedere, nell'ordine, come segue: aggiungere swap (Passaggio 1); assegnare più RAM alla VPS; oppure, se non è realmente possibile, aprire Administration → Settings → Machine Learning Settings e disattivare l'opzione di primo livello per il machine learning. Questa operazione disabilita tutte le funzionalità ML. Disattivare solo Smart Search e Facial Recognition non è sufficiente, perché OCR e gli altri tipi di modello rimangono abilitati per impostazione predefinita. I backup e gli album rimangono disponibili, ma si perde la ricerca in base al contenuto. Rimuovere il servizio immich-machine-learning dal file compose produce lo stesso effetto.

Il server Immich non si avvia dopo un aggiornamento. Il container Postgres può essere in esecuzione senza problemi; è immich_server a controllare la versione dell'estensione vettoriale all'avvio e a rifiutarsi di partire. Nel log viene ripetuta una riga come The database currently has VectorChord 0.5.3 activated, but the Postgres instance only has 0.4.2 available. This most likely means the extension was downgraded. oppure, negli stack meno recenti, The pgvecto.rs extension is not available in this Postgres instance.. La causa è un'immagine del database con una versione dell'estensione precedente a quella a cui sono stati aggiornati i dati. Questo accade quasi sempre dopo aver modificato manualmente il tag dell'immagine oppure ripristinato un dump più recente su un'immagine meno recente. La soluzione consiste nell'utilizzare l'immagine Postgres corrispondente, recuperare il file compose dalla release compatibile con il database, non eseguire il downgrade e ripristinare i dati solo su un'immagine compatibile.

L'app mobile non riesce a raggiungere il server. Dopo l'inserimento dell'URL, la schermata di accesso mostra un errore di connessione come Could not connect to server. Le cause più comuni sono: è stato inserito http://, mentre il proxy pubblica soltanto https://; ci si è connessi direttamente al backend senza specificare la porta, quindi l'app ha provato example.com (porta 443) invece di example.com:2283; il reverse proxy non inoltra /api; oppure un proxy che gestisce le challenge HTTP-01 di Let's Encrypt instrada /.well-known/immich verso una destinazione diversa da Immich. Inserire l'URL https://photos.example.com completo e verificare prima che venga caricato nel browser del telefono. Se il browser funziona ma l'app no, il proxy sta rimuovendo il percorso o instradando /.well-known/immich in modo errato. In alternativa, il certificato è autofirmato e l'app lo rifiuta con un errore di handshake, a meno che nelle impostazioni non sia abilitato il supporto per i certificati autofirmati.

Spazio su disco esaurito durante l'importazione. I caricamenti iniziano a non riuscire, le miniature diventano vuote e nei log compaiono ENOSPC: no space left on device oppure, da Postgres, could not extend file ... No space left on device. df -h mostra che il volume UPLOAD_LOCATION è pieno al 100%. Per questo è necessario dimensionare lo spazio su disco prima di importare una libreria di grandi dimensioni. Per il ripristino, collegare un volume più capiente, arrestare lo stack, spostare UPLOAD_LOCATION sul nuovo volume, aggiornare .env e riavviare. In alternativa, espandere il disco esistente se il provider lo consente. Se lo spazio si esaurisce, Postgres può bloccarsi. Liberare spazio e riavviare il container del database prima di considerare l'ipotesi di una corruzione.

FAQ

Quanta RAM e spazio su disco richiede Immich?

I requisiti ufficiali di Immich indicano almeno 6 GB di RAM e 8 GB consigliati; per una libreria ridotta, 4 GB con swap sono il minimo pratico. Configurate comunque la swap, perché il container di machine learning è il componente che può generare i picchi di utilizzo. Per lo spazio su disco, considerate le dimensioni dell'intera libreria più circa il 10–20% per miniature e anteprime generate, su storage locale. Non mettete mai la directory dei dati di Postgres su una condivisione di rete. Se state ancora decidendo quali altri servizi eseguire, la guida a cosa eseguire in self-hosting nel 2026 confronta l'occupazione di Immich con quella di altri servizi.

Posso eseguire Immich senza una GPU?

Sì. Il container di machine learning funziona senza problemi sulla CPU. Una GPU accelera soltanto l'indicizzazione per la ricerca intelligente e, con la variante di immagine corretta, la transcodifica video. Sulla CPU, l'indicizzazione iniziale di una libreria di grandi dimensioni può richiedere ore in background, ma non blocca i backup né la consultazione. Se il server è troppo limitato per eseguire il machine learning, potete disattivarlo completamente tramite l'opzione di livello superiore nelle impostazioni di amministrazione e mantenere attive tutte le altre funzioni.

Come aggiorno Immich in sicurezza?

Bloccate IMMICH_VERSION su un tag concreto, ad esempio v3.0.2, leggete le note di rilascio prima di ogni aggiornamento ed eseguite prima il backup del database. Poiché l'immagine Postgres è bloccata all'interno di docker-compose.yml anziché tramite IMMICH_VERSION, scaricate nuovamente sia il file compose sia example.env dalla release di destinazione, riapplicate i vostri valori, quindi eseguite docker compose pull && docker compose up -d. Non lasciate mai la versione non vincolata senza supervisione. Immich non supporta il downgrade, quindi non è possibile annullare un aggiornamento eseguito senza averne verificato prima i dettagli.

Che cosa devo includere esattamente nel backup?

Due elementi, insieme: un pg_dump del database immich e l'intera directory degli originali UPLOAD_LOCATION. Il database contiene album, volti e la corrispondenza tra asset e file; la directory contiene le foto effettive. Per un ripristino servono entrambi, oltre a un'immagine del database con un'estensione vettoriale compatibile. Eseguite prima il dump del database e poi la copia dei file. Testate il ripristino almeno una volta su un server di prova: un backup non verificato non è un backup.

Come importo una cartella di foto esistente?

Montate la cartella in sola lettura nel container immich-server come volume aggiuntivo, ad esempio - /srv/photos:/mnt/media/photos:ro, ricreate il container, quindi in Amministrazione → Librerie esterne create una libreria e aggiungete il percorso nel container /mnt/media/photos. Immich indicizza i file nella posizione originale e non li modifica né li elimina. L'errore più comune consiste nell'inserire il percorso dell'host invece di quello del container, impedendo alla scansione di trovare i file.