Restic: Dados do instantâneo incompleto.

Ah, hm. Você precisa de um arquivo específico ou apenas "todos os dados que existem"? Os dados estão lá, e o restic tem todos os meios para retirá-los, mas isso significaria criar um script em torno do restic (que será muito lento) ou adicionar um código personalizado para o restic.

Pergunta honesta: qual a importância dos dados para você? Eu poderia gastar algum tempo hoje hackeando algo para você, o que deve lhe dar acesso a quase todos os dados que foram carregados para o repo, mas provavelmente não está tão "pronto para produção" como a maioria do código. :)

Os dados são muito importantes para mim e infelizmente não existe outra cópia. Sei que não é o ideal, mas era um problema que eu estava tentando resolver. Estou buscando uma correção de hardware para tentar trazer o volume de volta online, mas isso não parece muito promissor no momento. Se houvesse uma maneira de especificar um diretório e poder acessar e baixar tudo dentro desse diretório, seria um grande salva-vidas. São muitos dados (muitos deles são projetos de vídeo), então a opção mais rápida seria preferível. Dito isso, eu realmente não sei quanto trabalho seria necessário e agradeço que este seja um software livre, mas ficaria extremamente grato se isso fosse possível.

ok, vou ver o que posso fazer.

Muito obrigado.

Você pode começar executando restic rebuild-index , portanto, temos um novo índice cobrindo todos os pacotes no repo.

Começando agora.

Uau, isso é muito generoso da sua parte @ fd0.

Se eu puder ajudar com o teste de algo relacionado a isso, me avise.

restic rebuild-index me pedir a senha do repo? Ainda não. Eu suspeito que pode levar muito tempo devido à quantidade de dados no repo. Estou perfeitamente satisfeito em deixá-lo rodar durante todo o fim de semana ou na próxima semana, se necessário. Só quero ter certeza de que ele não precisa de uma senha minha antes de deixá-lo sem supervisão por um longo período.

Hm, ele deve pedir uma senha logo no início. Ele precisa descriptografar todos os cabeçalhos de todos os arquivos do repo. Você talvez tenha a variável de ambiente RESTIC_PASSWORD exportada, então ela não precisa de uma senha sua?

Deve imprimir algo assim no início:

repository ed6136ad opened successfully, password is correct

Pelo menos quando executado interativamente (sem redirecionamento de stdout para um arquivo de log).

Você também pode pular rebuild-index se os últimos 15 minutos dos dados carregados não forem tão importantes, sempre podemos fazer isso mais tarde.

Eu não tenho a variável de ambiente RESTIC_PASSWORD definida, mas vou defini-la e apenas deixar o comando ser executado. Ele não retornou nada por cerca de 10 minutos, então eu dei um ctrl-c e tentei novamente. Minha sintaxe está correta, certo? restic -r b2:MY_BUCKET_NAME:/ rebuild-index Em qualquer caso, os últimos 15 minutos de dados devem ser muito pequenos em comparação com o total de dados carregados, então eu ficaria perfeitamente feliz em voltar a isso mais tarde.

ok, então não execute rebuild-index ainda, para que possamos experimentar o código de recuperação :)

Eu enviei um commit para o branch recover-data , apenas crie o restic ( go run build.go ) e chame-o assim:

$ restic -r b2:MY_BUCKET_NAME:/ recover

Ele deve então listar todas as árvores no repo, localizar as árvores raiz e criar um novo instantâneo referenciando todas as árvores raiz:

repository abe002d6 opened successfully, password is correct
load index files
load 543 trees
tree (543/543)
done
found 2 roots
save tree with 2 nodes
saved new snapshot 26f25bf1

Então você tem um instantâneo ( 26f25bf1 neste caso) que você pode restaurar, ou apenas usar restic mount para navegar nele. Você também pode simplesmente listá-lo:

