Por que motivo o Time Machine inicia um novo Sparsebundle em vez de continuar a cópia de segurança existente no NAS?

Eva Wong é a Redatora Técnica e e entusiasta residente na ZimaSpace. Uma geek de longa data com paixão por homelabs e software de código aberto, ela é especialista em traduzir conceitos técnicos complexos em guias acessíveis e práticos . Eva acredita que o auto-hospedagem deve ser divertida, não intimidante. Através dos seus tutoriais, ela capacita a comunidade adesmistificar configurações de hardware , desde a construção do seu primeiro NAS até dominar os contêineres Docker., from building their first NAS to mastering Docker containers.

O Time Machine inicia um novo sparsebundle quando deixa de associar o Mac atual e o destino NAS ao histórico de cópias de segurança existente.

A cópia de segurança antiga pode continuar visível como ficheiros, enquanto o Time Machine a considera pertencente a outro computador, a outro volume de rede, a outra identidade de partilha ou a uma configuração de destino incompatível. Os acionadores mais comuns incluem a migração do macOS, alterações na placa lógica ou no nome do dispositivo, a escolha de «Criar nova cópia de segurança», a mudança do nome do NAS ou da partilha, alterações na divulgação do Time Machine, a mudança de utilizador ou a apresentação de um UUID de volume diferente. Preserve ambos os sparsebundles antes de tentar voltar a ligar o histórico.

Confirme se foi realmente criado um segundo sparsebundle

Liste a partilha do Time Machine antes e depois de uma tentativa de cópia de segurança. Registe os nomes dos sparsebundles, as datas de criação, os tamanhos lógicos, os proprietários, o nome do Mac, o nome do anfitrião NAS, o nome da partilha e o destino selecionado.

A Apple explica que um Mac novo pode herdar um histórico de cópias de segurança antigo ou criar uma nova cópia de segurança, tornando a escolha durante a migração a primeira fronteira quando o novo bundle aparece após a substituição do hardware ou a utilização do Assistente de Migração.

Se apenas aparecerem ficheiros temporários dentro do sparsebundle existente, diagnostique antes uma cópia de segurança interrompida. Se aparecer um bundle distinto com um novo nome orientado para a máquina, prossiga para a identidade do Mac e do destino.

Compare a identidade atual do Mac com o histórico existente

Registe o nome atual do computador, o UUID do hardware ou a identidade da plataforma disponibilizada ao Time Machine, o histórico de migração, as alterações na placa lógica e se o Mac antigo ainda utiliza a cópia de segurança.

O módulo Samba vfs_fruit fornece suporte SMB para o Time Machine e um comportamento de identidade do servidor que afeta a forma como o macOS vê o destino de rede.

Não mude o nome do novo sparsebundle para corresponder ao antigo enquanto o Time Machine ou o SMB o tiver aberto. Alterar o nome do ficheiro não pode reescrever com segurança a identidade interna da cópia de segurança.

Verifique se o NAS continua a apresentar a mesma partilha e caminho

Compare o nome do anfitrião NAS antigo e atual, o endereço SMB, o nome da partilha, o caminho do conjunto de dados, a finalidade do Time Machine, o nome de descoberta e a conta dedicada às cópias de segurança.

O TrueNAS exige que uma partilha seja configurada com a finalidade SMB do Time Machine, pelo que recriar uma partilha SMB geral no mesmo caminho aparente pode continuar a apresentar uma capacidade de destino diferente.

Se a partilha antiga tiver sido renomeada ou recriada, restaure a identidade de serviço original quando for seguro fazê-lo ou migre deliberadamente o bundle antigo para um destino recém-validado antes de o selecionar.

Verifique se a pasta e o utilizador do Time Machine foram alterados

Confirme que a mesma pasta partilhada continua selecionada para o Time Machine e que a conta atual consegue ler, criar, mudar o nome e eliminar um ficheiro de teste junto ao bundle.

As instruções de configuração da Synology exigem a seleção da pasta partilhada SMB específica para o Time Machine.

Um novo utilizador ou uma nova pasta pode tornar o bundle antigo invisível ou impossibilitar a escrita, mesmo quando o Finder apresenta outra partilha com o mesmo nome visível. Evite montar simultaneamente o mesmo NAS através de várias contas durante os testes.

Verifique se as definições SMB do Time Machine não foram recriadas de forma diferente

Compare as atualizações do NAS, as definições do protocolo SMB, os sinalizadores do Time Machine, as quotas, as opções da reciclagem, os identificadores persistentes e qualquer migração de AFP para SMB.

A QNAP documenta uma definição de pasta de cópia de segurança do Time Machine dedicada, demonstrando que uma partilha normal com permissões de escrita e uma partilha anunciada para o Time Machine não são necessariamente equivalentes.

Volte a aplicar a predefinição suportada do Time Machine em vez de copiar manualmente um ou dois parâmetros do Samba a partir de uma configuração antiga. Preserve o bundle antigo antes de alterar os serviços.

Verifique se o UUID do volume de cópia de segurança anunciado foi alterado

Registe os detalhes do Bonjour ou da descoberta de serviços e compare a identidade do volume anunciada atualmente com a configuração guardada ou com a instância anterior do servidor.

O Netatalk documenta que o UUID do volume anunciado distingue os volumes do Time Machine, explicando por que motivo o mesmo caminho sob uma nova identidade de servidor pode ser tratado como outro disco de cópia de segurança.

Não invente nem duplique um UUID em dois destinos ativos. Restaure a identidade anterior apenas quando o servidor antigo tiver sido desativado e se souber que o histórico de armazenamento é o mesmo.

Volte a ligar o histórico existente sem eliminar nenhum dos bundles

Pare as cópias de segurança automáticas, crie um snapshot ou uma cópia dos metadados da partilha, desligue outros Macs, verifique se o sparsebundle antigo é montado em modo só de leitura e confirme qual é o Mac proprietário de cada histórico.

O artigo da ZimaSpace sobre uma cópia de segurança SMB do Time Machine indisponível aborda falhas gerais de acessibilidade e integridade da imagem; este artigo centra-se na criação de um segundo histórico.

O problema fica resolvido quando o Time Machine adiciona uma nova cópia de segurança ao histórico existente pretendido, não aparece um terceiro bundle e tanto a navegação de restauro atual como a recuperação de um ficheiro de teste são bem-sucedidas.

Perguntas frequentes

É possível juntar dois sparsebundles?

Não existe uma forma simples e suportada de os juntar ao nível dos ficheiros. Preserve ambos os históricos e volte a ligar o correto ou mantenha o bundle mais antigo como fonte de recuperação separada.

Devo eliminar o sparsebundle recém-criado?

Não até o histórico antigo estar novamente ligado e testado em segurança. O novo bundle pode conter a única cópia de segurança recente criada após a alteração da identidade.

Voltar a selecionar a mesma partilha visível continuará sempre a cópia de segurança antiga?

Não. O caminho da partilha pode parecer idêntico, enquanto a identidade do Mac, a conta, a identidade do volume anunciada ou a configuração do serviço Time Machine são diferentes.

Suporte e Dicas

Mais para Ler

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.