Restic: Adicione o comando para copiar todos os dados para outro repositório

Isso se destina a lidar com uma cópia única de um repositório (A) para um novo (B)? Ou isso pretende ser mais geral, executando uma "sincronização" ou atualização do conteúdo alterado entre (A) e (B) desde a última sincronização?

No momento, isso é intencionado para lidar apenas com uma cópia única, para que os usuários possam migrar para um repositório diferente em um local diferente ou com uma nova chave mestra.

Dada uma conexão de internet lenta, gostaria da possibilidade de fazer backup para s3 e outro local da forma mais eficiente possível.

@witeshadow Não tenho certeza de como isso pode ser feito de forma eficiente, já que os dados são criptografados no repo A com master A ', e precisam fazer o repo B com uma masterkey diferente B`. Precisamos ler todos os dados, descriptografar com A`, criptografar com B` e escrever. Não há como otimizar isso para largura de banda lenta. Vai doer...

a única otimização que posso pensar é ter um critério de seleção no repositório de origem A, usando os filtros de host, caminho e tags para que você não precise copiar tudo. No entanto, isso depende do seu caso de uso.

@ fd0 Eu só queria adicionar meu voto para esta solicitação de recurso. Posso fazer algo para que isso aconteça?

Você poderia implementá-lo ... A funcionalidade em si não é difícil de fazer, configurar os dois back-ends é o difícil. Não oferecemos suporte para acessar mais de um back-end (por exemplo, há apenas um $B2_ACCOUNT_ID ) ... então, acho que esse recurso depende de um arquivo de configuração adequado (consulte # 16).

Digamos que temos dois repos, A e B, e você gostaria de sincronizar A-> B para que, após a conclusão do processo, o conjunto de blobs (e instantâneos) em B seja um superconjunto do conjunto de blobs em A .

Portanto, você abre ambos os repositórios e carrega os arquivos de índice para cada um. Em seguida, você itera sobre o índice de A, para cada blob, verificando se o blob também está contido em B. Se isso for verdade, vá para o próximo. Se for falso, baixe, descriptografe, criptografe e faça upload para B.

O último é copiar os arquivos de instantâneo. Para cada arquivo de instantâneo em A, descriptografe o arquivo, criptografe-o novamente para B, armazene-o lá e pronto.

Como eu disse, a implementação técnica é bastante fácil :)

Excelente! Obrigado pelas dicas. Estou com essa coceira, então vou ver se consigo arranjar tempo para coçá-la - mas, a curto prazo, terei de ficar sem esse recurso restic merge . Se alguém chegar a isso antes de mim, tudo bem - ou irei voltar a fazer isso eventualmente!

Acho que já implementei ... / me coça a cabeça e procuro ...
... https://github.com/middelink/restic/tree/fix-323
Eu preciso verificar se ele ainda compila, porém, esse branch está com 228 commits atrás ...

Pode ser útil permitir não apenas uma cópia completa, mas também um subconjunto de instantâneos. Isso daria suporte a um caso de uso sugerido por # 1910 (backup para um repositório primário frequentemente e, a partir daí, backup para armazenamento externo / mais lento / mais caro com menos frequência) e, eu acho, não seria muito mais difícil de implementar do que uma cópia completa. Pode ser uma adição futura, embora :-)

Err… Alguma novidade para meros usuários sem habilidades de desenvolvimento para compilar e experimentar a sugestão de @middelink?

Este é principalmente um comentário "eu também", mas gostaria de ter a capacidade de copiar apenas instantâneos específicos de um repo para outro, em vez de uma semântica de "copiar tudo" ou "sincronizar"; por exemplo, faça backups diários para armazenamento local e, uma vez por semana, copie apenas o diário mais recente para um balde s3, etc.

Bem, então você está com sorte, meu cmd de cópia tira um ou mais ids de instantâneo. Na verdade, copiar tudo não é algo que ele faz. Você teria que listar seus ids de instantâneo primeiro e, em seguida, concatená-los no cmdline "cópia restic". Como vejo isso como um caso de uso degenerado, estou bem com isso.

Sem aprofundar muito nisso, talvez algumas discussões com ncw / rclone possam ser úteis ...

Também estou interessado na funcionalidade de mesclar / copiar, tenho um repositório em um pendrive que gostaria de mesclar / copiar para meu repositório central (mesmas senhas).
Alguma novidade sobre isso?

Parece que o branch fork foi atualizado para master , mas ainda não há um PR para ele.

@middelink Seu código é finalizado / mesclável? Se não, o que ainda precisa ser feito? Este é um recurso que eu realmente quero :)

@ teórico2019 O código em si está concluído, mas cada vez que me sento para criar um PR oficial, continuo encontrando coisas que preciso fazer antes que esteja pronto. Como documentação, como um log de mudanças / não lançado ...
Ah, e testes! Eu mencionei os testes? Precisa de testes: P

@middelink Fyi, testei seu branch com rebasing para o master upstream e funciona muito bem. Ele criou um novo instantâneo com o mesmo host, tags e data: +1:
Esperando por PR: tada:

Agora, com esse recurso, posso criar um repositório secundário, que é usado pelos clientes apenas quando o primeiro repositório está bloqueado para manutenção (por exemplo, poda). E a tarefa de poda pode acionar uma cópia do secundário depois de terminar, de forma que nenhum backup falte, portanto, tempo de inatividade zero no serviço de backup.

@middelink Você faria a gentileza de criar um PR de seu código? Ao fazer isso, permita também

O importante é que tenhamos uma base de relações públicas para trabalhar. Eu adoraria colocar seu ótimo trabalho em movimento, assim como outros, eu acho :) Deixe-me saber se você precisar de ajuda para criar o PR!

@rawtaz Claro. Deixe-me sincronizar e tudo mais. Por algum motivo, não encontrei tempo para fazê-lo antes, mas parece que agora tenho algum tempo.

Obrigado a todos pelo seu trabalho nisso!

Eu ainda tenho uma pergunta que não foi respondida pelos documentos (pelo menos para mim): Eu preciso remover ambos ou é o suficiente para fazer isso na origem e as exclusões de instantâneo são propagadas?

@lfrancke Ao usar o comando copy você lista especificamente os instantâneos que deseja copiar. Outros, instantâneos existentes, não existentes e previamente existentes, mas agora podados e não mais existentes, não são aplicáveis.

Se você copiar instantâneos do repo A para o repo B e, em seguida, esquecê-los e removê-los no repo A, eles não serão esquecidos e removidos no repo B automaticamente, você mesmo terá que fazer isso no repo B.

Excelente, muito obrigado @rawtaz pela resposta rápida e útil.