Een Immich-database herstellen vanaf een bekende goede back-up

Een bekende goede back-up van de Immich-database is alleen nuttig als je die terugzet in een gecontroleerde toestand en aantoont dat de herstelde database nog steeds verwijst naar de media die je server daadwerkelijk kan zien.

Behandel herstel als een reeks stappen, niet als één importopdracht. Behoud eerst de defecte instantie, bepaal de Immich-versie en het tijdstip van de back-up, start een schone, compatibele databasebestemming, herstel zonder de applicatie eerst naar een leeg schema te laten schrijven en valideer vervolgens accounts, tijdlijngegevens, mediapaden en één nieuwe schrijfactie. Als een stap onduidelijk is, stop dan voordat je de laatste herstelbare kopie vervangt.

Bevries de defecte toestand voordat je iets herstelt

Stop nieuwe uploads en achtergrondschrijfacties naar de getroffen Immich-instantie voordat het herstelwerk begint. Bewaar het huidige Compose-bestand, de omgevingswaarden, gekoppelde paden, imageversies, recente logs en, als de opslagruimte dat toelaat, de toestand van de beschadigde database. Een defecte database kan nog steeds aanwijzingen bevatten die verklaren wat er is gebeurd; door die te overschrijven verdwijnen die aanwijzingen.

Bepaal precies welke back-up je wilt vertrouwen. Noteer het tijdstip, hoe de back-up is gemaakt, de bestandsgrootte en of deze ooit testmatig is teruggezet. Een SQL-dump die door de database is gemaakt, is een ander herstelmiddel dan een ruwe kopie van de actieve PostgreSQL-gegevensdirectory; behandel ze niet als uitwisselbaar.

Maak de herstelbestemming indien mogelijk in een aparte directory of geïsoleerde stack. Het eindpunt van deze fase is eenvoudig: de oorspronkelijke defecte toestand is bewaard, de gekozen back-up is alleen-lezen en je weet met welke implementatieversie en opslagpaden het herstel opnieuw moet worden verbonden.

Controleer of de back-up daadwerkelijk kan worden hersteld

Inspecteer de back-up voordat je deze opnieuw afspeelt. Een gecomprimeerde SQL-dump moet zonder fouten kunnen worden gedecomprimeerd en herkenbare PostgreSQL-dumpinhoud bevatten, in plaats van een leeg archief te zijn dat door een mislukte pipeline is geproduceerd. Als je checksums of verificatieresultaten uit de repository hebt, vergelijk die dan nu, in plaats van halverwege het herstel corruptie te ontdekken.

Een PostgreSQL-dump is een veiliger herstelmiddel dan een losse kopie van een actieve databasemap, omdat deze met databasebewuste hulpmiddelen is gemaakt en in een schone bestemming kan worden afgespeeld. Het patroon met een database-dump als back-up houdt de database ook gescheiden van de mediakopie, waardoor je beide delen afzonderlijk kunt valideren voordat je ze herstelt.

Controleer ook of de media en configuratie die bij het back-upvenster horen nog bestaan. Alleen de database herstellen kan gebruikers, albums, metagegevens en bestandsverwijzingen terugbrengen, terwijl elk bestand onbruikbaar blijft als de verwezen bibliotheekpaden ontbreken. Ga alleen verder wanneer de dump en de media/configuratieset bij een bekend herstelpunt horen.

Start eerst een compatibele, schone databasebestemming

Stem de herstelmethode af op de versie waarmee de back-up is gemaakt. Huidige Immich-versies bieden databaseherstel via Beheer > Onderhoud en via de onboardingflow van een nieuwe installatie, terwijl voor oudere back-ups mogelijk versiegebonden handmatige instructies nodig zijn; de herstelworkflow is gewijzigd in v2.5.0.

Laat Immich bij een nieuwe herstelbestemming geen normale migraties uitvoeren op een leeg schema voordat het databaseherstel gereed is. Als je implementatiemethode de applicatie samen met PostgreSQL start, gebruik dan de herstelopties die bij de versie passen, zodat de server vóór het importeren geen concurrerende toestand aanmaakt.

Als de database niet vanzelf gezond wordt, stop dan en los dat eerst op. Blijf dezelfde back-up niet herhaaldelijk afspelen naar een bestemming die steeds opnieuw opstart, onvoldoende schijfruimte heeft of een incompatibele opslagindeling gebruikt. Een schone, stabiele bestemming is een voorwaarde, geen zijspoor voor probleemoplossing.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Herstel de dump één keer en stop bij de eerste fout

Herstel de gekozen dump naar de voorbereide database en leg de volledige uitvoer vast. Gebruik de databasehulpmiddelen en opties die bij het dumpformaat passen, zodat een fout het herstel zichtbaar laat mislukken in plaats van een gedeeltelijk geïmporteerd schema achter te laten dat toch opstart.

Een bruikbare migratieset heeft de assets, de PostgreSQL-toestand en de configuratie nodig die deze opnieuw met elkaar verbindt. Een complete Immich-back-upset bevat geüploade assets, een ondersteunde databaseback-up en implementatieconfiguratie, waarbij hersteltests aantonen dat de set werkt. Houd deze onderdelen bij elkaar, zodat de bestemming aan één herstelpunt kan worden gekoppeld.

Start na een geslaagde import de Immich-applicatie en houd de eerste opstart nauwlettend in de gaten. Als de interface je vraagt een nieuwe eerste beheerder aan te maken in plaats van de bestaande accounts te accepteren, stop dan: dat wijst er sterk op dat de herstelde database niet de database is die Immich gebruikt. Begin in die lege toestand niet opnieuw met het uploaden van foto's.

Valideer de databasetoestand, mediapaden en een nieuwe schrijfactie

Log in met een bestaand account en bekijk steekproefsgewijs de tijdlijn over oude en recente datums. Open verschillende originelen, controleer albums of favorieten waarvan je zeker weet dat ze bestonden en bevestig dat de applicatie de onderliggende bestanden kan vinden, in plaats van alleen databaseregels weer te geven.

De databasetoestand, applicatiebestanden, configuratie en uploads moeten bij het herstel met elkaar overeenkomen. Gebruik een consistente back-up van de databasecontainer als acceptatiemodel, niet alleen de vraag of PostgreSQL opstart.

Upload ten slotte één wegwerpfoto, wacht tot de normale verwerking is voltooid, controleer of de foto een herstart van Immich en een herstart van de host overleeft en verwijder deze daarna via de applicatie. Als accounts, oude assets en de nieuwe schrijfactie zich allemaal normaal gedragen, maak dan een nieuwe back-up van de herstelde toestand voordat je een versie-upgrade uitvoert. Zo niet, ga dan terug naar het bewaarde bewijsmateriaal van de fout of naar een oudere bekende goede back-up, in plaats van de schade te vergroten.