Usando o Subversion para backup de uso geral

https://stackoverflow.com/questions/61888

svn
backup

09-06-2019
|

Pergunta

É possível usar Subversão Apache (SVN) como ferramenta de backup de uso geral?(Como uma espécie de sincronizar novamente alternativa.)

Solução

Achei este artigo uma descrição muito legal de como usar o svn para fazer backup do seu diretório pessoal e muito mais:

Eu uso o Subversion para fazer backup de minhas caixas Linux.Com um pouco de criatividade, cobre facilmente:

Instantâneos diários e backup externo.

Fácil adição e remoção de arquivos e pastas.

Rastreamento detalhado de versões de arquivos.

Ele também permite alguns recursos de bônus:

E-mails de log regulares para acompanhar a atividade do sistema de arquivos através dos ganchos de eventos do Subversion.

Os usuários podem solicitar o check-out de suas pastas pessoais de qualquer revisão do repositório.

Servidores novos ou substitutos podem ser configurados com alguns comandos svn checkout.

Fonte: http://www.mythago.net/svn_for_backup.html

Também encontrado Este artigo que mostra um exemplo de controle de versão do seu diretório inicial.Isso permite que você traga seu ambiente com você, transferindo seu diretório inicial para uma nova máquina.Eu costumava fazer algo semelhante e achei muito útil.

Outras dicas

Uma coisa a ter em mente ao usar o SVN como backup para arquivos binários é que o SVN dobrará o tamanho dos seus arquivos, porque mantém uma cópia local de cada arquivo (no arquivo .svn/text-base).

Além disso, eu também uso o SVN para backup.Basta adicionar todos os arquivos e confirmar via script.

Como um backup de "uso geral", eu diria que provavelmente não é a melhor idéia, principalmente pelos motivos apresentados por outros (muitas pastas em excesso e desperdício de espaço em disco).Se você quiser apenas manter backups, novamente eu diria que provavelmente existem opções melhores, dependendo de suas necessidades, por exemplo:você precisa manter todas as versões de cada arquivo ou alguns instantâneos de seus dados seriam suficientes?

Porém, no meu escritório, temos uma pequena equipe de 6 pessoas que trabalham com arquivos compartilhados (por exemplo:manuais de políticas e procedimentos, formulários de registro, etc).Na maior parte do tempo, os membros da equipe trabalharão remotamente (em casa ou durante viagens) e, muitas vezes, offline.Em vez de usar uma configuração central de pasta compartilhada, usamos SVN para dar a cada pessoa uma cópia de trabalho completa da pasta na qual ela pode trabalhar, consultar e sincronizar sempre que possível.Isso mata dois coelhos com uma cajadada só:todos podem acessar e editar os arquivos mesmo quando estão off-line, além de nos proporcionar uma excelente redundância em nossos backups.Se meu laptop pega fogo, não há problemas porque posso simplesmente verificar outra cópia (obviamente em outro computador).Se o servidor pegar fogo, teremos os backups do repositório para restaurar.Se o servidor E todos os backups do repositório pegarem fogo, tudo o que você perdeu serão versões antigas de arquivos.A única maneira de você perder todos os dados atuais é se o servidor, seus backups de repositório e todos os computadores que possuem um checkout pegarem fogo misteriosamente.

Como algumas pessoas disseram, o SVN nunca removerá informações do repositório, o que significa que se você quiser manter backups por apenas 60 dias, então, bem, você não pode.Isso não é exatamente verdade.Através do uso de exportar, jogar fora e importar você poderia efetivamente eliminar versões mais antigas de arquivos.Não é bonito, mas é possível.

Uma coisa que me incomodaria muito são as pastas '.svn', que o svn coloca em todas as pastas que rastreia.

Eles parecem irritantes, quando você copia uma pasta, lembre-se de não copiá-la (ou sua sandbox pode ficar irritada) e é muito mais difícil navegar por um monte de pastas, já que geralmente há muitos acessos no arquivo . pastas de recursos svn.

Gosto da ideia de usar um controle de origem para controlar seu ambiente.Mas eu pessoalmente não escolheria o svn para este trabalho.Eu escolheria algo como git.Mas provavelmente sou só eu...

Eu uso SVN para fazer backup do meu computador e também para sincronizar meu laptop e desktop.Mas apresenta os problemas mencionados nas respostas anteriores, principalmente a duplicação do uso do disco.Também sinto que o excesso de arquivos e o processo SVN verificando constantemente se há alterações em meu HD tornam minha máquina mais lenta.

Gostaria de destacar, no entanto, que o SVN é ótimo para sincronizar diferentes máquinas, e você também ganha o bônus de poder fazer check-out de um arquivo em qualquer lugar se precisar - eu até faço isso no meu navegador através da interface web, às vezes.

Em resumo, tenho sentimentos confusos sobre o uso do SVN para backup de uso geral.Mas se você fizer isso, eu recomendo não para armazenar bibliotecas como filmes, fotos e músicas, porque elas tendem a ser grandes (sofrendo enormemente com o uso duplicado de espaço) e imutáveis - você não precisa de um sistema de versionamento para isso, porque nas raras ocasiões em que você altera um arquivo, você geralmente não precisa das versões antigas (e o SVN não é bom em criar/armazenar diferenças de arquivos binários, ele salva toda a nova versão do arquivo).Portanto, a menos que o SVN possa ser adaptado (uma intenção de projeto de longa data) para esses casos, sugiro usar um método alternativo para fazer backup desses tipos de arquivos.