$ restic ls -l 26f25bf1 /
repository abe002d6 opened successfully, password is correct
snapshot aac6d0ed of [/recover] filtered by [/] at 2018-08-23 22:23:56.903268714 +0200 CEST):
drwxr-xr-x     0     0      0 2018-08-23 22:23:56 /0b9e25fb
drwxr-xr-x     0     0      0 2018-08-23 22:23:56 /d0d9386a

Os diretórios de nível superior são nomeados de acordo com os IDs da árvore, então eles são um pouco enigmáticos, mas o próximo nível abaixo tem nomes normais.

Deixe-me saber se isso te ajudar!

Então, para adicionar um pouco de história de fundo: eu li a edição do github, depois fui tomar um banho e pensei comigo mesmo, "hm, isso não é tão difícil de fazer". Acontece que eu estava certo e não estava. Se essa funcionalidade for útil para outras pessoas, podemos transformá-la em um comando adequado mais tarde, mas por agora espero que funcione para você e você possa acessar os dados que já foram enviados para o B2.

Quantos dados foram? Quanto você recuperou?

Boa sorte!

Uau! Isso foi rápido! Muito obrigado! Acabei de clonar o repo e vou tentar construí-lo agora. Eu também descobri por que o índice de reconstrução não estava funcionando. Era um problema de DNS na rede em que nosso servidor está. Eu consertei isso e recebi Fatal: unable to create lock in backend: repository is already locked by PID 41208 então, aparentemente, meu upload não foi interrompido normalmente. O comando unlock parece ter limpado isso e o índice de reconstrução está em execução.

Farei o máximo que puder com isso hoje, mas estou partindo para o norte de Michigan no fim de semana em cerca de 15 minutos e não acho que meu acesso à Internet será muito bom lá. Isso vai chamar toda a minha atenção na segunda-feira, quando eu voltar, e vou te dar mais detalhes :-)

Muito obrigado por isso! Desculpe deixá-lo esperando, mas entrarei em contato na segunda-feira.

Se esta funcionalidade for útil para outros, podemos transformá-la em um comando adequado mais tarde

Eu adoraria ajudar de qualquer maneira que eu puder. Minha velocidade de upload aqui é de 1 Mbps e, portanto, meus backups iniciais podem levar de 3 a 6 meses. Ter uma maneira de restaurar antes de terminar seria um excelente recurso, especialmente se não for muito difícil, como você diz. Deixe-me saber como posso ser útil! Muito obrigado por trabalhar nisso! : D

Além disso, acho que sua solução é brilhante. Elegante e bastante simples.

Desculpe deixá-lo esperando, mas entrarei em contato na segunda-feira.

Não se preocupe com isso, só estou curioso para saber se funciona: óculos de sol:

Os dados estão seguros no B2 e não irão embora. Mesmo o comando recover não mudará nenhum dado, ele apenas irá lê-lo, adicionar outro arquivo e um instantâneo e pronto.

Então, para lhe dar um pouco de contexto (talvez eu expanda isso em uma postagem de blog mais tarde): Por trás, um repositório restic contém diferentes tipos de arquivos, por exemplo snapshot e data arquivos:

• data arquivos contêm um monte de tree ou data blobs menores, com um cabeçalho no final descrevendo o que está no arquivo e onde exatamente
• snapshot arquivos contêm apenas um minúsculo documento JSON que descreve um instantâneo, que faz referência a um tree

Quando um arquivo é salvo com o restic, ele é cortado em data blobs, que são coletados e salvos juntos em um ou mais arquivos no repositório. O nome do arquivo junto com a lista de referências (IDs) aos data blobs é então salvo em uma árvore. Quando o restic terminar de arquivar o diretório, a lista de arquivos (nomes e referências para data blobs) é salva como um tree blob em outro arquivo data .

Para subdiretórios, o restic armazena o nome do subdiretório junto com a referência do tree blob que descreve o conteúdo em outro tree .

No final da execução de restic backup , temos uma raiz tree que não é referenciada por nenhuma outra árvore, mas contém todas as referências a todas as árvores de nível superior e, portanto (indiretamente) a todos os arquivos e sub-dirs no backup. Como última etapa, restic cria um novo arquivo snapshot que faz referência à raiz tree .

