Sou responsável por um pequeno conjunto de laptops e queria obter algum tipo de backup remoto remoto (através da WAN); os backups iriam para uma unidade RAID. Como não temos realmente um cofre seguro para armazenar todas as nossas unidades (se alguém quisesse, poderia quebrar as janelas e levar nossas unidades), eu estava pensando em usar criptografia, talvez algo como duplicidade ( http: //duplicity.nongnu .org / ). Eu discuti isso com alguns dos desenvolvedores, mas eles parecem convencidos de que a criptografia é uma má idéia, porque um único bit ruim pode arruinar todo o bloco. No entanto, eu realmente não ouvi nenhuma história de horror onde isso aconteceu. Qual a sua opinião? Os benefícios superam os riscos com criptografia?
backup
encryption
encryptbackup
fonte
fonte
Respostas:
Eu faço isso e funciona para mim (como em, os backups correm bem e eu fiz várias restaurações). Eu uso bacula, que suporta. Para o meu dinheiro, os indicadores para acertar incluem:
1) A chave de descriptografia é mantida (sem criptografia) em um CD-R, não na minha cabeça. Existem várias cópias do CD-R, e nenhuma delas está comigo. Eu só preciso fazer restaurações uma vez a cada poucos meses e, francamente, provavelmente esquecerei uma senha que usei com pouca frequência. Isso também significa que minha segurança não é limitada pelo comprimento de uma senha memorável.
2) O software de backup já precisa suportar isso; não comece a hackear isso em sua ferramenta favorita, porque você pode errar e não saberá até que seja vital que funcione (por exemplo, restaurar o tempo).
3) Você tem razão sobre os flips de bits, mas eles podem arruinar qualquer backup. Eu limpo minhas cabeças de fita toda vez que a unidade solicita, giro as fitas a cada poucos anos e, acima de tudo, mantenho muitos incrementos. Se um pouco de estrondo realmente estragou o incremental de ontem, sempre posso voltar ao dia anterior, o que salvará a maior parte do meu bumbum.
4) Documente o procedimento de restauração . A criptografia sempre complica as coisas, mais se for bem-sucedida, e você não precisa redescobrir a roda quando estiver sob pressão para recuperar o banco de dados de contas. Escrevi um README curto com muitos detalhes muito específicos da minha configuração (um guia passo a passo real, todos os nomes de caminho explicitamente listados, esse tipo de coisa) e é gravado nos mesmos CDs que as chaves de descriptografia.
5) Acima de tudo, teste bastante . Você deve testar suas restaurações regularmente de qualquer maneira, mas depois de fazer algo inteligente como esse, torna-se absolutamente crítico que você tenha certeza de que as coisas estão funcionando como deveriam.
Os profissionais decorrentes dessa prática incluem não ter que se preocupar quando o armazenamento externo perde uma ou duas fitas, como - sendo apenas humano -, de vez em quando; destruir com segurança fitas antigas é fácil (jogar no lixo); e ter todos os meus sistemas de arquivos criptografados em disco não é mais prejudicado por ter uma pilha de fitas de backup não criptografadas no cofre ao lado.
fonte
Essa não é uma boa razão para não usar criptografia. O mesmo vale para a maioria dos backups compactados. A melhor maneira de resolver o problema seria usar um sistema de arquivos tolerante a falhas (os formatos de arquivo tolerantes a falhas são muito finos - principalmente porque eles não lidam com tantos cenários de falha quanto os sistemas de arquivos tolerantes a falhas).
Como em qualquer backup, você precisa garantir o acesso aos recursos necessários para restaurar os dados e verificar / executar periodicamente restaurações de teste.
No entanto, é muito mais provável que você perca um laptop do que um servidor de backup - por isso, se seus dados forem valiosos, sua primeira porta de escala deve estar descobrindo como proteger os dados no laptop. Provavelmente, isso terá muito impacto na sua escolha de como proteger o backup.
fonte
Eles têm seus benefícios e desvantagens, como qualquer outro. O problema de inversões de bits arruinando tudo o que 1 pode ser contornado, verificando adequadamente os backups e tendo mais de uma cópia (o que é sempre uma boa ideia de qualquer maneira - um local para restauração rápida e outro externo para fins de recuperação de desastres) )
No que diz respeito aos benefícios da criptografia, tudo se resume a quão ruim seria se os backups fossem roubados. Hoje em dia, a maioria das empresas possui dados críticos sensíveis suficientes, pelo menos, vale a pena fazer um projeto piloto (para aprender sobre as questões práticas de gerenciar a coisa) e fazer uma análise de ROI sobre a coisa toda.
fonte
Eu uso o rsync over ssh para fazer backup de 100 Gb de dados do servidor da Web remoto todas as noites - leva apenas alguns minutos para transferir diferenças e manter um espelho local em sincronia. No entanto, isso depende do destino não ser criptografado.
Depois que os dados são recebidos, eles podem ser arquivados usando tar, compactados com gzip (opcionalmente testados com gzip -t) e, opcionalmente, criptografados e renomeados com a data e armazenados em um sistema de ataque. (Achei mais fácil armazenar tudo do que mexer com incrementais).
Se a unidade de ataque usar um sistema de arquivos criptografados, será desnecessário criptografar ainda mais os backups. Se as unidades forem roubadas, elas deverão permanecer ilegíveis, mas se levarem todo o sistema e a chave estiver disponível em qualquer lugar, será um ponto discutível.
Você pode criptografar os arquivos individualmente, mas a segurança deles é tão segura quanto o local da chave.
Você pode servir a chave sobre https a partir de um servidor da Web remoto como uma função do endereço IP de origem. Dessa forma, se o sistema e os backups forem roubados, você ainda poderá ter algum controle sobre a chave e poderá desativá-la a tempo.
Sempre mantenha várias cópias, local e remotamente.
fonte