Evite fotografias duplicadas importando primeiro uma exportação canónica e ativando a cópia de segurança do telemóvel apenas depois de classificar as cópias exatas e as variantes editadas.
As migrações de bibliotecas na nuvem contêm frequentemente originais, cópias editadas, transferências redimensionadas, versões de álbuns partilhados, componentes de Live Photos, ficheiros auxiliares de metadados e pastas de exportação repetidas. Uma galeria autoalojada pode rejeitar duplicados com os mesmos bytes, mas aceitar ficheiros visualmente idênticos cuja compressão, dimensões, metadados ou nomes de ficheiro sejam diferentes. O processo seguro prepara a migração fora da biblioteca ativa, regista os hashes e as pastas de origem, importa um lote controlado e verifica como a galeria representa as variantes antes de iniciar a cópia de segurança automática do telemóvel.
Faça o inventário de todas as origens que podem conter a mesma fotografia
Liste os arquivos de exportação da nuvem, o rolo da câmara do telemóvel, a biblioteca de fotografias do computador, os álbuns partilhados, as pastas de transferências, as bibliotecas de parceiros, as pastas de NAS antigas e qualquer biblioteca externa montada na galeria. Registe o intervalo de datas e o número de ficheiros de cada origem.
Os duplicados surgem frequentemente ao importar uma cópia da nuvem e, em seguida, permitir que o telemóvel carregue o original local. Uma discussão sobre o Immich descreve como as Fotografias do Google e a cópia de segurança móvel produziram duplicados aparentes porque a versão da nuvem estava comprimida, enquanto o telemóvel forneceu um ficheiro diferente em resolução total.
Escolha a origem que será considerada oficial para os originais. Mantenha as restantes offline durante a primeira importação, para que uma cronologia cheia de duplicados não se torne o ambiente usado para decidir o que eliminar.
Separe os duplicados exatos das variantes visuais
Gere hashes criptográficos dos ficheiros antes da importação. Hashes correspondentes indicam bytes idênticos, enquanto hashes diferentes podem representar edições, recompressão, alterações de metadados, exportações redimensionadas, componentes de fotografias em movimento ou capturas genuinamente diferentes.
Utilizadores que migraram para o Immich criaram verificações de hashes antes da importação porque as transferências a partir de bibliotecas externas podem não efetuar a mesma verificação de duplicados que os carregamentos através da API. A estratégia descrita consistia em comparar os hashes antes de copiar.
Não elimine automaticamente ficheiros apenas porque parecem iguais numa miniatura. Preserve o original de maior resolução, a edição pretendida, os componentes de movimento e os ficheiros auxiliares de metadados até serem comparados fora da galeria.
Normalize a estrutura das pastas de exportação sem reescrever os originais
Extraia todos os arquivos da nuvem para um diretório de preparação e identifique partes repetidas de arquivos, sufixos como “original” e “editado”, ficheiros JSON auxiliares, duplicados de álbuns e ficheiros divididos por vários pacotes de exportação.
Mantenha os nomes dos ficheiros e os carimbos temporais inalterados durante o primeiro inventário. Mudar o nome, recodificar ou reescrever os metadados antes de calcular os hashes pode transformar duplicados exatos em ficheiros com bytes diferentes, que a galeria já não conseguirá identificar automaticamente.
Crie um manifesto que contenha o arquivo de origem, o caminho relativo original, o nome do ficheiro, o hash, o tamanho, as dimensões, a hora da captura e o caminho do ficheiro auxiliar. Isto torna reversível qualquer eliminação posterior e explica por que razão dois recursos semelhantes entraram na biblioteca.
Importe primeiro um pequeno lote representativo
Selecione um lote que contenha um JPEG normal, uma fotografia HEIC, uma imagem editada, uma Live Photo, um vídeo, uma sequência, uma cópia de um álbum partilhado e dois duplicados exatos. Importe-o utilizando o mesmo método planeado para a biblioteca completa.
Os recursos da nuvem e locais podem aparecer duas vezes numa cronologia móvel, mesmo quando um representa a cópia no servidor e o outro permanece apenas no telemóvel. Um relatório do Immich documenta fotografias apresentadas com estados de nuvem e de nuvem desativada.
Verifique se a galeria rejeita hashes idênticos, agrupa componentes de movimento, preserva edições, lê ficheiros auxiliares e distingue recursos apenas locais dos recursos carregados. Ajuste o método de importação antes de avançar para a exportação completa.
Não ative a cópia de segurança móvel até a importação do histórico estar estável
Pause a cópia de segurança automática em todos os telemóveis que contenham parte da biblioteca da nuvem migrada. Caso contrário, o cliente móvel poderá carregar milhares de recursos enquanto o servidor ainda está a importar o mesmo histórico a partir dos ficheiros exportados.
A duplicação entre origens pode repetir-se quando um utilizador mantém uma cópia da biblioteca externa, mas elimina o carregamento, porque o cliente móvel poderá voltar a carregar o mesmo recurso mais tarde. Uma discussão sobre o Immich descreve um ciclo recorrente de duplicação entre o telemóvel e a biblioteca externa.
Depois de concluir a importação histórica, compare o número de itens pendentes no telemóvel com o manifesto do servidor. Ative primeiro a cópia de segurança de um pequeno álbum recente e confirme que os recursos históricos conhecidos são ignorados ou apresentados como já salvaguardados.
Trate deliberadamente as bibliotecas externas e as bibliotecas carregadas
Decida se os ficheiros migrados ficarão como carregamentos geridos pela galeria ou como uma biblioteca externa só de leitura. Evite apresentar os mesmos ficheiros físicos através dos dois métodos.
Mover recursos da biblioteca gerida para uma biblioteca externa pode produzir entradas duplicadas na cronologia quando o registo antigo da base de dados permanece e a nova análise externa adiciona outro recurso. O resultado descrito foi um registo órfão e um novo duplicado.
Utilize um único modelo de propriedade para cada conjunto de ficheiros. Se mudar de modelo, faça uma cópia de segurança da base de dados, conclua a remoção ou limpeza suportada do caminho antigo e confirme que os registos obsoletos desaparecem antes de analisar a nova localização.
Analise os duplicados com contexto de metadados e recuperação
Quando a galeria identifica duplicados, compare a resolução, o tamanho do ficheiro, o codec, a hora da captura, o histórico de edições, o emparelhamento de Live Photos, a pertença a álbuns, os favoritos, as atribuições de rostos e a origem da cópia de segurança antes de escolher o recurso a manter.
A deteção de quase duplicados pode identificar diferentes resoluções ou codificações da mesma cena, mas não consegue saber qual versão preserva a edição preferida do utilizador ou o original de maior qualidade. Trate a deteção automática como uma fila de revisão, não como uma instrução para eliminar.
O guia de migração de dados para NAS da ZimaSpace apresenta a regra geral: mantenha a exportação da nuvem e a biblioteca original até verificar as contagens de ficheiros, os metadados, os álbuns e restauros representativos.
Conclua a migração com uma auditoria reproduzível
Compare os manifestos de origem, as contagens de ficheiros importados, os duplicados exatos rejeitados, as variantes mantidas, os ficheiros falhados e as contagens de itens pendentes nos telemóveis. Faça verificações pontuais de vários anos, álbuns, edições, vídeos e Live Photos.
Mantenha a exportação original da nuvem imutável e crie uma segunda cópia de segurança da biblioteca autoalojada antes de cancelar uma subscrição ou remover recursos da nuvem. A limpeza de duplicados não é uma cópia de segurança e nunca deve ser a única operação que altera as cópias.
A migração está concluída quando cada original tem uma única cópia canónica intencional, as variantes editadas permanecem distinguíveis, os telemóveis carregam apenas recursos novos, as bibliotecas externas e geridas não se sobrepõem e o manifesto explica todos os duplicados excluídos ou mantidos.
Suporte e Dicas
Mais para Ler

Por que motivo o restauro de um volume Docker recria o conteúdo dos ficheiros, mas elimina os atributos estendidos?
Um diagnóstico da restauração de volumes que abrange o inventário de xattr, as opções do tar e do Rsync, os namespaces, o suporte do...

Porque é que um contentor em execução mantém o limite de memória antigo depois de o ficheiro Compose ser alterado?
Um diagnóstico dos limites de memória que abrange cgroups ativos, reinício versus recriação, campos do Compose, limites rígidos e flexíveis, âmbitos superiores, swap e...

Porque é que reiniciar um proxy reverso invalida todas as sessões de uma aplicação auto-hospedada?
Um diagnóstico da perda de sessão que abrange o âmbito do reinício, a propriedade dos cookies, a rotação de segredos, as sessões suportadas por...

