Arbetsflöde för migrering av namngivna Docker-volymer mellan två hemmaservrar

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

Docker Named Volume Migration Workflow Between Two Home Servers - Zima Store Online

Det säkra tillvägagångssättet är att behandla ett pausat arkiv eller en synkroniserad kopia till en uttryckligen identifierad målvolym, följt av kontrollsumme- och programvalidering, som en sekvens av observerbara kontrollpunkter - inte som ett enda kommando.

På två Linux-hemm servrar som kör Docker Compose är den praktiska risken att en tillståndsbaserad container måste flyttas till en annan värd utan att en aktiv eller felaktigt namngiven volym kopieras. Dokumentera aktuell identitet och återställningspunkt, börja med den minst ingripande särskiljande kontrollen, tolka godkända och underkända resultat innan du ändrar någon annan variabel och avbryt när lagringen blir instabil eller den enda återställningsbara kopian skulle exponeras. Arbetsflödet nedan avslutas först när den ursprungliga arbetsbelastningen fungerar eller när bevisningen når en eskaleringsgräns.

Identifiera källans och målets volymkontrakt

Dokumentera källcontainerns image-digest, Compose-projektnamn, tjänst, volymnyckel, det faktiska Docker-volymnamnet, monteringsdestination, volymdrivrutin och programversion. Använd docker inspect och docker volume inspect; dra inte slutsatser om den fysiska sökvägen enbart från en YAML-etikett.

Compose prefixerar normalt namngivna volymer med projektnamnet, om inget uttryckligt namn eller en extern volym används. På målet renderar du Compose-konfigurationen och skapar uttryckligen den avsedda tomma volymen så att migreringen inte hamnar i en volym medan tjänsten startar en annan.

Om volymen innehåller en databas ska du använda dess inbyggda dump eller en stödd säkerhetskopiering som den primära portabla återställningsvägen och behandla volymkopian som en återställningspunkt för samma version. Avbryt om drivrutinen är fjärrbaserad, källagringen är instabil eller programtillståndet omfattar ytterligare volymer som inte ingår.

Pausa skrivningar och skapa en kopia som bevarar metadata

Försätt programmet i underhållsläge, stoppa bakgrundsjobb och stoppa sedan programmet och databasen på ett ordnat sätt. Bekräfta att ingen container monterar volymen med läs- och skrivåtkomst. Skapa ett arkiv genom en tillfällig container eller använd en kontrollerad filsystemskopia som bevarar numeriskt ägarskap, behörigheter, symboliska länkar, utökade attribut där det behövs och glesa filer.

En oberoende guide om migrering av Docker-volymer med rsync visar hur Docker-volymdata flyttas med rsync. Den viktiga gränsen är att källan måste vara pausad och att kopieringskommandot måste arbeta med det identifierade volyminnehållet, inte blint manipulera Dockers interna katalog medan daemonen använder den.

Skapa ett manifest med antal filer, totala byte, representativa hashvärden och arkivets kontrollsumma. Låt källvolymen och den ursprungliga säkerhetskopian förbli orörda; kopieringssteget är godkänt först när överföringsartefakten kan läsas på målvärden.

Återställ till den uttryckliga målvolymen

Kontrollera målfilsystemets kapacitet, tillgängliga inoder, förväntade UID- och GID-värden samt samma programversion för imagen. Återställ arkivet till den tomma målvolymen utan att platta till dess översta katalogstruktur och jämför sedan ägarskap, antal, storlekar och utvalda hashvärden.

En diskussion i communityt om ett fall med misslyckad migrering av en namngiven volym visar varför det kan misslyckas eller lämna ett förvirrande tillstånd att ersätta filer direkt under Dockers interna volymkataloger. Använd runtime-miljön för att montera volymen i en hjälparcontainer och genomför återställningen via det kontrollerade gränssnittet.

Anslut först endast en kasserbar kopia av tjänsten och använd alternativa portar utan åtkomst till produktionsresurser. Om programmet rapporterar schemauppgraderingar eller skadat tillstånd ska du avbryta och återställa volymen igen från den oförändrade artefakten efter att ha löst versionskompatibiliteten.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

Gör övergången och behåll en återställningsvärd

Starta beroenden före programmet, kontrollera loggar, inloggning, nya poster, bilagor, schemalagda jobb och en kasserbar skrivning. Starta om målstacken och bekräfta att den ansluter till samma namngivna volym igen. Uppdatera proxy eller DNS först när dessa kontroller har godkänts.

Den relaterade ZimaSpace-artikeln om konsekvent säkerhetskopiering av containerdata kan vara till hjälp om målet startar tomt trots en lyckad kopiering. Jämför runtime-monteringskällan med den avsedda volymen innan du kopierar data igen; upprepade kopieringar till fel mål skapar bara mer oklarhet.

Låt källprogrammet förbli stoppat och den gamla volymen skrivskyddad tills en ny säkerhetskopiering och ett återställningstest har lyckats på målet. Rulla tillbaka genom att återföra trafiken till den oförändrade källan endast om inga nya skrivningar har accepterats på målet; annars ska du stoppa och samordna data medvetet.