Se você disser a restic para esquecer um determinado instantâneo, a árvore raiz não será mais referenciada. restic prune detecta isso e remove a árvore e todos os outros tree e data blobs desnecessários.

Em geral, tree só é salvo no repositório quando todos os arquivos e subdiretórios nele são salvos com sucesso. Portanto, assim que um tree blob estiver lá, podemos assumir que os dados aos quais ele faz referência (incluindo subdiretórios) também estão lá.

Quando o restic é abortado durante o backup, haverá um monte de tree blobs no repo, junto com os dados nos arquivos que eles referenciam. Portanto, para recuperar os dados, o restic só precisa fazer o seguinte:

• faça uma lista de todos os IDs de árvore, observe quais árvores foram referenciadas (inicialmente: nenhuma)
• para cada árvore:
  
  
  
  • carregar a árvore
  
  
  • para cada entrada na árvore:
    
    
    
    
    
    • se for um diretório, faz referência a outra árvore, marque essa árvore como referenciada na lista
    
    
    
  
  

Em seguida, repasse a lista de árvores, jogue fora todas as que vimos referências. As árvores restantes são as árvores raiz, o que significa árvores que são (ou foram) diretamente referenciadas por um instantâneo ou que estão "penduradas" como resultado de uma execução abortada de restic backup .

Como última etapa, crie uma nova árvore que lista todas as árvores raiz, salve-a no repositório e, em seguida, crie um novo instantâneo que faça referência a essa nova árvore.

Você pode então usar este novo instantâneo normalmente, exceto para os nomes enigmáticos dos diretórios (que são apenas os IDs de árvore curtos das árvores raiz que encontramos).

Antes de mesclar isso com o master, acho que devemos fazer o seguinte:

• Adicione uma opção a recover que exclui as árvores raiz referenciadas por instantâneos existentes, de modo que só obteremos árvores raiz realmente pendentes. Talvez esse comportamento deva ser o padrão, a maioria dos usuários provavelmente não está tão interessada nos dados que podem acessar por meio de instantâneos existentes ...
• Disponibilize também blobs data não referenciados no novo instantâneo, para que os usuários possam juntar as partes dos arquivos que ainda não foram incluídos em um objeto tree .
• Defina metadados sensíveis para a nova árvore e para o novo instantâneo. No momento isso é muito feio (apenas o suficiente para que funcione).
• Melhor relatório de progresso, isso é muito hacky agora

Pequena atualização sobre isso: comecei um rebuild-index antes de sair na quinta-feira passada. Ele morreu antes de eu voltar com read: connection reset by peer . Eu reiniciei ontem com um número maior de conexões paralelas para b2 e parece estar funcionando bem. É de apenas 5% agora, mas espero que demore um pouco. O balde b2 tem cerca de 90 TB e os diretórios dos quais eu estava fazendo backup provavelmente tinham cerca de 110-120 TB.

Sinceramente, estou muito impressionado que o Restic permaneceu tão estável durante o upload. Eu tentei o Cloudberry para Mac antes de tentar o Restic e não consegui fazê-lo funcionar com tantos dados. Eu uso o Restic para fazer backup do meu laptop em casa e adoro isso, então pensei em tentar fazer isso. Como ainda não terminei meu upload inicial, não tenho ideia de como algo como prune irá, mas ficarei feliz em mantê-lo atualizado se você precisar de dados sobre como o Restic se comporta com grandes volumes de dados . Se eu conseguir fazer com que ele conclua todas as operações necessárias para manter um backup semanal em menos de uma semana, acho que será um ótimo candidato para lidar com esses backups.

Por enquanto, tenho algumas perguntas: Devo deixar este rebuild-index executado até a conclusão antes de tentar um recover ? Vou perder alguma coisa se não o fizer? Estive pensando sobre isso e acho que gostaria de recuperar o máximo possível na primeira tentativa, se possível, já que as coisas demoram um pouco para rodar com tantos dados, mas se for melhor eliminar isso, execute recover primeiro e rebuild-index depois, posso fazer isso. A execução de rebuild-index ou recover com uma bandeira --quiet acelera as coisas como faz com o comando backup ?

