GIT como uma ferramenta de backup


101

Em um servidor, instale o git

cd /
git init
git add .
git commit -a -m "Yes, this is server"

Em seguida, /.git/aponte para uma unidade de rede (SAN, NFS, Samba, qualquer que seja) ou outro disco. Use um trabalho cron a cada hora / dia etc. para atualizar as alterações. O diretório .git conteria uma cópia com versão de todos os arquivos do servidor (excluindo os inúteis / complicados, como / proc, / dev etc.)

Para um servidor de desenvolvimento não importante em que eu não quero o incômodo / custo de configurá-lo em um sistema de backup adequado, e onde os backups seriam apenas por conveniência (IE, não precisamos fazer backup desse servidor, mas isso salvaria algum tempo, se tudo der errado), isso poderia ser uma solução de backup válida ou simplesmente cairá em uma grande pilha de cocô?


3
não sparkleshare usando idéia semelhante?
B14D3

@ B14D3 Eu acho que o sparkleshare é mais uma espécie de tipo dropbox, mas vou dar uma olhada nele #
Smudge

2
você está certo, mas usando git para fazer algum tipo de coisa Buckup (copiar para vários PCs e controlando versões de arquivos);)
B14D3

O grande problema é que não há controle central - você precisa ter acesso direto (ssh) à máquina para executar qualquer forma de manutenção ou validação de backup. Sempre acho que instalar um aplicativo nas caixas a serem copiadas e administrá-los a partir de um local central é uma vitória muito maior.
hafichuk

@hafichuk Com ferramentas como Puppet / Chef, não é um problema tão grande, mas entendo o seu ponto.
quer

Respostas:


88

Você não é uma pessoa boba. Usar gitcomo um mecanismo de backup pode ser atraente e, apesar do que outras pessoas disseram, gitfunciona bem com arquivos binários. Leia esta página do Git Book para obter mais informações sobre este tópico. Basicamente, uma vez que gitnão está usando um mecanismo de armazenamento delta, ele realmente não importa o que seus arquivos parecer (mas a utilidade git diffé muito baixo para arquivos binários com uma configuração de estoque).

O maior problema com o uso gitde backup é que ele não preserva a maioria dos metadados do sistema de arquivos. Especificamente, gitnão registra:

  • grupos de arquivos
  • proprietários de arquivos
  • permissões de arquivo (exceto "é este executável")
  • atributos estendidos

Você pode resolver isso escrevendo ferramentas para registrar essas informações explicitamente em seu repositório, mas pode ser complicado fazer isso corretamente.

Uma pesquisa no Google por metadados de backup do git gera vários resultados que parecem valer a pena ler (incluindo algumas ferramentas que já tentam compensar os problemas que levantei aqui).

O etckeeper foi desenvolvido para fazer backup /etce resolver muitos desses problemas.


16
+1 por mencionar ACLs / permissões
Larry Silverman

23
O Git também não armazena diretórios vazios.
Flimm

e também é péssimo rastrear a movimentação / renomeação de arquivos ao longo do histórico.
Cregox # 10/13

1
Como o git não lida muito bem com arquivos binários, você também pode procurar no anexo do git , o que ajuda a fazer isso melhor. No entanto, isso muda a ideia do que é o git.
Wouter Verhelst

1
minha opinião é que você pode usar git para backup de dados, mas não servidores inteiros
EKanadily

21

Eu não o usei, mas você pode olhar para o bup, que é uma ferramenta de backup baseada no git.


Nunca vi bup antes, parece interessante
Smudge

1
Comecei a usar o bup recentemente, apenas alguns dias antes de meu disco rígido travar;) A restauração foi boa, por isso é recomendável!
André Paramés

1
@ AndréParamés Então, o que você está dizendo é apenas depois de instalado bup seu disco rígido caiu ... mmmmhh ... :) apenas brincando
hofnarwillie

12

