Restic: Backups não criptografados

Já ouvi essa solicitação de recurso algumas vezes e tinha em mente que havia um problema com ela. Como não consigo encontrar, essa solicitação de recurso é rastreada aqui. A versão resumida é: podemos, em algum momento, adicionar uma opção para desativar a criptografia, mas isso não está no roteiro no momento.

A versão longa é:

• A criptografia não é mais cara, pelo menos não se você tiver AES-NI (criptografia acelerada por hardware), o que é bastante comum hoje em dia (pelo menos em laptops e servidores)
• O restic não se preocupa apenas com a criptografia, mas também com a autenticidade e a assinatura dos dados. Precisamos encontrar uma maneira de implementar isso sem criptografia, portanto, precisaremos manter uma chave / senha de qualquer maneira.
• Uma vez que temos um caminho de código que permite backups não criptografados, há uma chance de que os invasores encontrem uma maneira de enganar um cliente para salvar os dados sem criptografia em um repositório (originalmente) criptografado. Isso já aconteceu com outros programas de backup antes, então precisamos ter muito cuidado, o que leva tempo e recursos que não temos no momento.

Posso acrescentar mais pontos quando os encontrar.

Um motivo alternativo para querer backups não criptografados (localmente) é que um repositório central possa ser compartilhado por vários usuários - ou seja, no meu servidor doméstico, gostaria de enviar o backup via HTTPS, mas permitir que todos sejam desduplicados em um repositório comum, mesmo que sejam apresentados como logicamente separados para usuários individuais.

há uma chance de que os invasores encontrem uma maneira de enganar um cliente para que ele salve os dados sem criptografia em um repositório (originalmente) criptografado.

Hm, pensei que a ideia era que um repositório fosse criptografado ou não, então não seria possível salvar dados não criptografados em um repositório que está criptografado ... E se um repositório criptografado for de alguma forma substituído por um não criptografado com o mesmo nome e local, o usuário deve notar que nenhuma senha foi solicitada. Talvez um aviso em texto piscando em vermelho em negrito possa ser impresso, informando que o repositório não está criptografado :).

@wrouesnel você já pode fazer isso, distinguindo pelo nome do host! (Eu estava me perguntando o mesmo outro dia) :)

@alexeymuranov como você determina se a senha inserida pelo usuário é a senha criptografada para um diretório criptografado ou a senha MAC para verificar a autenticidade de um diretório não criptografado? mais --switches ? Torna-se muito confuso muito rápido.

Eu gostaria de ter essa opção para fazer backups locais. Por exemplo, todos os dias eu executo um backup do meu diretório ~ / Music em meu servidor, mas não preciso criptografar isso. O backup não é para proteger contra falha ou perda de hardware (tenho outros backups para isso), mas simplesmente para proteger contra acidentes e bitrot. E o servidor tem pouca energia, então a sobrecarga de criptografia é um problema.

@alphapapa para isso há rsync .
EDITAR: E permissões / atributos de arquivos. BTW, qual é a diferença entre "falha de hardware" e "bitrot"?

@cfcs , rsync não desduplica.

para isso existe o rsync.

@cfcs Como todos sabemos, um espelho não é um backup. ;) Usando o Obnam, mantenho uma série de backups, semelhantes ao restic: keep = 7d,8w,12m,3y Desde que quase perdi minha chave GPG (porque ela foi misteriosamente truncada para 0 bytes sem eu perceber, e o arquivo truncado foi feito o backup repetidamente), e tive que desenterrá-lo de um backup de anos atrás em um CD-R, reconheço a importância de manter os dados de backup antigos por perto.

BTW, qual é a diferença entre "falha de hardware" e "bitrot"?

O Bitrot normalmente não é detectado até que você precise dos dados estragados e não torna todo o dispositivo ilegível. A falha de hardware é, por exemplo, o disco falhou completamente, o sistema falhou ao inicializar, etc.

E, como Alexey aponta, o rsync não desduplica, nem fornece remoção de dados de backup antigos, nem verificações de integridade de dados, etc. rsync é uma boa ferramenta e eu o uso regularmente, mas não para fazer backups .

A criptografia não é mais cara, pelo menos não se você tiver AES-NI (criptografia acelerada por hardware), o que é bastante comum hoje em dia (pelo menos em laptops e servidores)

A menos que seu software seja escrito em go. O crypro de Go é um software apenas para qualquer coisa, exceto intel - então, com um dispositivo arm, você fica preso ao "tempo estimado de backup - 14 dias" para o mesmo conjunto de arquivos que é concluído em menos de 30 minutos com a solução de backup oficial baseada em openssl no meu NAS .

Eu também gostaria de ver esse recurso. Estou usando SSH para transferência e estou armazenando meus backups em volumes criptografados LUKS / cryptsetup, portanto, a criptografia apenas adiciona o risco de perder a chave de criptografia. Além disso, a criptografia adiciona mais tendência a erros e adiciona carga desnecessária à CPU.

No entanto, a criptografia é muito útil quando estou fazendo backup para um destino não confiável.

As pessoas podem estar motivadas a proteger um arquivo de texto incluindo a senha junto com o backup ...

