Aqui está uma encarnação mais antiga desta solicitação que encontrei: # 555

+1

Eu também acho que esse seria um recurso muito útil.

Então, deixe-me resumir: você está executando restic backup /mnt/backup-snapshot , então o arquivo /mnt/backup-snapshot/foo está /mnt/backup-snapshot/foo no instantâneo, mas você gostaria que fosse /foo . Isso é correto?

Você pode conseguir isso com o restic> 0.9.0 mudando o diretório atual, apenas execute cd /mnt/backup-snapshot e então restic backup . .

Isso funciona para você?

Alterar o cwd funciona, mas percebi que há um efeito colateral desagradável se usar arquivos para inclusão / exclusão. Parece que se caminhos absolutos forem colocados lá, eles serão ignorados ao alterar o cwd . Eu prefiro usar caminhos absolutos também - por agora provavelmente vou seguir pelo caminho chroot, mas concordo que seria melhor ter algo semelhante ao sinalizador -C em tar .

Acho que essa opção de root falsa seria um recurso útil. Eu adoraria fazer o mesmo que cdhowie, mas com instantâneo apfs no macOS. Para acessar os instantâneos apfs somente leitura, eles precisam ser montados em algum lugar. Mas, ao restaurar, gostaria que o caminho "original" fosse o caminho canônico armazenado no instantâneo.

o truque do cd infelizmente não é ideal, pois tenho muitos (125) de caminhos absolutos coletados de StdExclusions.plist (lista de exclusão de backup padrão do macOS) e todos os arquivos e pastas que o mdfind pode encontrar com o conjunto de atributos com_apple_backup_excludeItem.

Só deixa o problema se você colocar / mnt no arquivo para ignorar e iniciar o backup a partir de / mnt / fs-snapshot, ele se excluirá.

Além disso, cd $ path && backup restic. ainda fornece $ path na visão geral do instantâneo, enquanto os pathes no instantâneo são baseados em /.

Eu encontrei uma solução alternativa com proot.

Também queria encontrar uma maneira de remover o prefixo do caminho. Meu caso de uso é um pouco diferente - estou criando um instantâneo zfs ( fs@$(date +%s) ) e queria fazer o backup sem ter que montá-lo ( /path/to/mount/.zfs/snapshots/${TS} ) - desta forma, espero não ter preocupar-se com o instantâneo não desmontando e ficando para sempre no caso de algo travar.

A saída de restic forget para isso me faz pensar que instantâneos com caminhos diferentes não serão esquecidos de acordo com a programação (diário / semanal / etc.).

O comentário proot de @blurayne foi um bom ponto de partida, acho que cheguei à mesma conclusão:

$snap_path="/path/to/where/snapshot/is/accessible"
$orig_fs="/path/to/filesystem"
proot -b "${snap_path}":"${orig_fs}" restic backup "${orig_fs}"

Isso funciona bem, e agora todos os instantâneos têm o mesmo caminho, sem cd ou pushd necessários. Além disso, o proot está disponível no espaço do usuário, portanto, se os backups não forem feitos como root, ainda será possível.

Meu caso de uso: despejar dados do banco de dados em um diretório temporário, como / tmp / tmpzmn28r02 (obtido via mktemp ou mkdtemp do python ()) e depois fazer o backup.
Este método marcará todos os arquivos entre 2 instantâneos como sendo diferentes. Portanto, preciso de uma maneira de dizer ao restic para ignorar totalmente o prefixo do diretório temporário.
Outro caso de uso possível: hoje eu tenho todas as minhas imagens em '/ mnt / something / pictures', mas amanhã, o mesmo conteúdo estará em '/ mnt / external / pictures-from-home' (esquema de particionamento diferente / qualquer que seja)

Além disso, se você quiser usar o restic e fazer backup de vários diretórios na mesma execução, para usar o mesmo instantâneo, isso fica ainda mais complicado.

Até que uma correção seja feita, vou usar a proposta 'proot' - obrigado @blurayne e @ whi-tw

Oi! Eu tenho um caso semelhante. Por exemplo, tenho pastas

/srv/my/long/server1/path/data (with many subfolders and dozen of files)
/path/to/dump.sql
/path/certbot.tar.gz

então eu quero ter reforços como

/data
/dump.sql
/certbot.tar.gz

e obter capacidade de restaurar em outro servidor (não sei sobre a estrutura de pasta anterior) por caminho diferente (relativo).

Não tenho ideias quentes para resolver essa tarefa trivial. Restic é uma ferramenta incrível, mas ... por que funciona tão difícil para os usuários finais?