Pode ser uma solução de backup válida, etckeeper é baseado nessa idéia. Mas fique de olho nas .gitpermissões do diretório, caso contrário, pressionar /etc/shadowpode ser legível no .gitdiretório.


11

Enquanto tecnicamente você poderia fazer isso, eu colocaria duas advertências contra ele:

1, você está usando um sistema de controle de versão de origem para dados binários. Portanto, você o está usando para algo para o qual não foi projetado.

2, preocupo-me com o seu processo de desenvolvimento, se você não tiver um processo (documentação ou automatizado) para construir uma nova máquina. E se você fosse atropelado comprando um ônibus, quem saberia o que fazer e o que era importante?

A recuperação de desastres é importante, porém é melhor automatizar (script) a configuração de uma nova caixa de desenvolvimento do que apenas fazer backup de tudo. Certifique-se de usar o git no seu script / documentação, mas não em todos os arquivos do computador.


4
Todas as caixas de desenvolvimento vêm de arquivos do KickStart e, na verdade, a caixa média dura cerca de 2 ou 3 meses antes de ser reconstruída. Mas as pessoas mudam as configurações e fazem as coisas, reconstruímos as caixas e as pessoas dizem "ei, eu sei que não coloquei no controle de origem, mas eu tinha alguma merda nessa caixa" e ri delas por serem estúpidas. Por toda parte, bons tempos. Dados binários seriam uma merda, é algo que eu totalmente esqueci enquanto estava no chuveiro.
Smudge

Aplaudo sua atitude para com aqueles que não seguem os princípios básicos. Pessoalmente, tenho uma situação semelhante a você, no entanto, tenho um repositório git que vincula todos os arquivos de configuração que podem ser importantes ao invés de capturar tudo. Além de um documento txt com as etapas de configuração.
Phil Hannent

1
Eu acho que o git funciona muito bem para arquivos binários, pois a maior parte do repositório do Google Android são repositórios git de executáveis ​​pré-construídos.
user377178

6

Eu uso o git como um backup para o meu sistema Windows e tem sido incrivelmente útil. Na parte inferior da postagem, mostro os scripts que utilizo para configurar em um sistema Windows. O uso do git como backup para qualquer sistema oferece duas grandes vantagens:

  1. Ao contrário das soluções comerciais, muitas vezes usam seu próprio formato proprietário, seu backup está em um formato de código aberto amplamente suportado e muito bem documentado. Isso fornece controle total dos seus dados. É muito fácil ver quais arquivos foram alterados e quando. Se você deseja truncar seu histórico, também pode fazer isso. Deseja eliminar algo da sua história? Sem problemas. Obter uma versão do seu arquivo de volta é tão simples quanto qualquer comando git.
  2. Quantos espelhos quiser, e todos podem ter tempos de backup personalizados. Você obterá o seu espelho local, que não é sobrecarregado pelo tráfego lento da Internet e, assim, fornece (1) a capacidade de fazer backups mais frequentes ao longo do dia e (2) um tempo de restauração rápido. (Os backups frequentes são uma grande vantagem, porque eu acho que a maior parte do tempo que perco um documento é por erro do usuário. Por exemplo, seu filho sobrescreve acidentalmente um documento em que ele está trabalhando nas últimas 5 horas.) Mas você receberá seu espelho remoto, que oferece a vantagem da proteção de dados em caso de desastre ou roubo local. E suponha que você queira que o seu espelho remoto faça backup em um momento personalizado para economizar sua largura de banda da Internet? Sem problemas.

Conclusão: um backup do git oferece uma quantidade incrível de poder no controle de como seus backups acontecem.

Eu configurei isso no meu sistema Windows. O primeiro passo é criar o repositório git local onde você confirmará todos os seus dados locais. Eu recomendo usar um segundo disco rígido local, mas usar o mesmo disco rígido funcionará (mas é esperado que você o empurre para algum lugar remoto, ou você ferrou se o disco rígido morrer).

