Restic: Rclone tornando a maioria dos back-ends redundantes

Isso nem faz sentido. Rclone é um utilitário de transferência, não um utilitário de backup. Não pode substituir os repositórios restic.

Ele provavelmente quer dizer apenas abandonar o código de back-ends do próprio restic, exceto o de rclone, para que a integração de rclone se torne aquela pela qual todos os back-ends passam.

@jtagcat Acho que você quer dizer "back-ends" em vez de "repositórios".

Eu concordo com esta proposta em espírito.
Na verdade, remover todos os outros back-ends pode ser muito perturbador, mas pelo menos as documentações podem destacar rclone como o back-end preferido e rotular outros back-ends remotos como "legado".

Na verdade, acho que podemos fazer melhor, marcando back-ends como legados.
Nos documentos, marque-os como legados, mas nas obras internas, traduza legado para rclone on the fly. Em alguns back-ends de rclone, você pode traduzir diretamente ( um exemplo do topo da minha cabeça é http ), outros você traduz para um arquivo de configuração temporário e usa --config /path/to/config com rclone.

Se você me perguntar como um usuário do restic, eu diria que ter que usar rclone para todos os back-ends seria horrível. Isso requer a configuração de configurações de rclone para seus back-ends e a manutenção de um binário rclone, o primeiro que remove a natureza ad-hoc e livre de configuração do restic, o que é realmente bom. A única coisa que não gosto em rclone é que tenho que configurá-lo antes de executá-lo, em vez de apenas ser capaz de fornecer dois URIs como origem e destino.

Uma sugestão melhor do IMO é se pudéssemos incorporar o rclone no restic, de forma que você possa continuar usando o restic da mesma forma que faz agora, mas com o suporte de backend que o rclone fornece. Se isso acontecesse, seria bom descartar o código de back-end atual presumindo que o código rclone correspondente fornece os mesmos recursos.

Como você incorporaria o rclone ao Restic? Para que esse problema fosse resolvido positivamente, isso teria que ser feito.
Você ficaria como 'rclone não encontrado, executando curl https://rclone.org/install.sh | sudo bash ' (curl e sudo podem não existir no sistema)? Porque você não pode simplesmente adicioná-lo como uma dependência nos gerenciadores de pacotes, se você não estiver instalando através de um gerenciador de pacotes.

Traduzindo backends atuais para configurações rclone temporários em tempo real é possível, quando se utiliza puramente rclone para o material, estou um pouco irritado por que me bem.

Como você incorporaria o rclone ao Restic?

Não investiguei o que é possível a esse respeito. É apenas algo em que pensei algumas vezes.

Pensando um pouco mais a respeito, a incorporação provavelmente terminaria como 'instalação como uma dependência', para permitir que o rclone seja atualizado sem que o restic precise ser atualizado.
Provavelmente, a melhor maneira seria adicionar rclone como uma dependência, onde possível, e ter 'rclone não encontrado, instalando' em todos os lugares (quando a dependência de rclone não for encontrada por algum motivo, como um backup).

Embora o instalador do rclone apresente alguns problemas. Torne-o compatível com posix.

• curl - Eu vi um ou dois sistemas em que não foi instalado fora da caixa.
• sudo - mesmo que acima
• descompactar / descompactar outra coisa, você provavelmente já experimentou isso, ao instalar o rclone em uma instalação mínima.

Estou pensando mais em tornar o rclone embutido como uma biblioteca ou qualquer outra coisa, para que possa ser integrado no restic. Não deve ser um problema lançar uma nova versão do restic quando há algo no rclone que é atualizado a ponto de justificar um novo lançamento.

Provavelmente, a melhor maneira seria adicionar rclone como uma dependência, onde possível, e ter 'rclone não encontrado, instalando' em todos os lugares (quando a dependência de rclone não for encontrada por algum motivo, como um backup).

Lamento dizer isso, mas tentar instalar o software (automaticamente) na máquina do usuário é (provavelmente) a pior ideia que já li nas discussões de questões do Restic.

Porque:

• O ambiente pode não permitir a instalação de um novo software.
• O usuário (ou o administrador do sistema) pode não querer que um novo software seja instalado.
• Acessar a Internet sem solicitação explícita pode ser indesejável.
• O instalador pode adivinhar um lugar errado para o novo software.
• A instalação de um novo software pode interferir nas funções normais do ambiente (por exemplo, fornecendo executáveis ​​fora de locais regulares onde os usuários / gerenciadores de pacotes / administradores / auditores / qualquer outra coisa esperem encontrá-los, criando assim confusão).
• A instalação pode falhar ou produzir resultados incorretos; de maneira óbvia ou sutil e difícil de descobrir.