Eu também uso um destino de backup criptografado luks / dm-crypt. É um disco USB externo que eu montei em / Backup /
Você pode apenas criar um arquivo de senha naquele local (/ Backup / restic_password) e alimentá-lo para o restic usando --password-file. O repositório fica em / Backup / restic_repo /
É importante tornar o arquivo de senha imutável, ou você está ferrado se ele se perder por acidente: chattr + i / Backup / restic_password
Também utilizo apenas "restic" como senha, apenas para garantir.

O recurso de criptografia da Restic é muito útil se você fizer backup para destinos não confiáveis, como provedores de nuvem. Mas se você usar apenas drives externos que você armazena em casa, ou um NAS em seu porão, a criptografia forçada é meio louca. O usuário comum vai esquecer a senha de qualquer maneira.

Permitir backups não criptografados permitiria que ZFS ou BtrFS ou NTFS ou qualquer sistema de arquivos compactasse os backups.

(A criptografia pode ser feita via dmcrypt em uma camada inferior, se desejado)

Permitir backups não criptografados permitiria que ZFS ou BtrFS ou NTFS ou qualquer sistema de arquivos compactasse os backups.

Mesmo aqui, nenhuma compressão e criptografia obrigatória ocupam muito espaço no meu servidor de backup. Meu caso de uso (algumas imagens, muitos arquivos xml / txt / csv pequenos) lucraria muito com a falta de criptografia (então o ZFS poderia fazer seu trabalho) ou compactação (taxa de compactação de ~ 2.3 com zstd, 5).

Se você estiver usando ZFS, por que não usar apenas zfs send instantâneos?

Os instantâneos do ZFS não são suficientes para backup em muitos casos. Se você detectou uma corrupção em um arquivo, ou se deseja ter anos de savesets, os instantâneos do ZFS não ajudam muito. Por exemplo, digamos que você esteja usando o FreeNAS e queira manter um ano de backups semanais. O agendamento e gerenciamento de instantâneos embutidos no FreeNAS não são _realmente_ suficientes para fazer isso corretamente. Não é "empresa".

Se você tiver um sistema de agendamento mais elaborado, provavelmente funcionará muito melhor. Também existe o problema de zfs send exigir que exista um instantâneo antes de poder enviá-lo; você também precisa gerenciar uma programação de instantâneo e certificar-se de que seu instantâneo e envio programado estão sincronizados (manualmente) para que você acerte seu RTO / RPO.

E sim .. Estou falando de recursos corporativos no FreeNAS. Mas essa é a preocupação ...

A criptografia não é mais cara, pelo menos não se você tiver AES-NI

O requisito AES-NI exclui muitos servidores mais antigos (que em alguns casos são _especialmente importantes_ para fazer backup!).

Estou ajudando alguém a conseguir backups melhores rodando em uma coleção de servidores na África rural, em hardware doado com mais de 10 anos (alguns deles até mesmo de 32 bits!). Temo que a criptografia simplesmente adicione muita sobrecarga, então acho que por enquanto vou precisar procurar outro lugar.

+1 para nenhuma criptografia

isso seria útil

+1 para nenhuma criptografia

isso seria útil

Use o recurso de polegar para cima no problema original em vez de '+ 1' para evitar inundar as caixas de entrada dos observadores. Obrigada!

Qual é o status deste recurso?

Eu preciso fazer backup de arquivos (documentos compartilhados como traduções do manual do usuário) do servidor interno do samba ao qual todos os usuários da empresa têm acesso, eles não são realmente confidenciais dentro dos limites da empresa. A criptografia de backup, neste caso, é inútil, estou usando jailkit para segurança adicional para backups de qualquer maneira e uso o sistema de arquivos btrfs com compactação habilitada. Eu faço backup de coisas como despejos de disco VM de outras maneiras de qualquer maneira. A criptografia não é um problema no meu caso de uso, evitar a perda de dados é praticamente a única prioridade. Usar uma senha como 'restic' é uma espécie de solução alternativa boba.

Por favor, implemente isso.

@mrkafk Qual é o problema real para você em restic ter criptografia? Mesmo se você não precisar disso, você precisará de motivos muito específicos para que seja um problema, já que suas CPUs provavelmente têm suporte para criptografia de hardware.

Descrevi meu problema real: dado o contexto específico, não preciso disso, embora pelo menos elimine os ganhos de compressão no sistema de arquivos btrfs. Tenho toneladas de arquivos para fazer backup, é por isso que estou usando btrfs com compactação habilitada em primeiro lugar porque com RAID-1 para redundância de hw eu preciso de muito espaço em disco (se não fosse por isso, eu prefiro usar ext4). Além disso, criptografar com o que equivale a uma senha falsa e fazer criptografia desnecessariamente parece ... idiota.

Ok, das coisas que você escreveu, eu percebi um problema real , a saber, que a compactação BTRFS não é tão eficaz quanto poderia ser sem criptografia. Este é um bom ponto. Além disso, não vejo nada que o limite devido à criptografia do Restic.

É impossível perder a chave de criptografia se ela não estiver criptografada. Isso é especialmente relevante para backups.

Mebus

É impossível perder a chave de criptografia se ela não estiver criptografada. Isso é especialmente relevante para backups.

Isso foi discutido como se o mundo já estivesse acabando amanhã :) https://github.com/restic/restic/issues/1786