Você primeiro precisará instalar o cygwin (com rsync) e também instalar o git para Windows: http://git-scm.com/download/win

Em seguida, crie seu repositório git local (execute apenas uma vez):

init-repo.bat:

@echo off
REM SCRIPT PURPOSE: CREATE YOUR LOCAL GIT-REPO (RUN ONLY ONCE)

REM Set where the git repository will be stored
SET GBKUP_LOCAL_MIRROR_HOME=E:\backup\mirror


REM Create the backup git repo. 
SET GIT_PARAMS=--git-dir=%GBKUP_LOCAL_MIRROR_HOME%\.git --work-tree=%GBKUP_LOCAL_MIRROR_HOME% 
mkdir %GBKUP_LOCAL_MIRROR_HOME%
git %GIT_PARAMS% init
git %GIT_PARAMS% config core.autocrlf false
git %GIT_PARAMS% config core.ignorecase false 
git %GIT_PARAMS% config core.fileMode false
git %GIT_PARAMS% config user.email backup@yourComputerName
git %GIT_PARAMS% config user.name backup

REM add a remote to the git repo.  Make sure you have set myRemoteServer in ~/.ssh/config   
REM The path on the remote server will vary.  Our remote server is a Windows machine running cygwin+ssh.  
REM For better security, you could install gitolite on the remote server, and forbid any non-fast-forward merges, and thus stop a malicious user from overwriting your backups.
git %GIT_PARAMS% remote add origin myRemoteServer:/cygdrive/c/backup/yourComputerName.git

REM treat all files as binary; so you don't have to worry about autocrlf changing your line endings
SET ATTRIBUTES_FILE=%GBKUP_LOCAL_MIRROR_HOME%\.git\info\attributes
echo.>> %ATTRIBUTES_FILE% 
echo *.gbkuptest text>> %ATTRIBUTES_FILE% 
echo * binary>> %ATTRIBUTES_FILE% 
REM compression is often a waste of time with binary files
echo * -delta>> %ATTRIBUTES_FILE% 
REM You may need to get rid of windows new lines. We use cygwin's tool
C:\cygwin64\bin\dos2unix %ATTRIBUTES_FILE%

Em seguida, temos nosso wrapper de script de backup, que será chamado regularmente pelo Windows Scheduler:

gbackup.vbs:

' A simple vbs wrapper to run your bat file in the background
Set oShell = CreateObject ("Wscript.Shell") 
Dim strArgs
strArgs = "cmd /c C:\opt\gbackup\gbackup.bat"
oShell.Run strArgs, 0, false

Em seguida, temos o próprio script de backup que o wrapper chama:

gbackup.bat:

    @echo off

REM Set where the git repository will be stored
SET GBKUP_LOCAL_MIRROR_HOME=E:\backup\mirror
REM the user which runs the scheduler
SET GBKUP_RUN_AS_USER=yourWindowsUserName
REM exclude file
SET GBKUP_EXCLUDE_FILE=/cygdrive/c/opt/gbackup/exclude-from.txt

SET GBKUP_TMP_GIT_DIR_NAME=git-renamed
for /f "delims=" %%i in ('C:\cygwin64\bin\cygpath %GBKUP_LOCAL_MIRROR_HOME%') do set GBKUP_LOCAL_MIRROR_CYGWIN=%%i

REM rename any .git directories as they were (see below command)
for /r %GBKUP_LOCAL_MIRROR_HOME% %%i in (%GBKUP_TMP_GIT_DIR_NAME%) do ren "%%i" ".git" 2> nul

SET RSYNC_CMD_BASE=C:\cygwin64\bin\rsync -ahv --progress --delete --exclude-from %GBKUP_EXCLUDE_FILE%

