Moet u Immich Live back-uppen of de service eerst stoppen?

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

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.

-15% OFF
Single board computer zimaboard2

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

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.