Estou copiando na pasta de backup predefinida (/ backup) tudo o que preciso e aí executo o backup do Restic (via cd). Mas essa solução funciona apenas para pequenas quantidades de dados.

Será ótimo ter a habilidade de restaurar com a subpasta --include logo após o template (ou incluindo esta máscara). ex.:
restic restore --include data --target /my/new/path
e obter como resultado
/my/new/path/data

Obrigado @ whi-tw pela solução com proot -b /path/i/wanted:./path_in_repo restic backup . - funciona para mim.

Meu caso de uso é migrar instantâneos de outras soluções de backup para o Restic (Time Machine e imagens de disco no meu caso).

Eu os migro de onde monto a imagem ou subdiretório do snapshot criado pelo TM, que pode ficar muito longo, por exemplo /Volumes/TimeMachine-Backups/Backups.backupdb/MacBook Pro/2019-05-22-185113/Macintosh SSD/ .

A solução cd funciona ao usar restic mount e restic restore , mas o caminho absoluto do instantâneo original é listado quando executo restic snapshots .

Como é um instantâneo migrado, gostaria que também fosse o caminho de onde o instantâneo original foi tirado. Além disso, com os caminhos longos, também torna a saída de restic snapshots um pouco barulhenta.

Uma bandeira para definir um prefixo alternativo seria ideal para mim também.

Isso funciona bem e agora todos os instantâneos têm o mesmo caminho, sem cd ou pushd necessários. Além disso, o proot está disponível no espaço do usuário, portanto, se os backups não forem feitos como root, ainda será possível.

Esta teria sido uma boa solução alternativa, mas proot não está disponível no macOS e não parece vir tão cedo (a maioria dos códigos escritos especificamente no Linux): O PRoot funciona no MacOSX?

Existe outra solução alternativa que vem à mente?

Meu caso de uso: despejar dados do banco de dados em um diretório temporário, como / tmp / tmpzmn28r02 (obtido via mktemp ou mkdtemp do python ()) e depois fazer o backup.
Este método marcará todos os arquivos entre 2 instantâneos como sendo diferentes.

Observe que os arquivos provavelmente _são_ diferentes de qualquer maneira; backups de banco de dados geralmente incluem um carimbo de data / hora nas primeiras linhas.

Você pode ajustar os comandos de despejo do banco de dados para excluir comentários dinâmicos e ser classificado por chaves primárias para tornar os dados de alteração lenta realmente dedupíveis

Uma atualização: 'proot' funcionou apenas em uma máquina para mim, em outra ele segfaults.
Uma alternativa (mais recente) - bolha
Adicionado um wrapper sobre ele (anexado) que deve funcionar com os mesmos parâmetros '-b'. Parece funcionar até agora. Observe que, dependendo de suas necessidades e localizações de diretório, pode ser necessário alterar um pouco o invólucro.
Espero que ajude vocês, mas estou ansioso pelo apoio dentro do próprio restic.

proot.sh.txt

