Como mover dados de contentores para um conjunto de SSD sem alterar os caminhos de montagem

Mova a origem dos dados no lado do anfitrião para o SSD, mantendo inalterado o caminho de destino no lado de cada contentor.

Uma migração segura trata o mapa de montagens atual como um contrato de interface. Os contentores, as bases de dados e as aplicações multimédia esperam caminhos como /config, /data ou /media, independentemente do disco que os fornece. O processo deve interromper as escritas, montar o SSD de forma previsível, copiar a propriedade e os metadados, atualizar apenas a origem no anfitrião, verificar a nova montagem antes do arranque e manter os dados originais até passar um teste completo de restauro.

Faça o Inventário de Todas as Origens Atuais e Destinos nos Contentores

Exporte o ficheiro Compose ou os dados de inspeção dos contentores e liste todas as montagens bind, volumes nomeados, montagens tmpfs, diretórios de bases de dados, caches, caminhos de transcodificação e localizações de ficheiros multimédia. Registe separadamente a origem no anfitrião e o destino no contentor.

Um guia prático de migração de volumes começa por localizar os dados atuais e parar os contentores antes de os copiar para uma nova localização num disco. Esse inventário evita que os dados de configuração fiquem no disco do sistema.

Identifique os caminhos que contêm o estado autoritativo, a cache que pode ser recriada e os ficheiros multimédia de grandes dimensões. Não parta do princípio de que uma pasta chamada data contém todo o estado persistente da aplicação.

Monte o Conjunto de SSD de Forma Previsível Antes de Iniciar o Docker

Crie o sistema de ficheiros ou conjunto de SSD, identifique-o através de um UUID estável ou do nome do conjunto e monte-o no caminho final do anfitrião. Verifique o espaço livre, as funcionalidades esperadas do sistema de ficheiros e o acesso de escrita após um reinício.

Mover os dados do Docker para armazenamento externo pode falhar quando o disco está ausente ou montado num caminho diferente durante o arranque. Um caso recente com um SSD externo destaca como a relocalização do armazenamento do Docker altera a dependência de um caminho de montagem de destino.

Configure a ordem de arranque dos serviços ou o comportamento de montagem automática para que o Docker nunca crie um diretório de recurso vazio no disco do sistema. Pare se o SSD não estiver montado exatamente no caminho esperado.

Pare os Processos de Escrita e Copie os Dados com os Metadados Preservados

Pare a aplicação e todas as dependências que possam escrever nos respetivos dados, incluindo bases de dados, indexadores, descarregadores e tarefas em segundo plano. No caso das bases de dados, faça uma exportação consistente com a aplicação ou um encerramento limpo antes de copiar os ficheiros brutos.

Uma discussão sobre contentores Synology recomenda mover um volume gerido pelo Docker para uma montagem bind apenas depois de identificar os dados do volume e preservar o seu conteúdo na nova origem da montagem bind.

Copie recursivamente, preservando a propriedade, as permissões, as marcas temporais, as ligações, as ACL e os atributos estendidos, quando suportados. Faça uma comparação de teste ou verifique uma amostra através de somas de verificação após a cópia e antes de alterar o Compose.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Altere Apenas o Caminho da Origem no Anfitrião

Mantenha o destino no contentor exatamente igual. Por exemplo, altere /oldpool/app:/config para /ssdpool/app:/config, em vez de ensinar à aplicação um novo caminho interno.

As montagens bind expõem uma localização exata do anfitrião através de um caminho estável dentro do contentor. Uma visão geral do armazenamento explica que este mapeamento direto é útil quando os administradores precisam de controlar o caminho no lado do anfitrião.

Preservar o destino evita danificar as bases de dados da aplicação, as referências às bibliotecas, os scripts, as permissões e os valores de configuração que armazenam o caminho no lado do contentor.

Restaure a Propriedade, os Rótulos e a Consistência da Base de Dados

Compare os valores numéricos de UID e GID esperados pela imagem com a propriedade no SSD. Restaure também as ACL, os rótulos SELinux, as permissões do AppArmor e as opções de montagem necessárias para bloqueios ou ficheiros mapeados em memória.

Um guia de migração do armazenamento do Docker no macOS observa que a relocalização dos dados do Docker exige copiar a imagem de armazenamento completa e confirmar depois que o runtime utiliza a nova localização de armazenamento. Em sistemas NAS Linux, a verificação equivalente consiste em confirmar que cada origem configurada resolve para o SSD montado.

Inicie apenas a base de dados e analise os registos de recuperação antes de iniciar as aplicações dependentes. Se indicar corrupção ou ficheiros em falta, pare e volte à cópia original, em vez de permitir que as aplicações inicializem uma base de dados vazia.

Faça a Mudança com uma Opção de Reversão e um Teste Completo do Fluxo de Trabalho

Inicie a stack pela ordem das dependências e verifique a configuração, os registos da base de dados, as permissões, as bibliotecas multimédia, os carregamentos, as transferências, as atualizações e a recriação dos contentores. Confirme que as novas escritas são feitas no SSD e que o disco do sistema já não aumenta de utilização.

O artigo da ZimaSpace sobre uma montagem bind do Docker que se torna subitamente só de leitura aborda o diagnóstico seguinte se o caminho migrado for montado, mas recusar escritas.

Mantenha os dados antigos offline e inalterados até que as cópias de segurança e uma segunda recriação do contentor sejam concluídas com êxito a partir do caminho no SSD. Remova a origem antiga apenas depois de um exercício de reversão demonstrar que consegue restaurar o ficheiro Compose, as montagens, as bases de dados e o estado da aplicação.