Como testar se o Time Machine está a continuar ou a recriar o histórico de cópias de segurança

Pode verificar a continuidade consultando a identidade do destino, o histórico de cópias de segurança herdado, a lista de snapshots recentes e verificando se a primeira execução nova se comporta como uma transferência incremental ou completa.

A decisão é importante quando um Mac volta a ligar-se a um NAS após uma migração, mudança do nome da partilha, alteração das credenciais ou reparação de um sparsebundle. Os dois estados concorrentes são: o histórico existente é herdado e prolongado, ou está a ser criado um novo conjunto de cópias de segurança ao lado do antigo. Comece com uma configuração guardada e dados descartáveis, observe um ramo de cada vez e pare se o teste aumentar o risco de perda de dados, permissões ou disponibilidade.

Defina as condições subjacentes à decisão sobre a continuidade do histórico do Time Machine

Registe o ambiente antes de alterar qualquer coisa: versões do software e do firmware, identidades dos dispositivos, caminho de montagem ou de rede, espaço livre, permissões e o sintoma observável. A linha de base deve preservar detalhes suficientes para reproduzir um Mac que volta a ligar-se a um NAS após uma migração, mudança do nome da partilha, alteração das credenciais ou reparação de um sparsebundle.

O primeiro candidato é que o histórico existente seja herdado e prolongado. O segundo é que esteja a ser criado um novo conjunto de cópias de segurança ao lado do antigo. A verificação atual de destino do tmutil define o mecanismo ou limite de comando utilizado no teste; não substitui a observação deste servidor doméstico específico.

Escreva a condição de aceitação e a condição de paragem antes de executar o discriminador. Um resultado aprovado deve alterar as evidências previstas por um dos ramos, mantendo inalterados os serviços não relacionados; um resultado reprovado deve devolver o sistema ao estado guardado, em vez de desencadear uma cadeia de correções especulativas.

Teste a afirmação sem reduzir o requisito original

Use este discriminador: inspecione o destino e o histórico de snapshots do tmutil e, em seguida, inicie uma cópia de segurança controlada enquanto monitoriza o tamanho transferido e o pacote de destino. Mantenha constantes a carga de trabalho, o cliente, o caminho, o conjunto de ficheiros e o momento, para que o resultado possa ser atribuído à variável alterada.

Use os destinos do Time Machine para selecionar o campo que pode realmente separar os ramos e, em seguida, registe o respetivo carimbo de data/hora, estado de saída, texto do erro, identidade do dispositivo ou snapshot, latência, bytes transferidos, permissões e estado de recuperação. Uma saída limpa do comando não é suficiente quando a identidade, a durabilidade ou o estado da aplicação são a afirmação em teste.

Repita o teste uma vez após um reinício, nova ligação, remontagem ou cache vazio, quando esse evento fizer parte da condição original. Se a primeira execução for destrutiva ou se não for possível restaurar o ambiente, pare e reproduza o teste numa cópia descartável.

tmutil destinationinfo
tmutil listbackups
tmutil status

Interprete os resultados aprovados, reprovados e excecionais

APROVADO: os novos snapshots locais ligam-se ao destino esperado e a execução transfere apenas os dados alterados. Registe a versão exata, a identidade e a carga de trabalho que foram aprovadas, para que a conclusão permaneça condicional em vez de se tornar uma afirmação universal.

REPROVADO: aparece um novo sparsebundle, o histórico está ausente ou o tamanho transferido aproxima-se de uma linha de base completa. Um resultado reprovado não prova automaticamente o ramo oposto quando a rede, a memória, as permissões ou a consistência da origem podem influenciar ambos; isole essas dependências partilhadas antes de avançar.

RESULTADO EXCECIONAL OU AMBÍGUO: pare a execução antes de ambos os históricos consumirem a quota e restaure a identidade de destino anterior. Preserve os registos e não execute comandos de reparação, limpeza, destruição, reparticionamento ou alteração recursiva de proprietários até existir uma cópia recuperável.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Confirme a decisão com a carga de trabalho original

Aplique a ação correspondente ao ramo observado e, em seguida, repita a condição original em vez de uma substituta reduzida. A decisão só é válida quando os novos snapshots locais se ligam ao destino esperado e a execução transfere apenas os dados alterados ao longo de dois ciclos ou do reinício, suspensão, interrupção ou transição de carga relevantes.

Use as quotas do Time Machine para verificar o fluxo de trabalho dependente mais próximo, mas mantenha inalterado o acionador original. Os conjuntos de dados, partilhas, contentores, utilizadores e pontos de recuperação não relacionados devem manter o acesso e o tempo de resposta anteriores.

O limite de paragem é explícito: se aparecer um novo sparsebundle, o histórico estiver ausente ou o tamanho transferido se aproximar de uma linha de base completa, volte à última configuração verificada, conserve as evidências e avance para um teste mais profundo da plataforma ou do hardware apenas quando o ramo for repetível.

Depois de o resultado pretendido se manter, compare-o com a verificação da restauração, para garantir que a correção não transfere o risco para um serviço vizinho. Um teste do objetivo bem-sucedido com uma nova cópia de segurança, identidade, falha de tempo limite ou falha de disponibilidade continua a ser uma alteração reprovada.

Perguntas frequentes

Na continuidade do histórico do Time Machine, as pesquisas restantes normalmente dizem respeito a saber se uma primeira execução grande significa sempre que o histórico foi perdido, se dois sparsebundles podem ter nomes semelhantes e se o pacote antigo deve ser eliminado depois de começar uma nova cópia de segurança. As respostas abaixo mantêm esses casos-limite separados da decisão principal.

O limite de aceitação não muda: os novos snapshots locais ligam-se ao destino esperado e a execução transfere apenas os dados alterados. Se uma condição posterior alterar o sistema de ficheiros, a identidade, o caminho de rede ou a versão da aplicação, repita apenas o discriminador afetado por essa alteração.

Pare de alargar a experiência quando aparecer um novo sparsebundle, o histórico estiver ausente ou o tamanho transferido se aproximar de uma linha de base completa. Nesse momento, pare a execução antes de ambos os históricos consumirem a quota e restaure a identidade de destino anterior; preserve as evidências antes de avançar para o responsável pela plataforma, pelo armazenamento ou pelo hardware.

Uma primeira execução grande significa sempre que o histórico foi perdido?

Não. Atualizações do sistema operativo, exclusões, alterações do sistema de ficheiros ou longos intervalos podem criar incrementais grandes; verifique a identidade do destino e a linhagem dos snapshots.

Dois sparsebundles podem ter nomes semelhantes?

Sim. Use a identidade da máquina e os metadados do destino, não apenas o nome do ficheiro.

O pacote antigo deve ser eliminado depois de começar uma nova cópia de segurança?

Não, até a continuidade ser comprovada ou o novo histórico completo ter passado um teste de restauração.

Na continuidade do histórico do Time Machine, a resposta prática continua a ser condicional: os novos snapshots locais ligam-se ao destino esperado e a execução transfere apenas os dados alterados. Quando aparecer um novo sparsebundle, o histórico estiver ausente ou o tamanho transferido se aproximar de uma linha de base completa, pare a execução antes de ambos os históricos consumirem a quota e restaure a identidade de destino anterior; um sucesso parcial que não resista à carga de trabalho original não é compatibilidade.