OK legal! Eu recomendaria fazer o seguinte:

• Abortar rebuild-index
• Execute restic recover
• Dê uma olhada nos dados que o instantâneo recém-criado contém

Se quiser tentar, execute rebuild-index novamente e extraia os megabytes restantes de dados do repo. Provavelmente, isso terá menos de algumas centenas de megabytes, e é provável que isso não revele nenhum dado novo ainda não contido no instantâneo. Mas você pode tentar :)

Enquanto rebuild-index está em execução, você não pode acessar o repositório.

A execução de rebuild-index ou recovery com um sinalizador --quiet acelera as coisas como acontece com o comando backup?

Não.

Deixei as coisas rodarem durante a noite e parece que encheu o disco rígido e falhou:

found 755 roots Fatal: unable to save new tree to the repo: fs.TempFile: open /var/folders/tq/67qp8py137n_5nzf563qlylr0000gn/T/restic-temp-pack-913168611: no space left on device

Existe uma maneira fácil de saber quantos dados essa operação terá de baixar ou uma maneira de reduzir a quantidade de downloads?

Além disso, se eu quiser liberar esse espaço em disco, restic cache --cleanup a maneira de fazê-lo?

Não, isso remove apenas os diretórios de cache que não foram usados ​​por 30 dias. Apenas remova o diretório de cache, que deve estar em algum lugar do seu diretório inicial.

Qual comando você executou exatamente? Tanto rebuild-index quanto recover não devem salvar muitos dados no disco rígido, exceto para o cache de metadados ...

Não na minha mesa no momento. mas era algo como: ./restic -o b2.connections=x -r b2:mybucket:/ recover Acho que x definido como algo enorme. Isso pode ter sido parte do problema. Posso reiniciá-lo sem o bit -o b2.connections=x . Encontrei o diretório do cache e o excluí.

Em primeiro lugar, uma ferramenta incrível.
Também preciso fazer backup de terabytes de dados em uma conexão lenta e ter a chance de o backup falhar enquanto não estiver completo. Existe uma maneira recomendada de fazer backup de apenas alguns arquivos por vez?

Existe uma maneira recomendada de fazer backup de apenas alguns arquivos por vez?

O que geralmente funciona (ouvi dizer) é salvar partes individuais dos dados de origem (por exemplo, diretórios únicos) e, quando terminar, salvar todos os diretórios juntos. Quando os dados de origem não foram alterados, o restic não deve carregar quase nada devido à desduplicação integrada.

Um lugar melhor para essas perguntas seria o fórum em https://forum.restic.net , a pergunta (e as respostas!) São muito mais fáceis de descobrir lá.

@pauletg então, como foi?

Eu propus o novo comando recover em # 2056.

Não avancei muito na recuperação instável desde meu último post. A boa notícia é que conseguimos reativar o servidor e os dados não foram prejudicados na falha, então eu tenho meus dados. O comando de recuperação parece preencher o HD da minha máquina, antes que pudesse ser concluído. Isso pode ter sido causado por vários fatores: Meu backup era enorme e eu estava usando um grande número de conexões com o b2 para o upload e o HD na máquina que estava usando para a recuperação era relativamente pequeno. Tenho certeza de que provavelmente funcionaria muito bem se meu backup tivesse um tamanho mais razoável. Avise-me se houver mais informações que possam ser úteis para você. Eu realmente aprecio você trabalhar nisso e ter esse recurso disponível para backups do meu laptop é muito bom.

Obrigado pelo feedback! Se quiser (e tiver muito tempo), você pode tentar novamente com --no-cache , mas isso vai demorar ainda mais. Encerrarei este problema quando # 2056 for mesclado.

Informe-nos se tiver comentários adicionais! :)