Flusso di lavoro per l'integrità della libreria fotografica self-hosted di originali e derivati

Una timeline fotografica dall’aspetto integro non dimostra che gli originali, il database e le anteprime generate siano tutti intatti.

Una galleria self-hosted può continuare a fornire miniature memorizzate nella cache anche dopo la scomparsa di un originale, oppure conservare originali perfetti mentre i worker non riescono a generare nuovi derivati. Separare lo stato necessario da quello ricostruibile, verificare i byte degli originali al di fuori dell’app, riconciliare i file con i record del database e rigenerare un solo elemento canary prima di testare un ripristino isolato. Interrompere immediatamente l’operazione se i checksum cambiano, lo storage di origine diventa instabile o un job scrive sugli originali.

Definire lo stato necessario e quello rigenerabile

Considerare stato necessario gli originali, i video caricati, i file sidecar, il database, la configurazione, i segreti, gli account utente, gli album, le modifiche e i record di condivisione. Elencare separatamente miniature, video transcodificati, embedding dei volti e indici di ricerca come derivati che possono essere rigenerati solo se gli originali e lo stato dell’applicazione rimangono intatti.

Una distribuzione self-hosted colloca comunemente la libreria su uno storage capiente e il database o il percorso di lavoro su supporti più veloci. Un’analisi pratica dello storage di Immich descrive la separazione tra storage della libreria e storage del percorso operativo, motivo per cui un controllo d’integrità deve coprire ogni percorso montato, non solo la cartella che gli utenti consultano.

Registrare la versione dell’applicazione, l’immagine del container, le definizioni dei mount, lo stato dello schema del database, lo spazio libero dello storage e lo stato della coda dei job. Interrompere l’operazione se un percorso necessario è mancante o diventa inaspettatamente di sola lettura; un job di rigenerazione non dovrebbe iniziare finché la fonte autorevole non è certa.

Dimostrare l’integrità dei byte originali indipendentemente dalla galleria

Generare o riutilizzare un manifest di checksum affidabile per gli originali e confrontarlo con l’albero corrente in modalità di sola lettura. Riconciliare il numero di file, i byte totali, i file illeggibili, gli oggetti imprevisti a dimensione zero e i percorsi orfani. Aprire, al di fuori della galleria, un campione stratificato contenente JPEG, HEIC, RAW, video, anni meno recenti e caricamenti recenti.

Non dedurre l’integrità degli originali dalle miniature visibili. Una galleria può continuare a fornire derivati memorizzati nella cache dopo la perdita di un originale, mentre un originale integro può rimanere nascosto se la pipeline delle anteprime non funziona. La distinzione tra originali e derivati rigenerabili rende il controllo diretto dei file il primo passaggio di sicurezza.

Se gli hash cambiano o le letture falliscono, sospendere l’importazione, la pulizia e la rigenerazione dei derivati. Ripristinare o creare un’immagine dello storage che presenta problemi prima di modificare i record del database. La fase è superata quando gli originali necessari sono leggibili e ogni differenza inspiegata ha un responsabile, una motivazione e un’azione di recupero.

Riconciliare record, percorsi e job dei derivati

Confrontare i record degli asset nel database con i percorsi del filesystem in entrambe le direzioni: record privi di file e file privi di record. Controllare UID e GID, bind mount, radici delle librerie esterne, distinzione tra maiuscole e minuscole e directory rinominate prima di dichiarare mancanti gli asset. Conservare gli elenchi degli orfani invece di eliminare automaticamente uno dei due lati.

Campionare quindi i job relativi a miniature, anteprime, transcodifica, estrazione dei metadati e machine learning. Un articolo indipendente di risoluzione dei problemi sugli originali intatti con derivati non riusciti mostra come caricamenti integri possano coesistere con riquadri grigi quando lo storage, i worker o i percorsi dei derivati non funzionano.

Rigenerare un solo derivato canary dopo aver verificato la corrispondenza tra l’originale e la riga del database. Il test è superato quando viene creata una nuova anteprima con proprietario, percorso e risposta del client previsti; in caso contrario, limitare l’indagine ai log del worker, al decoder, allo storage di output o allo stato della coda. Non avviare mai una ricostruzione dell’intera libreria finché il canary non rimane corretto dopo un riavvio.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

Ripristinare l’intera libreria in una destinazione isolata

Ripristinare originali, database, configurazione, segreti e file sidecar necessari in un ambiente usa e getta con porte e percorsi diversi. Avviare le dipendenze nell’ordine corretto, verificare utenti e album, quindi consentire solo i job dei derivati necessari per il set di esempio. Non puntare l’istanza di test verso uno storage di produzione scrivibile.

Testare l’accesso, la timeline, la ricerca, l’appartenenza agli album, il download dei byte originali, una modifica, una condivisione e la riproduzione di un video. Confrontare gli hash dei file scaricati con il manifest e verificare che un secondo riavvio non perda le mappature dei percorsi né ricrei lo stato necessario con il proprietario errato.

Dichiarare dimostrata l’integrità solo quando la libreria attiva e il ripristino isolato concordano sullo stato necessario e i derivati canary vengono ricostruiti dagli originali. Inoltrare per l’escalation le discrepanze tra database e file, gli errori di checksum in aumento o i job che modificano gli originali; conservare manifest e log affinché la riparazione non si trasformi in una reimportazione non documentata.