Zo verplaats je Immich-gegevens zonder gebruikers, geschiedenis of instellingen te verliezen

Verplaats Immich als een migratie van de applicatiestatus, niet als een mapkopie: behoud de database, mediaboom, configuratie, geheimen en de paden die deze met elkaar verbinden.

Een migratie kan geslaagd lijken omdat elke JPEG op de nieuwe schijf staat, terwijl accounts, albums, personen, gedeelde items, favorieten of historische relaties ontbreken. Maak eerst een terugvalpunt, leg één consistente bronstatus vast, kopieer die zonder identifiers te wijzigen, herstel op een geïsoleerd doel en schakel pas over nadat de workflows in huis overeenkomen.

Inventariseer de status die samen moet worden verplaatst

Noteer de PostgreSQL-database, geüploade media, gegenereerde gegevens die je wilt behouden, definities van externe bibliotheken, Compose- of appconfiguratie, omgevingswaarden, geheimen, netwerk­namen en de huidige opslagkoppelingen. Markeer welk onderdeel leidend is en welk onderdeel na herstel opnieuw kan worden gegenereerd.

Een migratiebespreking uit 2026 over het behouden van Immich-gebruikers tijdens een verplaatsing benadrukt het centrale punt: gebruikers- en bibliotheekstatus is gekoppeld aan de database en gekoppelde paden, niet aan de containerimage. Behandel opdrachten uit de community als voorbeelden en pas ze aan de exact geïmplementeerde versie aan.

Leg vóór de verplaatsing een kleine controleset vast: twee gebruikers, meerdere albums, favorieten, gedeelde items, één persoon of zoekresultaat, oude en recente assets en één pad naar een externe bibliotheek als die wordt gebruikt. Deze bekende records maken de validatie na de migratie veel sterker dan alleen het vergelijken van de totale bestandsgrootte.

Maak vóór het kopiëren een consistent herstelpunt

Pauzeer nieuwe uploads of plan een onderhoudsvenster, zodat de bron niet meer verandert terwijl je de migratiestatus vastlegt. Maak een database-native back-up en beveilig de bronmedia en configuratie. Laat de oorspronkelijke instantie na het vastleggen ongemoeid totdat de bestemming de verificatie heeft doorstaan.

De ZimaSpace-herstelgids over het samen herstellen van onderdelen van een fotobibliotheek legt uit waarom originelen, catalogusstatus en padbepalende configuratie een compatibel herstelpunt moeten vormen. Dat is dezelfde grens die een migratie nodig heeft.

Gebruik de live productiedatabasemap niet als gewone kopieerbestemming voor bestanden terwijl deze verandert. Als de downtime kort moet blijven, gebruik dan een databasebewuste dump en een opslagmethode waarvan je de volgorde van vastleggen begrijpt. Een migratie is slechts zo herstelbaar als het punt dat je kunt herstellen, niet als het aantal gekopieerde bestanden.

Kopieer media met behoud van paden en rechten

Kopieer de mediamap naar de bestemming zonder mappen halverwege de migratie opnieuw te organiseren. Behoud eigenaar, rechten, tijdstempels en alle bestandssysteemfuncties waarop je implementatie vertrouwt. Als het in de container zichtbare pad hetzelfde moet blijven, wijzig dan de bron aan de hostkant van de bind-mount terwijl je de koppeling in de container ongewijzigd laat.

De actuele rsync-migratieworkflow benadrukt de archiefmodus, proefruns, hervatbare overdrachten en het gevaar van destructieve spiegelopties. Voer vóór elke verwijdering een proefvergelijking uit en controleer de bestemming in plaats van aan te nemen dat een voltooide opdracht gelijkstaat aan een voltooide applicatiemigratie.

Vergelijk aantallen en groottes van bestanden en controleer vervolgens een representatief voorbeeld met checksums van oude foto's, nieuwe foto's, video's en grote bestanden. Als er kopieerfouten of “verdwenen bestanden” verschijnen doordat de bron is gewijzigd, stop dan met het accepteren van uploads en herhaal de differentiële doorgang in plaats van de bron te verwijderen om een schijnbaar nette bestemming af te dwingen.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Herstel de database en configuratie op een geïsoleerde bestemming

Start de bestemming onder een tijdelijke hostnaam of op een geïsoleerd netwerk, zodat mobiele clients er tijdens de validatie niet naartoe kunnen uploaden. Koppel de gekopieerde media aan de verwachte paden in de container, herstel de bijbehorende database en reproduceer de omgevingswaarden, geheimen, netwerken en proxy-instellingen die voor die versie nodig zijn.

Een afzonderlijk verslag uit 2026 over een gefaseerde servermigratie laat zien waarom beheerders de nieuwe host testen voordat ze de oude buiten gebruik stellen. Gebruik zulke verslagen om mogelijke fouten te bedenken, maar laat je bekende records bepalen of de migratie de status daadwerkelijk heeft behouden.

Stop als de bestemming opent als een nieuwe installatie, ontbrekende opslag meldt of een destructieve initialisatie voorstelt. Dat betekent meestal dat de database of mounts niet de verwachte zijn. Corrigeer eerst het pad of de herstelde bestemming; upload geen nieuwe bestanden naar een leeg lijkende instantie, want dan ontstaan twee concurrerende geschiedenissen.

Schakel pas over nadat gebruikers, geschiedenis en nieuwe schrijfacties zijn geslaagd

Log in als elke referentiegebruiker en controleer albummembership, favorieten, delen, zoek- of personenstatus, representatieve originelen, tijdstempels en de verwachte aantallen in de bibliotheek. Upload daarna één nieuwe testfoto en controleer of deze verschijnt, wordt verwerkt en een herstart van de container overleeft.

Wijzig de productieve DNS- of proxydestination pas nadat de geïsoleerde test is geslaagd. Houd de oude instantie gestopt maar herstelbaar, zodat beide systemen niet tegelijk schrijfacties kunnen accepteren. Bewaar de databaseback-up van vóór de migratie en de bronmedia totdat de nieuwe host normale back-ups heeft voltooid en ten minste één hersteltest heeft doorstaan.

Rol terug als aantallen afwijken, bekende relaties verdwijnen, nieuwe uploads naar de verkeerde schijf worden geschreven of de bestemming na een herstart uitvalt. Escaleer met de bron- en doelversies, het tijdstip van de databaseback-up, mountoverzichten, kopieerlogboeken, verschillen in rechten en het eerste mislukte controle-item.