Containergegevens naar een SSD-pool verplaatsen zonder mountpaden te verbreken

Verplaats de gegevensbron aan de hostzijde naar de SSD en behoud daarbij elk bestemmingspad aan de containerzijde.

Bij een veilige migratie wordt de huidige mountconfiguratie als een interfacecontract behandeld. Containers, databases en media-apps verwachten paden zoals /config, /data of /media, ongeacht welke schijf ze levert. De workflow moet schrijfbewerkingen stoppen, de SSD voorspelbaar mounten, eigenaarschap en metadata kopiëren, alleen de bron aan de hostzijde bijwerken, de nieuwe mount vóór het opstarten verifiëren en de oorspronkelijke gegevens bewaren totdat een volledige hersteltest is geslaagd.

Inventariseer elke huidige bron en containerbestemming

Exporteer het Compose-bestand of de inspectiegegevens van de containers en noteer elke bind mount, named volume, tmpfs-mount, databasemap, cache, transcodeerpad en medialocatie. Leg de bron aan de hostzijde en de bestemming aan de containerzijde afzonderlijk vast.

Een praktische handleiding voor volumemigratie begint met het lokaliseren van de huidige gegevens en het stoppen van de containers voordat je deze kopieert naar een nieuwe schijflocatie. Deze inventaris voorkomt dat configuratiegegevens op de systeemschijf achterblijven.

Markeer welke paden de leidende status, opnieuw op te bouwen cache en grote mediabestanden bevatten. Ga er niet van uit dat een map met de naam data alle permanente toepassingsstatus bevat.

Mount de SSD-pool voorspelbaar voordat Docker start

Maak het SSD-bestandssysteem of de SSD-pool aan, identificeer deze met een stabiele UUID of poolnaam en mount deze op het definitieve pad aan de hostzijde. Controleer na een herstart de vrije ruimte, de verwachte bestandssysteemfuncties en de schrijftoegang.

Het verplaatsen van Docker-gegevens naar externe opslag kan mislukken wanneer de schijf ontbreekt of tijdens het opstarten op een ander pad wordt gemount. Een recente casus met een externe SSD laat zien hoe het verplaatsen van Docker-opslag de afhankelijkheid van het doelpad van de mount verandert.

Configureer de volgorde waarin services starten of het automountgedrag, zodat Docker nooit een lege terugvalmap op de systeemschijf aanmaakt. Stop als de SSD niet op exact het verwachte pad is gemount.

Stop schrijfbewerkingen en kopieer gegevens met behoud van metadata

Stop de toepassing en elke afhankelijkheid die naar de gegevens kan schrijven, waaronder databases, indexeerders, downloaders en achtergrondtaken. Gebruik voor databases een applicatieconsistente dump of een nette afsluiting voordat je ruwe bestanden kopieert.

Een bespreking over Synology-containers adviseert om een door Docker beheerd volume pas naar een bind mount te verplaatsen nadat je de volumegegevens hebt geïdentificeerd en de inhoud ervan op de nieuwe bron voor de bind mount hebt behouden.

Kopieer recursief en behoud daarbij eigenaarschap, machtigingen, tijdstempels, koppelingen, ACL's en uitgebreide attributen waar dit wordt ondersteund. Voer na het kopiëren en vóór het wijzigen van Compose een vergelijking zonder wijzigingen of een steekproef met checksums uit.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Wijzig alleen het bronpad aan de hostzijde

Houd de bestemming aan de containerzijde identiek. Wijzig bijvoorbeeld /oldpool/app:/config in /ssdpool/app:/config in plaats van de toepassing een nieuw intern pad aan te leren.

Bind mounts maken een exacte locatie op de host beschikbaar via een stabiel pad in de container. Een overzicht van opslag legt uit dat deze directe koppeling nuttig is wanneer beheerders controle over het pad aan de hostzijde nodig hebben.

Door de bestemming te behouden voorkom je problemen met toepassingsdatabases, bibliotheekverwijzingen, scripts, machtigingen en configuratiewaarden waarin het pad aan de containerzijde is opgeslagen.

Herstel eigenaarschap, labels en databaseconsistentie

Vergelijk de numerieke UID- en GID-waarden die de image verwacht met het eigenaarschap op de SSD. Herstel ook ACL's, SELinux-labels, AppArmor-toestemmingen en mountopties die nodig zijn voor vergrendeling of bestanden die in het geheugen worden gemapt.

Een handleiding voor een Docker-opslagmigratie op macOS merkt op dat het verplaatsen van Docker-gegevens vereist dat de volledige opslagimage wordt gekopieerd en vervolgens wordt bevestigd dat de runtime de nieuwe opslaglocatie gebruikt. Op Linux-NAS-systemen betekent de overeenkomstige controle dat elke geconfigureerde bron naar de gemounte SSD verwijst.

Start alleen de database en controleer de herstel­logboeken voordat je afhankelijke apps start. Als er melding wordt gemaakt van beschadiging of ontbrekende bestanden, stop dan en ga terug naar de oorspronkelijke kopie in plaats van toepassingen een lege database te laten initialiseren.

Voer de omschakeling uit met een terugdraaipad en volledige workflowtest

Start de stack in volgorde van afhankelijkheden en controleer de configuratie, databaserecords, machtigingen, mediabibliotheken, uploads, downloads, updates en het opnieuw aanmaken van containers. Controleer of nieuwe schrijfbewerkingen op de SSD terechtkomen en de systeemschijf niet verder groeit.

Het ZimaSpace-artikel over een Docker-bind mount die plotseling alleen-lezen wordt behandelt de volgende diagnose als het gemigreerde pad wel wordt gemount maar schrijfbewerkingen weigert.

Houd de oude gegevens offline en ongewijzigd totdat back-ups en een tweede herstel van de containers vanaf het SSD-pad zijn geslaagd. Verwijder de oude bron pas nadat een terugdraaioefening heeft bewezen dat je het Compose-bestand, de mounts, databases en toepassingsstatus kunt herstellen.