Provavelmente, a melhor maneira seria adicionar rclone como uma dependência, onde possível, e ter 'rclone não encontrado, instalando' em todos os lugares (quando a dependência de rclone não for encontrada por algum motivo, como um backup).

Lamento dizer isso, mas tentar instalar o software (automaticamente) na máquina do usuário é (provavelmente) a pior ideia que já li nas discussões de questões do Restic.

Porque:

* The environment may not allow installation of new software.

* The user (or the system administrator) may not want new software to be installed.

* Accessing the Internet without explicit request may be undesirable.

* The installer may guess a wrong place for the new software.

* Installation of new software may interfere with the normal functions of the environment (for example, by providing executables outside of regular places where users/package managers/administrators/auditors/whatever else expect to find them, and thus creating confusion).

* The installation may fail or produce incorrect results; either in an obvious manner, or in a subtle and hard-to-discover way.

sim o que você sugere?

o que eu quis dizer foi assim:

restic rclone not found...
Install 'rclone' with command 'curl https://rclone.org/install.sh | sudo bash'  to provide rclone backends? [Y/n]

Eu não substituiria os back-ends existentes por rclone, a menos que o último fosse incorporado com sucesso como uma biblioteca e, portanto, sempre incluído na distribuição do restic.

Até que isso seja feito (ou em vez de fazer isso), eu faria rclone uma dependência opcional nos gerenciadores de pacotes que permitem isso (por exemplo, apt e portage). Se o rclone não estiver instalado, o restic pode mostrar uma mensagem referindo-se à página da Web do rclone, sugerindo (1) consultar a página para saber como instalar, (2) instalar o rclone usando o gerenciador de pacotes do sistema, (3) emitir o "curl + bash ", com um aviso de que" certifique-se de saber o que está fazendo ".

Eu não executaria o comando em nome do usuário, mesmo depois de perguntar sobre isso.

A natureza do RESTIC (especialmente no Linux) como um binário estático sem dependências foi ABSOLUTAMENTE INVALUÍVEL em cenários de restauração e recuperação bare-metal.

Atualmente, prefiro usar o "rest-server" (com interface haproxy para autenticação) para backups internos e dependo do suporte nativo do restic. Se eu fosse forçado a mexer com RESTIC e RCLONE durante uma restauração crítica de tempo, provavelmente encontraria outra solução.

A natureza do RESTIC (especialmente no Linux) como um binário estático sem dependências foi ABSOLUTAMENTE INVALUÍVEL em cenários de restauração e recuperação bare-metal.

Atualmente, prefiro usar o "rest-server" (com interface haproxy para autenticação) para backups internos e dependo do suporte nativo do restic. Se eu fosse _forçado_ a mexer com RESTIC _e_ RCLONE durante uma restauração crítica de tempo, provavelmente encontraria outra solução.

O back-end Rest não seria removido, pois é exclusivo da Restic. Eu também uso o rest-server, é muito conveniente apenas inserir as credenciais.

Acho que o problema está no estado de 'apenas, se rclone estiver incorporado'. Como ninguém realmente precisa disso (embora rclone embutido seja necessário). Eu acho que agora, é mais 'não adicione novos back-ends, o que já não é suportado por rclone', e uma solicitação de recurso para alguém (provavelmente em muitos, muitos meses, eu), que se preocupa em fazer isso, incorporar rclone .

Quanto ao básico, é necessário obter versões alternativas, que não usem o bzip (pelo que ouvi, a única razão para instalar o bzip é o restic). Quanto a isso, se ninguém mais fizer, eu provavelmente o farei, já que uma tarefa para mim é # 2705

A única coisa que não gosto em relação ao rclone é que _tenho_ que configurá-lo antes de executá-lo, em vez de apenas ser capaz de fornecer dois URIs como origem e destino.

@rawtaz
Você é capaz de fazer exatamente isso desde rclone não exigem que você configure qualquer coisa.
Você pode remover completamente qualquer _ ~ / .rclone.conf_ ou _ ~ / .config / rclone / rclone.conf_, eles são apenas consultados para os padrões ou opções de fallback.
Agora tente isto:

rclone copy ./file.txt :sftp:subdir --sftp-host=localhost --sftp-key-file=~/.ssh/id_rsa

É perfeitamente válido e descrito nos documentos: https://rclone.org/docs/#backend -path-to-dir

Você também pode passar todas as opções por meio do ambiente ou combiná-las com os argumentos CLI:

export RCLONE_SFTP_HOST=localhost
export RCLONE_SFTP_KEY_FILE=~/.ssh/id_rsa
rclone ls :sftp:

O uso de rclone como uma biblioteca é discutido em https://github.com/rclone/rclone/issues/633