Handleiding voor ZFS-datasetmigratie: gegevens verplaatsen zonder containerpaden te wijzigen

De veilige aanpak is om repliceren, verifiëren en het oorspronkelijke koppelpunt atomair om te schakelen naar een terugvald­ataset die behouden blijft, te behandelen als een reeks waarneembare controlepunten en niet als één enkele opdracht.

Bij ZFS-datasets die een containerstack op een thuisserver ondersteunen, bestaat het praktische risico erin dat je een ZFS-dataset moet verplaatsen en daarbij de bind-mountpaden voor containers moet behouden. Leg de huidige identiteit en het herstelpunt vast, begin met de minst ingrijpende onderscheidende controle, interpreteer geslaagde en mislukte resultaten voordat je een andere variabele wijzigt, en stop wanneer de opslag instabiel wordt of wanneer alleen de herstelbare kopie nog blootgesteld zou worden. De onderstaande procedure eindigt pas wanneer de oorspronkelijke workload succesvol werkt of het bewijs een escalatiegrens bereikt.

Inventariseer de dataset en het padcontract

Leg de brondataset, onderliggende datasets, snapshots, het koppelpunt, de waarde van canmount, de versleutelingsroot, quota's, reserveringen, ACL-gedrag en elke container-bind-mount die daarin terechtkomt vast. Het contract is het hostpad dat containers zien; de naam van de pool en dataset kan daaronder veranderen.

ZFS-replicatie kan snapshots en eigenschappen behouden, dus een recursieve stream vereist een doelbewuste beoordeling van eigenschappen in plaats van een blinde receive. Een onafhankelijke ZFS send- en receive-migratie laat zien hoe send en receive worden gebruikt voor interne datasetmigratie en waarom de doelhiërarchie vóór de omschakeling moet worden gecontroleerd.

Maak vóór de migratie een actuele externe back-up of bewijs dat een bestaande back-up kan worden teruggezet. Stop als de bron verborgen onderliggende datasets heeft, als er een onbekende afhankelijkheid van een versleutelingssleutel bestaat of als een koppelpunt overlapt met een andere actieve dataset; onder die omstandigheden kan een correcte stream op de verkeerde plaats worden aangekoppeld.

Ontvang de eerste kopie zonder deze boven productie te koppelen

Maak een recursieve snapshot, zoals zfs snapshot -r oldpool/apps@move-0, en stuur deze naar een doeldataset die wordt ontvangen met aankoppelen uitgeschakeld of met een tijdelijk koppelpunt. Gebruik de vlaggen die passen bij je versleutelings- en eigenschapsvereisten; neem niet aan dat een onbewerkte versleutelde stream en een ontsleutelde receive hetzelfde sleutelgedrag hebben.

Vergelijk na het ontvangen zfs list -r -t filesystem,snapshot en zfs get -r mountpoint,canmount,encryptionroot,quota,reservation op beide bomen. Een forumbespreking over gerepliceerde eigenschappen van koppelpunten laat zien waarom gerepliceerde eigenschappen van koppelpunten een verder geslaagde migratie kunnen verrassen.

De eerste kopie is geslaagd wanneer de dataset- en snapshot-afstamming overeenkomen en het doel geïsoleerd blijft van het productiepad. Als het wordt aangekoppeld boven de bron of bestanden wijzigt die containers zien, exporteer of ontkoppel dan het doel en corrigeer de eigenschappen voordat je een incrementele send uitvoert.

Sluit de schrijfachterstand en schakel het koppelpunt om

Maak nog een snapshot van de bron en stuur het incrementele verschil terwijl de app nog draait. Stop voor de definitieve omschakeling alle schrijvers, controleer of geen enkel proces bestanden open heeft onder het bind-mountpad, maak een laatste snapshot en stuur alleen die delta. Beperk de downtime tot de definitieve synchronisatie en het wisselen van het pad.

Stel de bron in op een niet-productiekoppelpunt of canmount=noauto, wijs vervolgens het oorspronkelijke hostpad toe aan het doel en koppel het aan. Laat nooit twee datasets aanspraak maken op hetzelfde koppelpunt. Start de database en afhankelijke services voordat je de applicatiefrontend start, zodat fouten naar de juiste laag verwijzen.

Als de laatste send mislukt, koppel de bron dan opnieuw aan op het oorspronkelijke pad en start de stack opnieuw; vermeng geen nieuwe schrijfbewerkingen over beide kopieën. De terugvalvoorwaarde is expliciet: de bron blijft intact en op het doel wordt geen productieschrijfbewerking geaccepteerd totdat de laatste stream- en eigenschapscontroles zijn geslaagd.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Valideer containers op het ongewijzigde pad

Controleer bind-mounts vanuit de container-runtime, open representatieve bestanden, maak via de app een tijdelijk bestand aan en verwijder het weer, en bevestig eigenaarschap, ACL's, uitgebreide attributen en de rapportage van vrije ruimte. Start de stack tweemaal opnieuw en controleer of ZFS wordt aangekoppeld voordat containers starten.

Voer volgens je onderhoudsplan een scrub of een andere controle van de poolstatus uit, maar gebruik die niet als het enige migratiebewijs. Vergelijk snapshot-GUID's of een representatief hashmanifest, zet één klein item terug en gebruik de ZimaSpace-test om te controleren of ZFS-replicatie na een onderbreking kan worden hervat voordat je de bronafstamming buiten gebruik stelt.

Behoud de bron alleen-lezen totdat ten minste één normale back-up- en applicatiecyclus succesvol is verlopen. Stel de bron pas buiten gebruik wanneer containers de oorspronkelijke paden gebruiken, geplande taken zich op de nieuwe dataset richten, de replicatie vanaf de bedoelde afstamming doorgaat en terugvallen niet langer nodig is; draai anders het koppelpunt terug en behoud beide geschiedenissen.