Stop Immich eerst wanneer je de eenvoudigste, gemakkelijkst uit te leggen consistentiegrens wilt; gebruik alleen een live back-up wanneer je een database-eigen dump kunt maken en de vastlegging of snapshot van de media zo kunt coördineren dat de relatie tussen beide bij herstel bekend is.
Immich slaat activarecords op in PostgreSQL, terwijl originelen en afgeleide bestanden op opslag staan. Daardoor kan een gewone live, recursieve kopie verschillende momenten waarnemen. Voor een klein huishouden is een kort onderhoudsvenster vaak veiliger dan complexe orkestratie. Wanneer continue uploads belangrijk zijn, houd je de service actief, maar gebruik je databasebewuste tools, leg je de volgorde van vastlegging vast, bescherm je nieuw binnenkomende assets en beoordeel je de back-up aan de hand van een geïsoleerd herstel.
Definieer elk onderdeel dat bij herstel opnieuw moet worden aangemaakt
Breng de PostgreSQL-database, uploadbibliotheek, gegenereerde media die volgens je beleid nodig zijn, definities van externe bibliotheken, Compose- en omgevingsbestanden, geheimen, proxy-instellingen en versleutelingssleutels in kaart. Classificeer welke items Immich beheert en welke opnieuw kunnen worden gegenereerd.
Een praktisch artikel over databaseback-ups legt uit hoe je een PostgreSQL-dump gebruikt in plaats van de actieve databasemap als gewone bestanden te behandelen. De databasebewuste back-upmethode ondersteunt de live aanpak; controleer de opdrachten en versies voor jouw implementatie.
Een plan faalt als het originelen beschermt maar hun records niet kan herstellen, of als het de database beschermt maar media weglaat. Noteer de herstelvolgorde naast de back-upvolgorde voordat je bepaalt of downtime aanvaardbaar is.
Kies een gestopte back-up voor de duidelijkste grens
Pauzeer uploads, stop de Immich-applicatie en workers netjes en maak vervolgens een database-eigen back-up. Kopieer of snapshot daarna de media en implementatiebestanden. Laat PostgreSQL alleen draaien voor zover nodig om de dump te maken, of stop het netjes voordat je een opslagniveau-snapshot maakt die voor die service bedoeld is.
Een gestopte service herstelt geen onjuiste paden of onvolledige scope, dus controleer mounts en archiefgroottes. Een geslaagde back-up heeft tijdens de vastlegging geen actieve Immich-schrijfbewerkingen, een geslaagde databaseback-up, leesbare mediavoorbeelden, checksums en een gedocumenteerd herstarttijdstip.
De ZimaSpace-gids voor het verifiëren van back-upsleutels en herstelprocedures benadrukt dat een rustige kopie pas herstelbaar is nadat de inloggegevens en het herstelpad zijn getest.
Gebruik een gecoördineerde live back-up wanneer beschikbaarheid vereist is
Maak voor een live plan een database-eigen consistente dump en combineer die met een opslag-snapshot of bestandsvastlegging waarvan het tijdstip en het schrijvengedrag bekend zijn. Noteer begin- en eindtijd, bewaar nieuw binnenkomende uploads tot de volgende back-up en vermijd het kopiëren van de actieve databasemap.
Een communitydiscussie over het back-uppen van Immich vanuit een actieve implementatie laat zien waarom beheerders onderscheid maken tussen de database en uploadbestanden. Gebruik die grens van een live back-up als praktische context, niet als vervanging voor een hersteltest.
Een live ontwerp slaagt alleen als de databasetool zonder fouten voltooit, de bestandssysteemvastlegging atomair is of de volgorde ervan is gedocumenteerd, en uploads die tijdens het venster zijn aangemaakt worden verantwoord. Kies anders de gestopte aanpak of verhoog de back-upfrequentie om het onderhoudsvenster te verkorten.
Herstel geïsoleerd en maak de definitieve keuze
Herstel de geselecteerde database en media naar een geïsoleerd doel met de opgeslagen implementatiebestanden. Controleer gebruikers, aantallen assets, steekproeven van originelen, albums, favorieten, zoekopdrachten, externe bibliotheken en een nieuwe upload. Start het doel opnieuw en herhaal de kritieke controles.
Kies gestopte back-ups wanneer de downtime binnen het huishouden past en eenvoud de kans op fouten verkleint. Kies gecoördineerde live back-ups wanneer beschikbaarheid extra tooling rechtvaardigt en herhaalde hersteltests het proces bewijzen. De beslissing kan veranderen naarmate de bibliotheek groter wordt en de uploadfrequentie toeneemt.
Stop met het buiten gebruik stellen van productie als het herstel fouten met ontbrekende bestanden of verweesde records oplevert. Bewaar beide back-upcomponenten en de logboeken en breng vervolgens tijdstempels en scope met elkaar in overeenstemming. Escaleer met de databaseversie, dumpmethode, bestandssysteemmethode, vastleggingstijden en aantallen afwijkingen; verwijder nooit de laatste gestopte back-up voordat de live methode onafhankelijk is geslaagd.
Ondersteuning & Tips
Meer om te lezen

Hoe je Docker-herstartbeleid afstemt op databases, workers en webapps
Stem het herstartbeleid af op de levenscyclus en afsluitsemantiek van de service. Combineer het met gezondheids- en gereedheidscontroles; gebruik herstartlussen niet om afhankelijkheidsproblemen te...

Containergebruikers-ID's configureren voor meerdere NAS-shares
Koppel de UID/GID van elke container aan de NAS-shares, gebruik waar nodig gedeelde groepen of ACL's en behandel PUID/PGID als image-specifiek, niet als universele...

Docker Compose-profielen instellen voor optionele thuisserverdiensten
Laat vereiste services zonder profiel en gebruik profielen voor optionele tools. Test directe doelen en afhankelijkheden in plaats van ervan uit te gaan dat...

