Por que não converter seu repo para usar o formato FSFS em vez do BDB ?
Dessa forma, cada revisão será armazenada como um arquivo separado, portanto, os backups incrementais apenas enviarão as revisões que foram confirmadas desde o último backup.
Eu estou olhando para usar o S3 como um repositório de backup externo para o meu banco de dados Subversion. Quando eu despejo meu banco de dados SVN, é cerca de 10 gigabytes. Eu gostaria de evitar a cobrança de enviar esses dados repetidamente.
A anatomia desse arquivo grande, de tal forma que novas mudanças no Subversion modificam a cauda do arquivo, com tudo o mais permanecendo o mesmo. Como o Amazon S3 não permite que você "remova" arquivos com alterações, eu terei que carregar 10 gigs toda vez que eu instanciá-lo depois de fazer um simples envio para o Subversion.
Aqui estão as opções que eu vejo:
Opção 1
Eu estou olhando para a duplicidade que tem --volsize , que divide os dados em uma quantidade de megas. É possível dividir os dumps do Subversion usando isso para que mais backups incrementais sejam medidos em megabytes?
Opção 2 Posso apenas fazer backup do repositório quente do subversion? Isto parece ser uma má ideia se estiver no meio de escrever um envio. No entanto, tenho a opção de colocar o repo offline entre as 24:00 e as 04:00. Cada revisão no meu banco de dados de Berkeley usa um arquivo como seu registro.
Por que não converter seu repo para usar o formato FSFS em vez do BDB ?
Dessa forma, cada revisão será armazenada como um arquivo separado, portanto, os backups incrementais apenas enviarão as revisões que foram confirmadas desde o último backup.
Você pode colocar uma pequena instância do Amazon EC2 e um backup em um volume do EBS (Elastic Block Store) por meio do rsync ou de qualquer outra ferramenta que preferir. Quando o backup estiver concluído, faça um snapshot, que será mantido no S3.
É uma solução um pouco mais complexa em alguns aspectos, mas compensa algumas das limitações / complexidades com o S3.
Eu sei que isso não é realmente uma resposta, mas por que não usar um provedor de SVN e não se preocupar com essas coisas?
Outra solução é usar o git, onde cada usuário tem uma cópia completa de todos os deltas para que você possa se recuperar de uma falha do servidor (já que todos são iguais).
Como tive que fazer isso recentemente, gostaria de acrescentar que o gerenciador de backup fez o truque. Pode bzip o despejo e rodar em s3. Eu usei este como referência.