Como preservar a identidade da cópia de segurança do Time Machine antes de mudar o nome ou reconstruir uma partilha NAS
É menos provável que o Time Machine abandone um histórico existente num NAS quando a identidade da cópia de segurança da partilha é preservada antes de a renomear, reconstruir ou migrar.
Um destino de Time Machine numa rede é mais do que uma pasta que contém um sparsebundle. O Mac também pode depender do volume de rede anunciado, das capacidades SMB, do caminho da partilha, das credenciais e de um identificador de volume do lado do serviço. Antes de alterar o NAS, registe esses sinais de identidade e proteja o sparsebundle existente. Em seguida, reconstrua ou renomeie uma camada de cada vez e verifique se o Mac continua a reconhecer o destino pretendido antes de permitir o início de uma nova cópia de segurança.
Registe o destino de rede atual antes da manutenção
Guarde o nome de anfitrião do NAS, o endereço SMB, o nome da partilha, a conta, o destino de Time Machine selecionado, o nome do sparsebundle e o tamanho atual da cópia de segurança. Registe também como a partilha é descoberta, por exemplo, através de um anúncio Bonjour ou de um caminho SMB montado manualmente.
A Apple explica que um disco de Time Machine numa rede é selecionado como destino de rede, e não é simplesmente qualquer pasta que contenha ficheiros de cópia de segurança.
Faça um snapshot do NAS ou uma cópia independente do sparsebundle antes de alterar a definição da partilha. Assim, terá um ponto de reversão caso o serviço reconstruído crie outra identidade de destino ou o Mac inicie um novo histórico.
Preserve o UUID do volume do Time Machine quando o NAS o suportar
Se o NAS expuser um UUID de volume do Time Machine ou um identificador persistente semelhante, registe-o antes de eliminar ou recriar a partilha SMB. Não presuma que o mesmo nome visível da partilha irá gerar novamente a mesma identidade.
A TrueNAS documenta que o seu UUID do Time Machine identifica o volume, e que criar ou atualizar uma partilha com um valor nulo pode gerar um novo UUID.
Restaure o identificador anterior apenas quando a partilha reconstruída representar realmente o mesmo destino de cópia de segurança e a instância antiga do servidor já não estiver ativa. Duplicar um UUID em dois destinos ativos cria uma ambiguidade própria.
Mantenha a capacidade SMB do Time Machine ativada na partilha reconstruída
Recriar uma partilha SMB normal no mesmo caminho do sistema de ficheiros não é suficiente. Confirme que a partilha reconstruída continua a anunciar suporte para o Time Machine e as extensões SMB da Apple esperadas pelo Mac.
O módulo vfs_fruit do Samba indica que o suporte para o Time Machine é anunciado através da capacidade FULLSYNC da partilha e do registo mDNS quando suportado.
Compare as definições antigas e novas da partilha Samba ou do NAS antes de voltar a ligar o Mac. Se a capacidade tiver mudado, corrija primeiro a apresentação do servidor, em vez de eliminar ou renomear o sparsebundle.
Não reutilize um identificador de volume sem ponderação
Um identificador de volume de rede preservado só é útil quando se refere ao mesmo destino lógico de cópia de segurança. Se clonar a partilha antiga para um segundo NAS ativo, os dois servidores não podem fingir que são exatamente o mesmo volume do Time Machine.
O Netatalk avisa que o seu UUID de volume proporciona uma desambiguação robusta e não deve ser editado ou copiado sem ponderação para outro servidor.
Durante a migração, mantenha apenas um destino como autoridade de cada vez. Coloque o substituto online com a identidade preservada apenas depois de o serviço anterior estar offline e de a cópia do sparsebundle estar concluída.
Preserve o Bonjour e a seleção da partilha durante a transição
Registe qual é a pasta partilhada explicitamente designada para o Time Machine e se o Bonjour anuncia essa pasta. Depois de reconstruir o NAS, verifique se a mesma pasta é publicada antes de a voltar a selecionar no Mac.
As orientações atuais da Synology exigem que os administradores definam a pasta do Time Machine e ativem a transmissão Bonjour do Time Machine ao utilizarem esse método de descoberta.
Se o nome de anfitrião do NAS tiver de mudar, confirme primeiro que a partilha pretendida está acessível através do novo caminho SMB e que ainda contém o sparsebundle protegido. Não permita que uma partilha substituta vazia se torne no primeiro destino que o Mac deteta.
Teste o histórico existente antes de retomar as cópias de segurança automáticas
Com as cópias de segurança automáticas pausadas, volte a ligar-se ao destino reconstruído, confirme que o sparsebundle antigo está visível e procure ou restaure um ficheiro conhecido do histórico anterior. Observe a partilha para detetar a criação de um segundo sparsebundle durante a primeira cópia de segurança controlada.
A ASUSTOR recomenda SMB para cópias de segurança do Time Machine nos sistemas NAS suportados, reforçando que a apresentação SMB específica do Time Machine no servidor faz parte do destino.
A manutenção está concluída quando o Time Machine acrescenta dados ao histórico existente e não aparece um segundo bundle. O artigo relacionado da ZimaSpace sobre um novo sparsebundle do Time Machine é o caminho de recuperação caso a identidade não tenha sido preservada e o Mac já tenha iniciado uma nova cópia de segurança.
Perguntas frequentes
É suficiente manter o mesmo nome da partilha SMB?
Não. O nome visível é apenas um dos sinais. O NAS pode recriar a partilha com uma capacidade do Time Machine, um anúncio do serviço, credenciais ou uma identidade de volume diferentes.
Devo renomear o sparsebundle existente para corresponder ao NAS reconstruído?
Não como medida preventiva. Preserve primeiro o bundle e mantenha estável a identidade do destino; renomear a imagem não atualiza automaticamente as relações utilizadas pelo Time Machine.
Posso testar a partilha reconstruída enquanto o servidor antigo do Time Machine ainda está ativo?
Tenha cuidado. Dois destinos ativos que apresentem a mesma identidade lógica podem confundir a descoberta e tornar pouco claro qual sparsebundle está a ser atualizado. Prefira uma transição controlada com um único servidor como autoridade.
Produtos recomendados
Suporte e Dicas
Mais para Ler
O Plex pode partilhar uma GPU com outro contentor Docker?
O Plex e outro contentor conseguem frequentemente aceder à mesma GPU, mas é necessário testar o suporte dos controladores, o mapeamento de dispositivos, a...
Como saber se um erro do Plex vem do cliente ou do servidor
Reproduza o mesmo item noutro cliente, compare o percurso da sessão e, em seguida, recolha provas do servidor apenas depois de o âmbito lhe...
Como configurar a cache do Plex e o armazenamento temporário de transcodificação
Proteja o estado persistente do Plex enquanto coloca os ficheiros temporários de transcodificação num armazenamento local adequado e, em seguida, verifique a limpeza, o...
