De brongegevens waren niet duidelijk verloren gegaan. Na een reset van ZimaOS bestond RAID6 nog steeds en waren mappen zoals upload, pgdata, thumbs, profile, en encoded-video waren nog steeds aanwezig. Het probleem was dat de opnieuw geïnstalleerde Immich-stack niet was verbonden met de oude database-/bibliotheekstatus op een manier die de vorige fotocatalogus herstelde.
Het veiligste advies uit de bron was: verwijder of verplaats de oude mappen upload en pgdata voorlopig niet. Immich bouwt zijn volledige catalogus niet opnieuw op door alleen afbeeldingsbestanden op schijf te zien. De database bevat bestandspaden, gebruikers, albums, metadata en applicatiestatus. De huidige Immich v3-documentatie maakt die relatie expliciet en raadt aan zowel de assetbestanden als de database te back-uppen.
Eerst het werkelijke RAID-mountpad bevestigen
De bron gebruikte:
ls -la /media
find /media -maxdepth 4 -type d \( -iname "immich" -o -iname "pgdata" -o -iname "upload" \)en vond:
/media/photos/immich
/media/photos/immich/pgdata
/media/photos/immich/uploadDaarmee stond vast dat de oude Immich-mappen nog op de RAID stonden.
/media/ZimaOS-HD → /DATA bewees niet dat Immich de OS-schijf gebruikte
De gebruiker schrok van:
/media/ZimaOS-HD -> /DATAmaar de community legde terecht uit dat dit een ZimaOS-koppeling/symlink-relatie is. De aanwezigheid ervan vertelt niet welke hostpaden de Immich-containers daadwerkelijk gebruiken.
De effectieve Docker-koppelingen inspecteren
De discussie raadde aan het volgende te controleren:
docker inspect immich-server --format '{{json .Mounts}}'
docker inspect immich-postgres --format '{{json .Mounts}}'Dat is betrouwbaarder dan aannemen dat een screenshot of oude herinnering de configuratie van de actieve container weergeeft.
De oude pgdata is net zo belangrijk als de oude fotobestanden
Als de herinstallatie een volledig nieuwe database heeft geïnitialiseerd in plaats van de oude, kunnen de bestanden nog steeds bestaan terwijl Immich leeg lijkt.
De huidige Immich gebruikt UPLOAD_LOCATION en DB_DATA_LOCATION
De huidige Immich v3 Compose scheidt de locatie van de assets op de host en de locatie van Postgres met behulp van UPLOAD_LOCATION en DB_DATA_LOCATIONUpstream zegt expliciet dat netwerkshares niet worden ondersteund voor het databasepad.
Gebruik het huidige opslagmodel van Immich.
Een databaseback-up is veiliger dan het opnieuw koppelen van een actieve oude pgdata-directory tussen versies
De bron gebruikte Immich v2.7.2. De huidige Immich-versie is v3. Bij herstel tussen versies is de back-up- en herstelworkflow van upstream veiliger dan ervan uitgaan dat een oude Postgres-datadirectory eenvoudig aan een nieuwere database-image kan worden gekoppeld.
Zie het huidige back-up- en herstelproces van Immich.
Herschik de interne assetmappen van Immich niet handmatig
De huidige Immich-documentatie waarschuwt dat mappen zoals library, upload, thumbs, profile, en encoded-video worden door de applicatie beheerd. Het verplaatsen of verwijderen van afzonderlijke bestanden achter Immich kan ertoe leiden dat assets ontbreken of niet meer worden bijgehouden.
De brongebruiker heeft geen succesvolle herstelactie bevestigd
Communityleden stelden verschillende toewijzingsmethoden voor, waaronder één bovenliggende mount, maar jerlo zette de kwestie uiteindelijk terzijde en begon opnieuw op een ander systeem. Daarom bevestigt het forum geen enkele padtoewijzing als de definitieve oplossing.
De huidige Immich-versie geeft de voorkeur aan een beheerde uploadhoofdmap in plaats van het handmatig koppelen van elke onderliggende map
De bron-screenshots brachten handmatig upload, thumbs, profile, library, encoded-videoen maak back-ups één voor één. De huidige upstream Compose-configuratie richt zich daarentegen op de hostconfiguratie rond UPLOAD_LOCATION, waarbij Immich de interne onderliggende mappen onder die hoofdmap beheert.
Gebruik bij het opnieuw opbouwen met een nieuwere Immich-release de huidige Compose-/opslagindeling in plaats van een historische set koppelingen van onderliggende mappen te reproduceren, tenzij het pakket dit specifiek vereist.
Houd het PostgreSQL-gegevenspad op ondersteunde lokale opslag
De huidige Immich-documentatie vermeldt expliciet dat netwerkshares niet worden ondersteund voor DB_DATA_LOCATION. Een lokaal aangesloten RAID-/opslagbestandssysteem kan geschikt zijn, maar een via SMB/NFS gekoppelde databasemap is niet het ondersteunde databasepad.
Voor volledig Immich-herstel zijn zowel assets als de database nodig
Volgens de huidige Immich-back-updocumentatie bevatten databaseback-ups metadata en gebruikersinformatie, maar niet de foto- en video-assets. De assetstructuur moet afzonderlijk worden geback-upt en samen met een compatibele databaseback-up worden hersteld.
Dat verklaart waarom „de uploadbestanden staan er nog” in het oorspronkelijke geval geruststellend maar onvoldoende was.
Koppel een oude actieve pgdata-directory niet zomaar aan een andere PostgreSQL-/imageversie
Een onbewerkte PostgreSQL-gegevensdirectory is versieafhankelijk. Als de oude omgeving en het nieuwe pakket verschillende PostgreSQL- of Immich-versies gebruiken, geef dan de voorkeur aan een ondersteunde database-export/import of een gedocumenteerde migratieroute. Maak een back-up die byte voor byte overeenkomt van de oude pgdata voordat je gaat experimenteren.
Veelgestelde vragen over Immich-herstel
Heeft de ZimaOS-reset de fotomappen op de bron-RAID6 gewist?
Nee. De gebruiker zei dat de RAID en de bestaande mappen/bestanden intact waren gebleven.
Zal het koppelen van alleen oude fotobestanden de Immich-bibliotheek herstellen?
Niet noodzakelijkerwijs. Immich heeft ook de bijbehorende database-/catalogusstatus nodig.
Wat moet worden beschermd voordat je gaat experimenteren?
De volledige opslag van assets plus de database of een geverifieerde databaseback-up.
