Come verificare un ripristino di Immich prima di dismettere il vecchio server

Non dismettere il vecchio server Immich solo perché la nuova dashboard si carica e le foto sono visibili. Dismettillo soltanto dopo che il sistema ripristinato avrà dimostrato il corretto funzionamento di utenti, album, persone, ricerca, originali campionati, nuovi caricamenti, processi in background, riavvii e di un nuovo backup, mentre il vecchio host rimane disponibile come destinazione per il rollback.

Mantieni il vecchio server spento ma invariato durante la convalida, così due istanze non accettano caricamenti su stati divergenti. Assegna inizialmente all’host ripristinato un indirizzo di test controllato, registra una baseline del vecchio sistema e confronta gli stessi flussi di lavoro domestici, invece di affidarti all’impressione visiva che la timeline sia completa.

Mantieni intatto il vecchio server mentre stabilisci una baseline del ripristino

Prima del passaggio, registra il numero di utenti e di risorse, alcuni album rappresentativi, le persone nominate, i preferiti, gli elementi condivisi, i percorsi delle librerie esterne e diversi originali campione appartenenti a date e utenti differenti. Registra anche le versioni di Immich e PostgreSQL del vecchio sistema e gli artefatti di backup utilizzati per il ripristino. I controlli di integrità delle cartelle o dello spazio di archiviazione sono criteri utili, ma non sostituiscono la verifica a livello di relazioni.

Il modello di ripristino di ZimaSpace per ripristinare una libreria fotografica ricercabile considera gli originali, lo stato del catalogo/database e la configurazione che definisce i percorsi come un’unica unità di ripristino. Questa è la baseline corretta, perché i soli file immagine non possono dimostrare che siano sopravvissute le relazioni relative all’appartenenza agli album, alla proprietà, alle persone e alla ricerca.

Non cancellare i dischi vecchi, non riutilizzare permanentemente il loro IP e non eliminare ancora l’ultimo backup noto come funzionante. L’obiettivo della verifica deve essere reversibile: se manca una relazione critica, devi poter utilizzare il vecchio stato per determinare se il problema deriva dal backup, dal metodo di ripristino, dalla mappatura dei percorsi o dal nuovo ambiente di esecuzione.

Verifica le relazioni, non solo la visibilità delle foto

Accedi con più di uno degli utenti previsti e verifica che ogni account visualizzi le risorse e le condivisioni corrette. Apri album noti, persone nominate, preferiti, ricordi o altre relazioni specifiche dell’ambiente domestico che sarebbe difficile ricostruire partendo dai soli file. Confronta un piccolo campione con la baseline registrata del vecchio server.

Una discussione sulla migrazione di Immich relativa alla scomparsa degli album dopo un ripristino di PostgreSQL dimostra perché questo aspetto è importante: le foto potevano rimanere mentre lo stato degli album era assente, e un successivo nuovo dump del database modificava il risultato. Consideralo come una prova del fatto che un accesso riuscito o una timeline visibile non costituiscono un test completo del ripristino.

Cerca diverse risorse note utilizzando i metadati e tutte le funzioni visive o relative alle persone abilitate. Se gli originali sono presenti ma mancano relazioni o risultati di ricerca, determina se lo stato pertinente avrebbe dovuto essere ripristinato oppure se deve essere rigenerato intenzionalmente. Non dismettere il vecchio server finché questa distinzione non sarà chiarita.

Metti alla prova i percorsi di lettura, scrittura, dipendenze e riavvio

Apri direttamente dal supporto di archiviazione ripristinato vecchie foto e video, quindi carica una nuova risorsa usa e getta da un client mobile o web. Conferma che il relativo originale venga scritto nel percorso previsto, che appaia per l’utente corretto e che i processi in background avanzino. Testa le librerie esterne e l’accesso remoto solo dopo che il percorso locale di lettura e scrittura è stabile.

Il test del ripristino deve convalidare l’applicazione dopo la copia dei dati. Un’attuale guida ai test di disaster recovery raccomanda una convalida a livello applicativo che includa database, autorizzazioni, connessioni di rete e servizi, invece di fermarsi a un processo di backup o ripristino completato. Riavvia lo stack Immich due volte e riavvia una volta il nuovo host. Dopo ogni ciclo, conferma che gli stessi mount, utenti, risorse campione, database, proxy o endpoint locale e comportamento dei processi tornino disponibili. Un servizio che funziona solo fino al primo riavvio dell’host non ha superato la migrazione.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Crea un nuovo backup prima di chiudere la finestra di rollback

Crea un nuovo backup coerente con il database e proteggi l’ambito di file multimediali e configurazione richiesto dal progetto di ripristino. Ripristina almeno un piccolo obiettivo di convalida oppure ispeziona il backup utilizzando lo stesso processo impiegato prima del passaggio. Un server ripristinato che non è in grado di produrre un proprio backup recuperabile non dovrebbe diventare l’unica copia di produzione.

Sottoponi il nuovo host a una finestra di osservazione definita che includa i normali caricamenti dal telefono, la consultazione, la ricerca, l’elaborazione in background, il backup pianificato e almeno un ciclo notturno. Mantieni spento il vecchio host per evitare che lo stato si divida, ma conservalo invariato finché il nuovo sistema non avrà superato questi eventi senza differenze inspiegabili.

La decisione di procedere richiede relazioni critiche corrispondenti, originali leggibili, nuove scritture riuscite, riavvii stabili e un nuovo backup verificato.

Se gli utenti scompaiono, i conteggi divergono in modo significativo, ricompaiono errori nei percorsi o il database segnala problemi di coerenza, spegni la nuova istanza e preserva entrambi i lati prima di indagare. Solo allora dovrai cancellare o riutilizzare il vecchio server.