REM rsync all needed directories to local mirror
%RSYNC_CMD_BASE% /cygdrive/c/dev %GBKUP_LOCAL_MIRROR_CYGWIN%
%RSYNC_CMD_BASE% /cygdrive/c/Users/asmith %GBKUP_LOCAL_MIRROR_CYGWIN%
%RSYNC_CMD_BASE% /cygdrive/c/Users/bsmith %GBKUP_LOCAL_MIRROR_CYGWIN%

cacls %GBKUP_LOCAL_MIRROR_HOME% /t /e /p  %GBKUP_RUN_AS_USER%:f

REM rename any .git directories as git will ignore the entire directory, except the main one
for /r %GBKUP_LOCAL_MIRROR_HOME% %%i in (.git) do ren "%%i" "%GBKUP_TMP_GIT_DIR_NAME%" 2> nul
ren %GBKUP_LOCAL_MIRROR_HOME%\%GBKUP_TMP_GIT_DIR_NAME% .git

REM finally commit to git
SET GIT_PARAMS=--git-dir=%GBKUP_LOCAL_MIRROR_HOME%\.git --work-tree=%GBKUP_LOCAL_MIRROR_HOME% 
SET BKUP_LOG_FILE=%TMP%\git-backup.log
SET TO_LOG=1^>^> %BKUP_LOG_FILE% 2^>^&1
echo ===========================BACKUP START=========================== %TO_LOG%
For /f "tokens=2-4 delims=/ " %%a in ('date /t') do (set mydate=%%c-%%a-%%b)
For /f "tokens=1-2 delims=/:" %%a in ('time /t') do (set mytime=%%a%%b)
echo %mydate%_%mytime% %TO_LOG%
echo updating git index, committing, and then pushing to remote %TO_LOG%
REM Caution: The --ignore-errors directive tells git to continue even if it can't access a file.
git %GIT_PARAMS% add -Av --ignore-errors %TO_LOG%
git %GIT_PARAMS% commit -m "backup" %TO_LOG%
git %GIT_PARAMS% push -vv --progress origin master %TO_LOG%
echo ===========================BACKUP END=========================== %TO_LOG%

Temos o arquivo exclude-from.txt, onde colocamos todos os arquivos para ignorar:

exclude-from.txt:

target/
logs/
AppData/
Downloads/
trash/
temp/
.idea/
.m2/
.IntelliJIdea14/
OLD/
Searches/
Videos/
NTUSER.DAT*
ntuser.dat*

Você precisará ir a qualquer repositório remoto e executar um 'git init --bare' neles. Você pode testar o script executando o script de backup. Supondo que tudo funcione, vá para o Windows Scheduler e aponte um backup de hora em hora para o arquivo vbs. Depois disso, você terá um histórico do git do seu computador a cada hora. É extremamente conveniente - todos os usuários excluem acidentalmente uma seção de texto e perdem isso? Basta verificar o seu repositório git.


Apenas curioso - funcionará também para unidades de rede lentas ou fora do padrão, como as emuladas pelo NetDrive ou Expandrive? Acho que a maioria dos softwares de backup falha com essas unidades de rede. Além disso, as coisas ficam dolorosamente lentas e tendem a atingir o tempo limite, se eu quiser listar todos os arquivos no backup e extrair arquivos individuais. O git é capaz de resolver esses problemas?
precisa saber é o seguinte

@JustAMartin Eu nunca testei em unidades de rede, então não posso dizer. Depois de obter os arquivos em um repositório git, o git é muito eficiente.
user64141

4

Bem, não é uma má ideia, mas acho que há duas bandeiras vermelhas a serem levantadas:

  • Se o disco rígido falhar, você perderá tudo se não estiver enviando sua confirmação para outro servidor / unidade. (Caso você tenha um plano para isso, prefiro mencionar.)

... mas ainda assim, pode ser um bom backup de coisas relacionadas à corrupção. Ou, como você disse, se a pasta .git / estiver em outro lugar.

  • Esse backup sempre aumentará de tamanho. Não há poda ou rotação ou qualquer coisa por padrão.

... Portanto, você pode precisar informar ao seu cronjob para adicionar tags e garantir que a confirmação que não está marcada seja limpa.


Provavelmente montaríamos o diretório .git em um servidor remoto, embora o clássico rm -Rf /nos causasse alguns problemas. Nosso sistema de backup atual mantém as coisas por 2 anos ou 50 versões (o que ocorrer primeiro), portanto nosso backup aumenta constantemente de qualquer maneira. Mas eu gosto da idéia de adicionar tags, podemos ter tags "diárias", "semanais" etc. etc.
Smudge

+1 para requisitos de espaço sempre crescentes
hafichuk

@ sam git está sempre crescendo. Você não pode remover a história com mais de N anos. Suponho que o seu sistema atual funcione.
Rds 16/12

1
Com relação ao aumento de tamanho, faça 'git gc' regularmente ou antes de enviar para outro servidor (central). Sem isso, o repositório git pode crescer (muito) maior do que deveria. Certa vez, tive um repositório git de 346 MB que pode diminuir para 16 MB.
Hendy Irawan

3

Eu não tentei com um sistema completo, mas estou usando-o para meus backups do MySQL (com a opção --skip-extended-insert) e ele realmente funcionou bem para mim.

Você terá problemas com arquivos de dados binários (todo o conteúdo pode e será alterado) e pode ter problemas com a .gitpasta ficando muito grande. Eu recomendaria configurar um .gitignorearquivo e apenas fazer backup de arquivos de texto que você realmente sabe que precisa.


Também estou usando-o para backups do MySQL, com --extended-insert = false. Certifique-se de "git gc" regularmente ou logo após o commit.
Hendy Irawan


3

Uma vez desenvolvi uma solução de backup baseada no subversion. Embora tenha funcionado muito bem (e o git deva funcionar ainda melhor), acho que existem soluções melhores por aqui.

Considero o rsnapshot um dos melhores - se não o melhor. Com um bom uso do link físico, eu tenho um servidor de arquivos de 300 GB (com meio milhão de arquivos) com backup diário, semanal e mensal, desde um ano. O espaço total em disco usado é apenas uma cópia completa + a parte incremental de cada backup, mas, graças aos hardlinks, tenho uma estrutura de diretórios "ativa" completa em cada um dos backups. Em outras palavras, os arquivos são acessíveis diretamente, não apenas em daily.0 (o backup mais recente), mas também em daily.1 (ontem) ou semanalmente.2 (duas semanas atrás), e assim por diante.

Compartilhando novamente a pasta de backup com o Samba, meus usuários podem extrair o arquivo dos backups simplesmente apontando seu PC para o servidor de backup.

Outra opção muito boa é o rdiff-backup , mas como eu gosto de ter os arquivos sempre acessíveis, basta ir no Explorer para \\ servername, o rsnapshot foi uma solução melhor para mim.


A última versão do rdiff-backup é de 2009. Ele é extremamente bem projetado e não requer atualização, ou é simplesmente um projeto abandonado?
Mateusz Konieczny 16/04

Não sei se é mantido, mas está basicamente "pronto".
Shodanshok 17/04/19

Observando savannah.nongnu.org/bugs/… , parece que houve alguma atividade até 2015, mas muitos relatórios de erros são ignorados. Acho que vou classificá-lo como abandonado.
Mateusz Konieczny

2

Eu tive a mesma idéia de fazer backup com o git, basicamente porque ele permite backups com versão. Então vi o rdiff-backup , que fornece essa funcionalidade (e muito mais). Ele tem uma interface de usuário muito boa (veja as opções da CLI). Estou muito feliz com isso. O --remove-older-than 2Wé muito legal. Permite excluir apenas versões com mais de 2 semanas. rdiff-backuparmazena apenas diferenças de arquivos.


2

Eu sou extremamente novo no git, mas as ramificações não são locais por padrão e devem ser enviadas explicitamente para repositórios remotos? Foi uma surpresa desagradável e inesperada. Afinal, não quero que todo o meu repositório local seja copiado para o servidor? Lendo o livro git :

Suas ramificações locais não são sincronizadas automaticamente com os controles remotos para os quais você escreve - você deve enviar explicitamente as ramificações que deseja compartilhar. Dessa forma, você pode usar ramificações particulares para o trabalho que não deseja compartilhar e enviar apenas as ramificações de tópicos nas quais deseja colaborar.

Para mim, isso significava que essas ramificações locais, como outros arquivos não-git na minha máquina local, correm o risco de serem perdidas, a menos que o backup seja feito regularmente por alguns meios não-git. Eu faço isso de qualquer maneira, mas isso quebrou minhas suposições sobre o git 'fazer backup de tudo' no meu repositório. Eu adoraria esclarecimentos sobre isso!


1
Praticamente tudo sobre o git, com exceção dos controles remotos, é local. Isso é por design. Você pode enviar coisas para controles remotos e deve, principalmente se usado para backup, como neste cenário. Para ramificações, novamente, sim, você precisa enviá-las explicitamente, se desejar que elas sejam adicionadas a um controle remoto. Para o desenvolvimento, isso é ótimo porque geralmente você deseja testar algo, mas não há necessidade de preservar esse ramo de teste indefinidamente. Depois de obter o que você precisa dele, é provável que você o mescle com um ramo de desenvolvimento e exclua o ramo de teste.
LocalPCGuy

1

Eu achei essa uma boa metodologia para minhas caixas de desenvolvimento. Isso os muda de algo que precisa ser feito em backup apenas em um ponto de extremidade de implantação.

Todos os manifestos de configuração e instalação de pacotes são armazenados no Puppet, permitindo fácil reimplementação e atualizações de configuração. O diretório Puppet é feito com o git. O Kickstart é usado para fazer a implantação inicial.

Também mantenho um repositório YUM personalizado para quaisquer pacotes que estejam sendo desenvolvidos no momento. Isso tem o benefício adicional de que, independentemente dos pacotes com os quais estamos trabalhando, não serão deixados como binários autônomos no sistema local - se isso acontecer e os arquivos forem destruídos, tudo bem. Alguém não seguiu o procedimento adequado.



1

É uma abordagem usada, faz sentido.

O Keepconf usa rsync e git para este trabalho, é um invólucro sobre essas ferramentas para facilitar a tarefa.

Você só precisa de um servidor central com as teclas ssh configuradas para acessar os servidores de backup e algumas linhas no arquivo de configuração. Por exemplo, este é meu próprio arquivo para manter todos os / etc / e os pacotes debian instalados:

[hosts]
192.168.1.10
192.168.1.11
192.168.1.12

[files]
/etc/*
/var/lib/dpkg/status

Com isso, tenho o backup rsync e o git commit.


0

Minha opinião pessoal é que isso é basicamente tudo ao contrário. Você está enviando os arquivos para uma solução de backup, em vez de retirá-los.

Muito melhor seria centralizar a configuração do servidor em primeiro lugar e depois puxá-la para baixo, usando algo como fantoche.

Dito isto, pode funcionar, eu apenas não acho que seria tão bom.

Tente pesquisar no backuppc - é muito fácil de configurar e é francamente brilhante.


0

Funcionaria um pouco, mas duas ressalvas.

  1. As adições de arquivo não serão selecionadas automaticamente quando você fizer a confirmação. Use o status --porcelean om git para encontrar novos itens a serem adicionados antes de fazer o commit.

  2. Por que o incômodo de uma montagem remota para o .ssh? Poderia ser frágil e você não saberá que falhou. Use um repositório vazio para o extremo remoto com um login de chave ssh normal. Enquanto o repositório estiver vazio e você enviar apenas de uma fonte, é garantido que ele funcione sem uma mesclagem.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.