Vad måste återställas tillsammans för att en självhostad fotobibliotek ska förbli sökbar?
Återställ originalen, katalogdatabasen och konfigurationsfilen som definierar sökvägar som en enhetlig återställningsenhet.
För ett Immich-, Lightroom-, PhotoPrism- eller liknande hemmabaserat NAS-bibliotek kan bildfilerna öppnas igen, men personer, album, betyg, redigeringar, platser och sökresultat kan gå förlorade. En sökbar återställning måste anpassa mediefilerna med databasen eller katalogen som beskriver dem, konfigurationen som kartlägger deras sökvägar och eventuella hemligheter eller applikationsversion som behövs för att läsa det tillståndet.
Definiera sökbarhet som mer än att bara öppna originalfiler
Ett fotobibliotek är sökbart när applikationen kan koppla varje original till dess databaspost, metadata, albumtillhörighet, personkopplingar och sökväg. Att kunna öppna en JPEG bevisar filåterställning, inte bibliotekets återställning.
En diskussion om Immich-återställning visar att databasen innehåller filplatser och bibliotekets metadata medan de faktiska fotona finns kvar i uppladdningsmapparna. Att bara återställa ena sidan kan ge miniatyrbilder eller poster som pekar på saknade original.
Skriv ner det önskade resultatet innan återställning: originalen ska öppnas, tidslinjedatum ska vara korrekta, album ska visas, personsökning ska fungera, redigeringar eller betyg ska återkomma och användare ska behålla åtkomst. Det resultatet definierar vilka komponenter som ingår i återställningsenheten.
Återställ original och katalog från samma tidsgräns
Medieträdet och dess katalog bör representera samma återställningspunkt. En nyare databas kan referera till filer som saknas i en äldre mediekopia, medan en äldre katalog kan ignorera foton som finns på disken.
En Lightroom-återställning krävde en tvåstegsprocess: först fotomappen, sedan en matchande katalogbackup från före incidenten. Samma beroende gäller för självhostade bibliotek som lagrar redigeringar, betyg, personer eller album utanför originalen.
Välj den närmaste gemensamma tidsstämpeln mellan mediebakupen, databasdumpen och konfigurationskopian. Om ingen gemensam punkt finns, återställ till en isolerad instans och lös gapet innan biblioteket görs tillgängligt för användare.
Bevara sökvägar, identifierare och konfiguration som förenar delarna
En katalog kan vara frisk men ändå visa saknade tillgångar när den återställda sökvägen, monteringsnamnet, volymidentifieraren eller bibliotekets rot skiljer sig från den lagrade referensen. Sökvägskonsistens är därför en del av återställningen, inte en kosmetisk uppgift efter återställning.
Lightroom-användare rapporterar att återställda filer måste behålla samma namn och mappstruktur. För containerappar kan motsvarande vara en bind-mount-sökväg, miljövariabel, databas-URL eller lagringsrot.
Återställ Compose-filen eller appkonfigurationen, miljövariabler, hemligheter, användar-ID:n och monteringsdefinitioner bredvid databasen. Gör inte massomlänkning eller omindexering förrän du har bekräftat vilka identifierare applikationen förväntar sig.
Separera nödvändigt tillstånd från regenererbara söktillgångar
Original, databasposter, användardata, albumrelationer, redigeringar och konfiguration är normalt nödvändiga. Miniatyrer, cachade modeller och vissa maskininlärningsinbäddningar kan regenereras, men biblioteket kan förbli långsamt eller delvis osökbart tills dessa jobb är klara.
En aktuell Immich-distributionsguide beskriver separata tjänster för server, maskininlärning och bakgrundsjobbkö, och noterar inbyggd schemaläggning av databasbackup. Dessa komponenter förklarar varför sökning och personigenkänning kan bero på mer än den synliga mediekatalogen.
Dokumentera vilka genererade tillgångar som kan byggas om och hur lång tid ombyggnaden tar. Om ombyggnad skulle ta dagar av CPU-tid eller det ursprungliga modelltillståndet inte kan reproduceras, skydda den tillgången som en del av den praktiska återställningsenheten även om applikationen tekniskt kan återskapa den.
Anpassa det återställda tillståndet till en kompatibel applikationsversion
En katalog eller databas kan kräva den applikationsversion som skapade eller migrerade den. Att starta en äldre tjänst mot ett nyare tillstånd, eller tvärtom, kan misslyckas innan mediet utvärderas.
Användare av fotobibliotek har stött på inkompatibilitet mellan katalogversioner. Bevara den distribuerade bildtaggen, migrationsanteckningar och databasversion så att testmiljön kan reproducera den förväntade uppgraderingsvägen.
Starta det återställda biblioteket offline eller under ett tillfälligt namn. Bekräfta databasmigrationer, användarinloggning och sökvägsupplösning innan mobila klienter eller bakgrundsjobb tillåts ändra det återställda tillståndet.
Verifiera sökning, album och personer innan övergång
Använd ett isolerat återställningstest som inkluderar representativa gamla och nya foton, redigerade objekt, flera användare, delade album, platsmetadata och kända personer. Sök efter poster vars förväntade resultat redan är dokumenterat.
Det befintliga ZimaSpace Immich-familjefotobackupplan ger den närliggande planeringskontexten; detta återställningstest måste nu bevisa att dessa komponenter återkommer tillsammans.
Gör övergången först när originalen öppnas, antal stämmer, album och behörigheter återkommer, sökresultaten är rimliga och en ny uppladdning indexeras korrekt. Behåll den tidigare instansen och återställningsfilerna oförändrade tills testbiblioteket har klarat en omstart och en ny backup.
Rekommenderade produkter
Support och tips
Mer att läsa
Varför återskapar en återställning av en Docker-volym filinnehållet men tar bort utökade attribut?
En felsökning av volymåterställning som omfattar inventering av xattr, alternativ för tar och Rsync, namnrymder, stöd för måldestinationen, behörigheter, etiketter, appmetadata och tester.
Varför behåller en körande container sin gamla minnesgräns efter att Compose-filen har ändrats?
En minnesgränsdiagnos som omfattar aktiva cgroups, omstart kontra återskapande, Compose-fält, hårda och mjuka gränser, överordnade scope, växlingsutrymme och körningsheapar.
Varför ogiltigförklarar en omstart av en omvänd proxy varje session för en självhostad app?
En sessionsförlustdiagnos som omfattar omstartens omfattning, cookie-ägarskap, rotation av hemligheter, cachebaserade sessioner, sticky routing, autentiseringsgatewayer och återställning.