Tentei proot . Parece quebrar a capacidade de executar o restic como não root com recursos adicionais (https://restic.readthedocs.io/en/stable/080_examples.html#full-backup-without-root); pelo menos recebi scan: Open: open /.pulse: permission denied erros que não obtive ao executar o Restic sem proot .

O mesmo problema com bwrap .

Então, para mim, remover um prefixo de caminho no próprio restic ainda parece útil.

Esse recurso ausente torna mais difícil do que o necessário para fazer backup de VMs.
Meus instantâneos de VM acabam em uma pasta temporária e, em seguida, são armazenados em backup pelo Restic.
Isso resulta no seguinte:

ID        Time                 Host         Tags        Paths
--------------------------------------------------------------------------------------
02c536db  2020-04-10 14:28:27  resolver-02              /tmp/tmp.vOFFxxly9O/config.xml
c5709aed  2020-04-10 14:28:29  resolver-02              /tmp/tmp.vOFFxxly9O/sdb.img
a88cc1e7  2020-04-10 14:36:22  resolver-02              /tmp/tmp.FoY1j5JPIZ/config.xml
7c44e6ee  2020-04-10 14:36:24  resolver-02              /tmp/tmp.FoY1j5JPIZ/sdb.img
65456111  2020-04-10 14:37:48  resolver-02              /tmp/tmp.vjtI9JE3Iz/config.xml
eaced756  2020-04-10 14:37:49  resolver-02              /tmp/tmp.vjtI9JE3Iz/sdb.img
8eccec2c  2020-04-10 16:04:30  resolver-02              /tmp/tmp.YtLYRd0rNI/config.xml
34c897e1  2020-04-10 16:04:31  resolver-02              /tmp/tmp.YtLYRd0rNI/sdb.img
99b67b97  2020-04-10 16:07:53  resolver-02              /tmp/tmp.aWaEDqAaTq/config.xml
cad2c9d8  2020-04-10 16:07:54  resolver-02              /tmp/tmp.aWaEDqAaTq/sdb.img
--------------------------------------------------------------------------------------

Isso quebra restic forget porque não reconhece que é o mesmo arquivo e mantém um instantâneo para cada instância. Eu preferiria se houvesse uma maneira de remover um prefixo conhecido ou apenas armazenar um caminho relativo, sem absoluto.
Já estou ligando para o restic com um caminho relativ e ching na pasta temporária. Infelizmente não ajuda e eu prefiro não ter que usar bindmounts para isso.

Isso quebra restic forget porque não reconhece que é o mesmo arquivo e mantém um instantâneo para cada instância.

Também encontramos isso, mas a solução é bastante simples: marque cada backup com base no (s) arquivo (s) sendo copiado (s).

Por exemplo, você pode usar as tags config.xml e sdb.img aqui. Em seguida, adicione --group-by host,tags ao executar restic forget .

O que torna esse recurso tão difícil de implementar? Não é apenas a mesma filtragem de string básica em metadados de instantâneo? O valor que isso traria é enorme. Sim, você pode contornar a marcação, mas há um campo de caminho e pode ser utilizável ...

O que torna esse recurso tão difícil de implementar?

Falando como um desenvolvedor (não de restic, mas de outros projetos de código aberto): muitas vezes não é a complexidade de um recurso que impede sua implementação, mas sim coisas mundanas como falta de tempo, motivação ou simplesmente "vida real" ...

Claro, meu objetivo não era ser crítico, procurando genuinamente mapear a complexidade para contribuidores em potencial

Olá a todos, comecei a trabalhar na implementação dessa função "raiz personalizada". A implementação em si foi aparentemente simples, embora eu tenha que aprender golang tendo anteriormente conhecido apenas C # ... De qualquer forma, estou tentando avaliar que tipo de suporte esse problema ainda tem, visto que isso vem de 2018, 2 anos atrás . Vou me comprometer com https://github.com/TheRealVincentVanGogh/restic/tree/2092-feature-custom-path-prefix em breve, caso alguém queira me ajudar com golang 😅. Espero que em breve estarei colocando uma solicitação de pull aqui.

@TheRealVincentVanGogh Não vou aprender Go, mas ainda estou ansioso por esse recurso e tenho uma tonelada de backups que ainda quero portar para restabelecer, mas por causa desse problema. Abra um PR assim que tiver algo que pareça estar funcionando e poste o link aqui, vou fazer alguns testes pesados

@TheRealVincentVanGogh Como sua implementação planejada se relaciona com o PR # 2010?

@TheRealVincentVanGogh Como sua implementação planejada se relaciona com o PR # 2010?

@MichaelEischer Oh @cdhowie pudesse vincular PR # 2010 a este problema para ajudar a evitar confusões futuras? Obrigado!

@themightychris Aqui está um link para esse PR . Parece que o dev desistiu em 2018 também ... curioso.

Editar:

Parece haver alguma ambigüidade entre a remoção de um prefixo de caminho do arquivo de instantâneo VS. removendo um prefixo de caminho de cada estrutura de arquivo + arquivo de instantâneo. Parece que PR # 2010 aborda apenas o primeiro . Já que o OP estava procurando "retirar este caminho principal dos caminhos de todos os arquivos de backup" (também conhecido como correção de caminho no nível da estrutura do arquivo) , tenho que retomar o que disse sobre vincular o PR # 2010 a esse problema . Desculpe pela menção cdhowie!

Mesmo assim! @MichaelEischer Minhas intenções sempre foram obter uma implementação de divisão de estrutura de arquivo + prefixo de caminho de nível de instantâneo no Restic (cara, esse é um longo recurso / frase). Portanto, provavelmente começarei a trabalhar nisso a partir do código existente do PR # 2010, o que deve acelerar a implementação.

PS: Estou muito ocupado hoje em dia, então o trabalho pode ficar lento por um tempo; claro, vou postar um PR quando achar que tenho algo que vale a pena compartilhar com todos vocês! Fique seguro, todos! 😄