Restic: Não é possível encontrar documentos para a sintaxe de arquivo de exclusão

Oi vc viu

Os padrões usam filepath.Glob internamente, consulte filepath.Match para obter a sintaxe. Além disso, ** exclui subdiretórios arbitrários. As variáveis ​​de ambiente em arquivos de exclusão são expandidas com os.ExpandEnv.

em https://github.com/restic/restic/blob/master/doc/manual.rst?

Acho que isso deve responder às suas perguntas.

Acessei a documentação em https://restic.readthedocs.io/en/latest/manual.html e pesquisei exclude, onde infelizmente não inclui nenhum exemplo comum (ou uma referência a outra documentação em manual.rst ): /

Eu li o documento do golang e acho que o usuário final (eu!) Não vai saber o que restic está comparando um exclude a internamente - é o caminho completo (por exemplo, / home / me / blah) ou um caminho do raiz do repositório (/ blah ou blah), ou relativo ao cwd (eu / blah quando estou em / home)?

Obrigado por levantar esta questão, acho que você tem um ponto válido. O manual deve explicar os filtros de exclusão sem fazer referência a godoc.org, e mais exemplos são necessários.

Para responder já a algumas de suas perguntas:

• Todos os padrões são testados em relação ao caminho completo de um arquivo / diretório a ser salvo
• Caminhos / padrões relativos corresponderão a qualquer lugar abaixo do caminho a ser salvo
• No momento não há como distinguir entre um arquivo e um diretório, então --exclude foo excluirá todos os arquivos e diretórios com o nome foo . O mesmo vale para --exclude foo/ .

Do seu arquivo de exclusões:

• ._* irá corresponder a todos os arquivos e diretórios cujo nome começa com um ponto e um sublinhado
• desktop.ini corresponderá a todos os arquivos chamados desktop.ini exatamente. Portanto, desktop.ini.bak não é excluído e salvo no instantâneo.
• .Trash-* exclui arquivos / diretórios chamados .Trash- , .Trash-foobar , etc.
• .tmp$ exclui todos os arquivos / diretórios literalmente chamados .tmp$ , que é um ponto, seguido por tmp , seguido por um cifrão. Sem expansão regexp.
• ~$ exclui todos os arquivos / diretórios literalmente denominados til dollar. Para excluir todos os arquivos / diretórios que terminam em um til, use *~ .
• ~/.cache exclui o diretório .cache em todos os diretórios chamados til. Para excluir o diretório de cache apenas em seu diretório inicial, use $HOME/.cache (o til não é expandido, as variáveis ​​de ambiente são, mas apenas em um arquivo lido via --exclude-file , na linha de comando o shell se expande Ambas).
• /full/path/to/directory/.syncthing/index* exclui todas as coisas com nomes começando com index abaixo de /full/path/to/directory/.syncthing .

Obrigado @ fd0

Assim, com "diretório atual", você não quer dizer o diretório em que eu estava quando iniciei o backup, mas o diretório que restic está examinando os arquivos (exceto as exclusões que começam com uma barra). Entendi.

O comportamento para arquivos e diretórios é ligeiramente inesperado, eu esperava que --exclude foo / fizesse backup do diretório, mas não do conteúdo, enquanto --exclude foo para fazer backup também não. Não sei por que, de rsync, eu acho.

Meus exemplos perderam um importante: espaços! Acho que preciso escapar desses e dos metacaracteres de shell com uma barra invertida.

Acabei copiando muitos destes: https://gist.github.com/jult/e2eaedad6b9e29d95977fea0ddffae7d

Os comentários são permitidos no arquivo de exclusões? Edit: https://github.com/restic/restic/pull/916/commits/c796d84fca48feea91ca3e85fbf38e16f764a468 parece que um hash é o caractere de comentário.

Ah, infelizmente isso ainda não está totalmente correto. Descreverei como o Restic avalia os padrões de exclusão. Vamos supor que o restic seja executado por um usuário em seu diretório inicial ( /home/user ) assim:

$ restic backup --exclude='*.bak' --exclude='/home/user/secret' --exclude='extra' ~

Em seguida, o restic verá os seguintes argumentos de linha de comando (após a expansão pelo shell):

["restic", "backup", "--exclude='*.bak'", "--exclude='/home/user/secret'", "--exclude='extra'", "/home/user"]

Em seguida, ele começa a percorrer /home/user . A lista a seguir descreve o que acontece quando o arquivo / diretório nomeado é visto. O restic sempre testa o caminho completo em relação aos padrões:

• arquivo /home/user/foo.bak : O padrão *.bak corresponde e o arquivo não é salvo. O padrão não é absoluto, portanto, corresponde a todos os arquivos que terminam em .bak .
• dir /home/user/secret : O padrão absoluto /home/user/secret corresponde, então o dir não é salvo e não é percorrido
• dir /home/user/foo/home/user/secret : Nenhum padrão corresponde, então o dir é salvo.
• dir /home/user/work/extra : O padrão extra corresponde, o dir não é salvo.

Espero que isso esteja um pouco mais claro agora, acrescentarei uma seção ao manual descrevendo o processo. O ponto principal é que os padrões são avaliados em relação ao caminho completo dos arquivos durante o backup. Portanto, se você deseja corresponder a um único diretório, use o caminho completo, caso contrário, ele pode corresponder várias vezes em algum lugar.

Quaisquer outras questões? :)

Tenho outras perguntas e agradeço muito o tempo que você dedicou a respondê-las. É realmente uma questão sobre a ancoragem de padrões de automagia. Acho que posso adivinhar a resposta (contamos com o caminho absoluto sendo bastante único e nos dando o comportamento que desejamos), mas é melhor perguntar e ter certeza.

O padrão absoluto /home/user/secret corresponderia a /home/user/secret2 ? (E se você não quiser?)
O padrão absoluto /home/user/secret corresponderia a /home/user/somemount/home/user/secret ?

Em ambos os casos: Não, o padrão não corresponde.

Por que é que? Edit: Estou satisfeito que não, mas não vejo por que isso acontece :)

O código correspondente é modelado a partir do que um shell faria: Se você se perguntasse, se o arquivo /home/user/secret2 existe, o que ls /home/user/secret imprimiria (desde que o arquivo secret não existe)?

Em termos mais formais: Se o padrão começar com / ele é absoluto e o padrão deve corresponder ao início da string em teste, então o padrão /home/user/secret não corresponde a /home/user/somemount[...] : O padrão não é um prefixo da string.

Você pode imaginar por si mesmo que o padrão e o caminho do arquivo são divididos em seus respectivos componentes:

• /home/user/secret é dividido em [ROOT, "home", "user", "secret"] e o arquivo /home/user/somemount/home/user/secret é dividido em [ROOT, "home", "user", "somemount", "home", "user", "secret"] . A string ROOT é usada neste exemplo para marcar o diretório raiz. Você pode ver que o padrão não está contido no nome do arquivo.
  
  
  
  • Vejamos o arquivo /home/user/secret2 , que está dividido em [ROOT, "home", "user", "secret2"] . Novamente, você pode ver que o padrão não está contido no nome do arquivo.
  
  
• Para o arquivo /home/user/secret/secret.txt , que é dividido em [ROOT, "home", "user", "secret", "secret.txt"] você pode ver que o padrão está realmente contido no nome do arquivo, logo no início: [ROOT, "home", "user", "secret", ...] , portanto, o padrão corresponde e o arquivo é excluído.
• Digamos que temos um padrão de exclusão relativo de secret/secret.txt , que é dividido em ["secret", "secret.txt"] . Você pode ver que esse padrão pode ser encontrado na lista do arquivo /home/user/secret/secret.txt , começando no deslocamento 3: [ROOT, "home", "user", "secret", "secret.txt"] , portanto, o padrão corresponde.

Quando você tem curingas ( * , ? e assim por diante) em um componente de caminho, eles também são testados. Portanto, para seu primeiro exemplo, um padrão de /home/user/secret* corresponderia ao caminho /home/user/secret2 .

Todos esses exemplos devem ser documentados no manual, eu acho.

Peguei vocês. Obrigado.

As exclusões negativas são possíveis ala .gitignore?
digamos que eu queira excluir todo o conteúdo dos diretórios denominados .meteor, exceto o dir aninhado .meteor / local / db, posso fazer isso?

/ etc / restic / excludes:
.meteor/ !.meteor/local/db
restic backup exclude-file=/etc/restic/excludes

Não, isso ainda não foi implementado.

A documentação de exemplos de inclusão / exclusão é rastreada em # 396, estou encerrando este problema aqui.

@ fd0 estou tentando excluir caminhos como jobs / / jobs / / builds / ** / archive para excluir o diretório de todos os diretórios que funcionaria. E eu tenho vários caminhos como este que devo excluir, se possível, você pode me sugerir a melhor maneira de lidar com esse tipo, pois não consigo encontrar nenhum exemplo para esse tipo na documentação