Você também pode considerar cara - Sistema de backup de arquivos altamente eficiente baseado no formato git packfile. É baseado no git's na forma como armazena dados, o que é muito eficiente para armazenar arquivos e suas diferenças.

Usei o CVS como substituto do fantasma, então não vejo por que não.

É legal porque você pode marcar uma linha de base:você pode alterar o gerenciamento de máquinas.

Isso funciona melhor em unixes do que em Windows, obviamente.

O que me afastaria dessa ideia é que, para uso geral, qualquer dado binário seria copiado sempre que fosse alterado, enquanto o conteúdo de texto em que os sistemas SCM se baseiam pode ser facilmente atualizado na forma de diferenças.

Então você poderia fazer isso, mas esteja ciente de que você pode não querer usá-lo para gerenciar coisas como repositórios de fotos se fizer muitas edições.

O bom das soluções de backup de uso mais geral (por exemplo, Time Machine) é que elas podem acumular várias alterações binárias depois de um tempo para economizar espaço.Não tenho certeza de como isso seria fácil de fazer no SVN, no git ou no mercurial.

Usar SVN para backups pode funcionar.No entanto, com o tempo pode ser difícil excluir revisões antigas que não são necessárias.Digamos que você queira manter apenas 30 ou 60 dias de backups.O SVN não fornece uma maneira fácil de remover qualquer histórico anterior a X dias.Se você não tiver uma maneira de limpar o histórico antigo, eventualmente sua unidade de backup ficará sem espaço.

Aqui está uma citação do Livro SVN no svndumpfilter comando:

Como o Subversão armazena tudo em um sistema de dados opacos, a tentativa de ajustes manuais é imprudente, se não muito difícil.E uma vez que os dados foram armazenados em seu repositório, a subversão geralmente não fornece uma maneira fácil de remover esses dados.[13]

[13] A propósito, isso é um recurso, não um bug.

eu encontrei uníssono ser uma opção melhor que o svn para uma alternativa ao rsync.

Esta afirmação de JoãoPSF está incorreta:

(e o SVN não é bom em criar/armazenar diferenças de arquivos binários, ele salva toda a nova versão do arquivo)

Veja esta citação de Como o Subversion lida com arquivos binários:

Observe que o fato de um arquivo ser binário ou não não afeta a quantidade de espaço de repositório usado para armazenar alterações nesse arquivo, nem afeta a quantidade de tráfego entre cliente e servidor.Para fins de armazenamento e transmissão, o Subversion usa um método de comparação que funciona igualmente bem em arquivos binários e de texto;isso não tem nenhuma relação com o método de comparação usado pelo comando svn diff.

Fazer backup do /etc com controle de código-fonte pode ser de grande ajuda quando você deseja reverter uma alteração que afetou seu sistema, experimentar alterações ou transportar alterações de um servidor para outro.

Mas a infinidade de diretórios .svn do Subversion pode atrapalhar isso, não apenas durante a pesquisa, mas em alguns casos, como pastas *.d, sistemas mal projetados podem interpretar as próprias pastas .svn como contendo dados de configuração.

Agora prefiro usar o Mercurial para fazer backup do/etc, pois ele coloca uma única pasta .hg em/etc.Para backup real e não apenas controle de versão, você precisa copiar a pasta .hg em outro lugar.

Para usar SVN como backup no Linux faça o seguinte:

Crie um repositório vazio.
Faça check-out do repositório vazio na árvore de pastas da qual deseja fazer backup.
Use o seguinte trecho de código (svnauto).Você deve substituir "myuser" e "mypassword" por credenciais válidas para o seu repositório:

    #!/bin/sh
    svn status --depth=infinity --username=myuser --password=mypassword > /tmp/svnauto_tmp.list
    cat /tmp/svnauto_tmp.list | grep '^?' | sed -e 's/^?       /svn add --depth=infinity --force --username=myuser --password=mypassword "/g' -e 's/$/@"/g' | sh
    cat /tmp/svnauto_tmp.list | grep '^!' | sed -e 's/^!       /svn delete --username=myuser --password=mypassword "/g' -e 's/$/@"/g' | sh
    rm -f /tmp/svnauto_tmp.list
    svn update . --username=myuser --password=mypassword
    svn commit --username=myuser --password=mypassword --message "Automatic backup"

O script acima irá adicionar/remover e atualizar quaisquer arquivos e subdiretórios dentro do diretório atual.Para usá-lo simplesmente cd para a pasta da qual deseja fazer backup (que deve ser uma cópia de trabalho, é claro) e execute svnauto.Observe que você precisa ter grep e sed instalados em seu sistema, e isso cria um arquivo temporário em/tmp.Ele pode ser usado a partir de um cron job para commit noturno, usando o seguinte script cron:

#!/bin/sh
export LANG=en_US.UTF-8 && cd /my/directory && echo Starting backup $(date) > /root/backup_log.txt && /root/svnauto >> /root/backup_log.txt 2>&1 && echo Finished backup. >> /root/backup_log.txt && cat /root/backup_log.txt

Este script cron assume que /my/directory é a pasta da qual você deseja fazer backup (substitua conforme necessário).Também pressupõe que você coloque o svnauto roteiro em /root.Ele cria um log e o exibe no final.Mais um detalhe:o primeiro export é necessário para que o svn encontre o idioma adequado.Talvez seja necessário ajustar esta linha ao seu idioma local para que funcione.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow