GIT come strumento di backup


101

Su un server, installa git

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

Quindi arriva /.git/a puntare a un'unità di rete (SAN, NFS, Samba qualunque) o disco diverso. Utilizzare un processo cron ogni ora / giorno ecc. Per aggiornare le modifiche. La directory .git conterrebbe una copia con versione di tutti i file del server (esclusi quelli inutili / complicati come / proc, / dev ecc.)

Per un server di sviluppo non importante in cui non voglio la seccatura / il costo di configurarlo su un sistema di backup adeguato e in cui i backup sarebbero solo per comodità (IE non è necessario eseguire il backup di questo server ma risparmierebbe un po 'di tempo se le cose andassero male), potrebbe essere una valida soluzione di backup o cadrà semplicemente in un mucchio di cacca?


3
sparkleshare non usa un'idea simile ??
B14D3,

@ B14D3 Penso che sparkleshare sia più una specie di tipo dropbox tipo, ma lo esaminerò
Smudge

2
hai ragione, ma usando git per creare una sorta di operazione di chiusura (copia su più PC e controllo delle versioni dei file);)
B14D3,

Il grosso problema è che non esiste un controllo centrale: è necessario disporre dell'accesso diretto (ssh) alla macchina per eseguire qualsiasi forma di manutenzione o convalida del backup. Trovo sempre l'installazione di un'app sulle scatole di cui eseguire il backup, quindi amministrarli da una posizione centrale è una vittoria molto più grande.
Hafichuk,

@hafichuk Con strumenti come Puppet / Chef non è un grosso problema, ma vedo il tuo punto.
Sfumatura

Risposte:


88

Non sei una persona sciocca. L'uso gitcome meccanismo di backup può essere interessante e, nonostante ciò che hanno detto altre persone, gitfunziona perfettamente con i file binari. Leggi questa pagina dal Git Book per ulteriori informazioni su questo argomento. Fondamentalmente, dal momento che gitnon utilizza un meccanismo di archiviazione delta, non importa davvero come sono i tuoi file (ma l'utilità di git diffè piuttosto bassa per i file binari con una configurazione stock).

Il problema più grande con l'utilizzo gitper il backup è che non conserva la maggior parte dei metadati del filesystem. In particolare, gitnon registra:

  • gruppi di file
  • proprietari di file
  • permessi sui file (diversi da "è questo eseguibile")
  • attributi estesi

Puoi risolverlo scrivendo strumenti per registrare esplicitamente queste informazioni nel tuo repository, ma può essere complicato farlo bene.

Una ricerca su Google per i metadati di backup di Git produce una serie di risultati che sembrano essere degni di lettura (inclusi alcuni strumenti che già tentano di compensare i problemi che ho sollevato qui).

etckeeper è stato sviluppato per il backup /etce risolve molti di questi problemi.


16
+1 per menzionare ACL / permessi
Larry Silverman,

23
Git inoltre non memorizza directory vuote.
Flimm,

e fa anche schifo per tenere traccia dello spostamento / rinominazione dei file, attraverso la cronologia.
Cregox,

1
Dato che git non tratta molto bene i file binari, potresti anche voler esaminare git annex , il che aiuta a farlo meglio. Tuttavia, cambia l'idea di cosa sia un po 'Git.
Wouter Verhelst,

1
la mia opinione è che puoi usare git per il backup dei dati ma non per interi server
EKanadily,

21

Non l'ho usato, ma potresti guardare bup che è uno strumento di backup basato su git.


Mai visto prima, sembra interessante
Sfumino il

1
Ho iniziato a utilizzare bup di recente, solo pochi giorni prima che il mio disco rigido si bloccasse;) Il ripristino è andato bene, quindi consigliato!
André Paramés,

1
@ AndréParamés quindi quello che stai dicendo è subito dopo l'installazione del tuo disco rigido si è schiantato ... mmmmhh ... :)
sto

12

Può essere una soluzione di backup valida, etckeeper si basa su questa idea. Ma tieni d'occhio i .gitpermessi della directory altrimenti spingere /etc/shadowpuò essere leggibile nella .gitdirectory.


11

Mentre tecnicamente potresti farlo, metterei due avvertimenti:

1, stai utilizzando un sistema di controllo della versione di origine per i dati binari. Lo stai quindi usando per qualcosa per cui non è stato progettato.

2, mi preoccupo del tuo processo di sviluppo se non hai un processo (documentazione o automatizzato) per la costruzione di una nuova macchina. E se venissi colpito compra un autobus, chi saprebbe cosa fare e cosa è importante?

Il ripristino di emergenza è importante, tuttavia è meglio automatizzare (script) l'installazione di una nuova casella di sviluppo piuttosto che eseguire il backup di tutto. Sicuramente usa git per il tuo script / documentazione ma non per tutti i file su un computer.


4
I box di sviluppo provengono tutti da file KickStart e in realtà il box medio dura circa 2 o 3 mesi prima che venga ricostruito. Ma la gente cambia config e fa cose, ricostruiamo le scatole e la gente dice "ehi, so di non averlo messo nel controllo del codice sorgente ma avevo un po 'di merda su quella scatola" e rido di loro per essere stupidi. Tutto intorno, bei tempi. I dati binari sarebbero una cagna, è qualcosa che ho completamente ignorato mentre ero sotto la doccia.
Sfumatura

Apprezzo il tuo atteggiamento nei confronti di coloro che non seguono i principi di base. Personalmente ho una situazione simile a te, tuttavia ho un repository git che collega tutti i file di configurazione che potrebbero essere importanti piuttosto che catturare tutto. Inoltre un documento txt con passaggi di installazione.
Phil Hannent,

1
Penso che git funzioni abbastanza bene per i file binari, in quanto la maggior parte dei repository di Google Android sono repository git di eseguibili precompilati.
user377178

6

Uso git come backup per il mio sistema Windows ed è stato incredibilmente utile. In fondo al post, mostro gli script che utilizzo per configurare su un sistema Windows. L'uso di git come backup per qualsiasi sistema offre 2 grandi vantaggi:

  1. A differenza delle soluzioni commerciali spesso utilizzano il proprio formato proprietario, il backup è in un formato open source ampiamente supportato e ben documentato. Questo ti dà il pieno controllo dei tuoi dati. È molto facile vedere quali file sono cambiati e quando. Se vuoi troncare la tua storia, puoi farlo anche tu. Vuoi cancellare qualcosa dalla tua storia? Nessun problema. Ottenere una versione del tuo file è semplice come qualsiasi comando git.
  2. Quanti o quanti mirror vuoi e tutti possono avere tempi di backup personalizzati. Otterrai il tuo mirror locale, che è esaltato dal lento traffico Internet e ti dà quindi (1) la possibilità di eseguire backup più frequenti durante il giorno e (2) un tempo di ripristino rapido. (I backup frequenti sono un grande vantaggio, perché trovo che la maggior parte del tempo che perdo un documento sia dovuto a un errore dell'utente. Ad esempio, tuo figlio sovrascrive accidentalmente un documento su cui ha lavorato nelle ultime 5 ore.) Ma otterrai il tuo mirror remoto, che offre il vantaggio della protezione dei dati in caso di disastro locale o furto. E supponi di voler eseguire il backup del mirroring remoto in un momento personalizzato per risparmiare larghezza di banda Internet? Nessun problema.

In conclusione: un backup git ti dà un'incredibile quantità di energia nel controllare come avvengono i tuoi backup.

L'ho configurato sul mio sistema Windows. Il primo passo è creare il repository git locale in cui impegnerai tutti i tuoi dati locali. Consiglio di utilizzare un secondo disco rigido locale, ma utilizzando lo stesso disco rigido funzionerà (ma si prevede che spingerai questo da qualche parte in remoto, o altrimenti sarai fregato se il disco rigido si spegne.)

Dovrai prima installare cygwin (con rsync) e anche installare git per Windows: http://git-scm.com/download/win

Quindi, crea il tuo repository git locale (eseguilo una sola volta):

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%

Successivamente, abbiamo il nostro wrapper di script di backup, che verrà chiamato regolarmente dall'utilità di pianificazione di Windows:

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

Successivamente, abbiamo lo script di backup stesso che il wrapper chiama:

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%

Abbiamo il file exclude-from.txt, dove mettiamo tutti i file da ignorare:

escludere-from.txt:

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

Dovrai andare su qualsiasi repository remoto e fare un 'git init --bare' su di essi. È possibile testare lo script eseguendo lo script di backup. Supponendo che tutto funzioni, vai a Utilità di pianificazione di Windows e punta un backup orario verso il file vbs. Successivamente, avrai una cronologia git del tuo computer per ogni ora. È estremamente conveniente: ogni cancella accidentalmente una sezione di testo e la manca? Controlla il tuo repository git.


Solo curioso: funzionerà anche con unità di rete lente o non standard, come quelle emulate da NetDrive o Expandrive? Trovo che la maggior parte dei software di backup non riesca con queste unità di rete. Inoltre, le cose diventano dolorosamente lente e tendono al timeout, se voglio elencare tutti i file nel backup ed estrarre i singoli file. Git è in grado di risolvere questi problemi?
JustAMartin,

@JustAMartin Non l'ho mai testato su unità di rete, quindi non posso dirlo. Una volta ottenuti i file IN un repository git, git è molto efficiente.
user64141

4

Beh, non è una cattiva idea, ma penso che ci siano 2 bandiere rosse da alzare:

  • Se il disco rigido non riesce, perderai tutto se non stai spingendo il commit su un altro server / unità. (Evento se hai un piano per questo, preferisco menzionarlo.)

... ma comunque, può essere un buon backup per cose legate alla corruzione. O come hai detto, se la cartella .git / è altrove.

  • Questo backup aumenterà sempre di dimensioni. Non ci sono potature o rotazioni o altro per impostazione predefinita.

... Quindi potrebbe essere necessario dire al tuo cronjob di aggiungere tag, quindi assicurarsi che il commit che non sia stato taggato venga ripulito.


Probabilmente monteremmo la directory .git su un server remoto, anche se il classico rm -Rf /ci causerebbe alcuni problemi. Il nostro attuale sistema di backup mantiene le cose per 2 anni o 50 versioni (a seconda dell'ultima volta), quindi il nostro backup è in costante aumento comunque. Ma mi piace l'idea di aggiungere tag, potremmo avere tag "giornalieri", "settimanali" ecc.
Sfumatura

+1 per esigenze di spazio sempre crescenti
hafichuk,

@sam git è in continua crescita. Non puoi eliminare la storia più vecchia di N anni. Suppongo che il tuo sistema attuale lo faccia.
rd

1
Per quanto riguarda l'aumento delle dimensioni, eseguire 'git gc' regolarmente o prima di passare a un altro server (centrale). Senza questo il repo git potrebbe crescere (molto) più grande di quanto dovrebbe. Una volta ho avuto un repository git di 346 MB che può ridursi a 16 MB.
Hendy Irawan,

3

Non l'ho provato con un sistema completo ma lo sto usando per i miei backup MySQL (con l'opzione --skip-extended-insert) e ha funzionato davvero bene per me.

Incontrerai un problema con i file di dati binari (il loro intero contenuto potrebbe e cambierà) e potresti avere problemi con la .gitcartella che diventa davvero grande. Consiglierei di impostare un .gitignorefile e di eseguire il backup dei soli file di testo che sai davvero di aver bisogno.


Lo sto usando anche per i backup di MySQL, con --extended-insert = false. Assicurati di "git gc" regolarmente o subito dopo il commit.
Hendy Irawan,


3

Una volta ho sviluppato una soluzione di backup basata sulla sovversione. Mentre ha funzionato abbastanza bene (e git dovrebbe funzionare ancora meglio), penso che ci siano soluzioni migliori qui.

Ritengo che rsnapshot sia uno dei migliori - se non il migliore. Con un buon uso di hard link, ho un file server da 300 GB (con mezzo milione di file) con backup giornalieri, settimanali e mensili che risalgono a un anno fa. Lo spazio su disco totale utilizzato è solo una copia completa + la parte incrementale di ciascun backup, ma grazie ai collegamenti fissi ho una struttura di directory "live" completa in ciascuno dei backup. In altre parole, i file sono direttamente accessibili non solo in daily.0 (il backup più recente), ma anche in daily.1 (ieri) o settimanale.2 (due settimane fa) e così via.

Ripartendo la cartella di backup con Samba, i miei utenti sono in grado di estrarre il file dai backup semplicemente indirizzando il proprio PC al server di backup.

Un'altra ottima opzione è rdiff-backup , ma poiché mi piace avere i file sempre accessibili semplicemente dirigendo Explorer a \\ nomeserver, rsnapshot è stata una soluzione migliore per me.


L'ultima versione di rdiff-backup è del 2009. È estremamente ben progettata e non richiede alcun aggiornamento o è semplicemente un progetto abbandonato?
Mateusz Konieczny,

Non so se sia manutenuto, ma sostanzialmente è "fatto".
shodanshok,

Dall'esame di savannah.nongnu.org/bugs/… sembra che ci sia stata qualche attività nel 2015 ma molte segnalazioni di bug vengono ignorate. Penso che lo classificherò come abbandonato.
Mateusz Konieczny,

2

Ho avuto la stessa idea di eseguire il backup con git, fondamentalmente perché consente backup con versione. Poi ho visto rdiff-backup , che fornisce quella funzionalità (e molto altro). Ha un'interfaccia utente davvero gradevole (guarda le opzioni della CLI). Ne sono abbastanza contento. Il --remove-older-than 2Wè piuttosto fresco. Ti consente di eliminare solo le versioni precedenti a 2 settimane. rdiff-backupmemorizza solo differenze di file.


2

Sono estremamente nuovo su Git, ma i rami non sono locali per impostazione predefinita e devo essere esplicitamente trasferiti ai repository remoti? Questa è stata una sorpresa spiacevole e inaspettata. Dopotutto, non voglio che tutti i miei repository locali siano "sottoposti a backup" sul server? Leggendo il libro git :

I tuoi rami locali non sono automaticamente sincronizzati con i telecomandi su cui scrivi - devi spingere esplicitamente i rami che vuoi condividere. In questo modo, puoi utilizzare le filiali private per il lavoro che non vuoi condividere e fare il push solo degli argomenti su cui vuoi collaborare.

Per me questo significava che quei rami locali, come altri file non git sul mio computer locale, rischiano di perdersi a meno che non vengano regolarmente sottoposti a backup con mezzi non git. Lo faccio comunque, ma ha rotto le mie ipotesi sul fatto che git "esegua il backup di tutto" nel mio repository. Mi piacerebbe chiarimenti su questo!


1
Praticamente tutto su git ad eccezione dei telecomandi è locale. Questo è di progettazione. È possibile inviare elementi ai telecomandi e, in particolare, se utilizzati per il backup, come in questo scenario. Per i rami, di nuovo, sì, è necessario spingerli esplicitamente se si desidera che vengano aggiunti a un telecomando. Per lo sviluppo, questo è fantastico perché spesso vuoi testare qualcosa, ma non è necessario che quel ramo di test venga conservato indefinitamente. Una volta ottenuto ciò di cui hai bisogno, probabilmente lo unirai a un ramo di sviluppo e del ramo di test.
LocalPC Acquista

1

Ho trovato che questa è una buona metodologia per le mie scatole di sviluppo. Li cambia da qualcosa di cui è necessario eseguire il backup su un endpoint di distribuzione.

Tutti i manifesti di configurazione e installazione dei pacchetti sono archiviati in Puppet, consentendo facili ridistribuzioni e aggiornamenti di configurazione. La directory Puppet viene copiata con git. Kickstart viene utilizzato per eseguire la distribuzione iniziale.

Conservo anche un repository YUM personalizzato per qualsiasi pacchetto in fase di sviluppo in quel momento. Questo ha l'ulteriore vantaggio che qualunque pacchetto con cui stiamo lavorando non viene lasciato come binario incustodito sul sistema locale - se ciò accade e i file vengono rovinati, beh. Qualcuno non ha seguito la procedura corretta.



1

È un approccio utilizzato, ha senso.

Keepconf usa rsync e git per questo lavoro, è un wrapper su questi strumenti per mantenere la cosa facile.

È necessario solo un server centrale con chiavi ssh configurate per l'accesso ai server di backup e alcune righe nel file di configurazione. Ad esempio, questo è il mio file per mantenere tutti / etc / e i pacchetti debian installati:

[hosts]
192.168.1.10
192.168.1.11
192.168.1.12

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

Detto questo, ho il backup rsync e il commit git.


0

La mia opinione personale è che questo è sostanzialmente tutto all'indietro. Stai spingendo i file in una soluzione di backup, anziché estrarli.

Molto meglio sarebbe centralizzare la configurazione del server in primo luogo, e poi abbatterlo, usando qualcosa come burattino.

Detto questo, potrebbe funzionare, non penso che sarebbe così bello.

Prova a guardare nel backuppc: è abbastanza facile da configurare ed è francamente geniale.


0

Funzionerebbe un po ', ma due avvertenze.

  1. Le aggiunte ai file non verranno raccolte automaticamente quando esegui il commit. Usa lo stato --porcelean om git per trovare nuovi elementi da aggiungere prima di eseguire il commit.

  2. Perché la seccatura di un montaggio remoto per .ssh? Potrebbe essere fragile Bd non saprai che ha fallito. Utilizzare un repository nudo per l'estremità remota con un normale accesso con chiave ssh. Finché il repository è nudo e si spinge da una sola fonte, è garantito il funzionamento senza una fusione.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.