Soru Yedekleme aracı olarak GIT


Bir sunucuda, git kurulumu

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

O zaman al /.git/ Bir ağ sürücüsüne (SAN, NFS, Samba neyse) veya farklı bir diske işaret etmek. Değişiklikleri güncellemek için her saat / gün vb. .Git dizini, tüm sunucu dosyalarının (/ proc, / dev vb. Gibi yararsız / karmaşık olanlar hariç) sürümlenmiş bir kopyasını içerecektir.

Önemli bir yedekleme sunucusu için, uygun bir yedekleme sistemine kurmanın zorluğunu / maliyetini istemediğim ve yedeklerin yalnızca kolaylık sağlamak için olduğu (I.E. gerek Bu sunucu yedeklemek için ama şeyler yanlış gitti eğer biraz zaman kazandıracak, bu geçerli bir yedekleme çözümü olabilir mi yoksa sadece büyük bir kaka yığını içinde düşecek mi?


88
2017-12-15 12:10


Menşei


benzer bir fikir kullanarak sparkleshare yok mu? - B14D3
@ B14D3 Bence sparkleshare bir çeşit dropbox türü bir şey değil, ama ben ona bakacağım - Smudge
Haklısın, ama bir çeşit buckup şeyi yapmak için git kullanıyor (birkaç bilgisayara kopyalayıp dosyaların sürümlerini kontrol ediyor);) - B14D3
Bununla ilgili en büyük sorun, merkezi kontrolün olmamasıdır - herhangi bir bakım veya yedek doğrulama şekli oluşturmak için makineye doğrudan (ssh) erişime sahip olmanız gerekir. Her zaman yedeklenecek kutulara bir uygulama yüklüyor, daha sonra onları merkezi bir konumdan yönetmek çok daha büyük bir kazanç. - hafichuk
@hafichuk Kukla / Aşçı gibi araçlarla bu kadar büyük bir sorun değil, ama ben sizin noktanızı görüyorum. - Smudge


Cevaplar:


Aptal bir insan değilsin. kullanma git Bir yedek mekanizma olarak çekici olabilir ve diğer insanların söylediğine rağmen, git İkili dosyalarla iyi çalışır. okumak Git sayfasından bu sayfa Bu konu hakkında daha fazla bilgi için. Temel olarak git bir delta depolama mekanizması kullanmıyor, gerçekten ilgilenmiyor ne dosyalarınız gibi görünüyor (ama git diff Bir stok konfigürasyonu ile ikili dosyalar için oldukça düşüktür).

Kullanarak en büyük sorun git Yedekleme, çoğu dosya sistemi meta verisini korumamasıdır. özellikle, git kayıt yapmıyor:

  • dosya grupları
  • dosya sahipleri
  • dosya izinleri ("bu yürütülebilir dosya" dışında)
  • genişletilmiş özellikler

Bu bilgiyi açık bir şekilde veri havuzunuza kaydetmek için araçlar yazarak çözebilirsiniz, ancak bunu doğru yapmak zor olabilir.

Bir Google araması git yedek meta verileri okumaya değer görünen bir dizi sonuç verir (burada yükselttiğim sorunları telafi etmeye çalışan bazı araçlar dahil).

etckeeper yedekleme için geliştirildi /etc ve bu problemlerin çoğunu çözer.


78
2017-12-15 17:25



ACL'leri / izinleri belirtmek için +1 - Larry Silverman
Git ayrıca boş dizinleri de saklamıyor. - Flimm
ve aynı zamanda tarih boyunca dosya taşıma / yeniden adlandırma izleme için de berbat. - cregox
Git, ikili dosyalar ile çok iyi uğraşmadığından, aynı zamanda git ekiBu daha iyi yardımcı olur. Bununla birlikte, git bir şey ne olduğu fikrini değiştirir. - Wouter Verhelst
Benim görüşüme göre, verileri sunucuya değil tüm veriyi kullanabilmeniz - EKanadily


Kullanmıyorum ama bakabilirsin bup Git tabanlı bir yedekleme aracıdır.


20
2017-12-15 13:27



Daha önce hiç bup görmedim, ilginç görünüyor - Smudge
Son zamanlarda bup kullanmaya başladım, sadece bir kaç gün önce sabit diskim çöktü;) Geri yükleme iyi gitti, bu yüzden tavsiye! - André Paramés
@ AndréParamés demek istediğini söyledikten hemen sonra, sabit sürücün düştü ... mmmmhh ... :) sadece şaka yapıyorum - hofnarwillie


Geçerli bir yedekleme çözümü olabilir, bu fikre dayanan bir etkiye sahiptir. Ama göz kulak ol. .git aksi halde dizin izinleri /etc/shadow içinde okunabilir .git dizin.


12
2017-12-15 12:18





Teknik olarak bunu yapabiliyor olsanız da, ona karşı iki uyarı koyardım:

1, ikili veri için bir kaynak versiyon kontrol sistemi kullanıyorsunuz. Bu nedenle, bunun tasarlanmadığı bir şey için kullanıyorsunuz.

2, yeni bir makine oluşturmak için bir süreç (belgeler veya otomatik) yoksa geliştirme süreciniz için endişeleniyorum. Ya bir otobüs satın alırsan, ne yapacağını ve neyin önemli olduğunu kim bilemez?

Felaket kurtarma önemlidir, ancak her şeyi yedeklemekten ziyade yeni bir geliştirme kutusunun kurulumunu otomatikleştirmek (betik) daha iyidir. Komut dosyanız / belgeleriniz için git'i kullanın, ancak bir bilgisayardaki her dosya için kullanmayın.


11
2017-12-15 13:45



Geliştirme kutularının hepsi KickStart dosyalarından gelir ve aslında ortalama kutu yeniden oluşturulmadan önce yaklaşık 2 veya 3 ay sürer. Ama insanlar konfigürasyonları değiştirir ve bazı şeyleri yaparlar, kutuları yeniden inşa ederiz ve insanlar “hey, ben kaynak kontrolüne koymadığımı biliyorum ama o kutuda bazı şeylerim vardı” diyorlar ve aptal oldukları için onlara gülüyorum. Her zaman, güzel zamanlar. İkili veri bir orospu olurdu, duştayken tamamen gözden kaçırdığım bir şey. - Smudge
Temel prensiplere uymayanlara karşı tutumunuzu alkışlıyorum. Şahsen size benzer bir durumum var, ancak tüm yapılandırma dosyalarında hepsinden daha önemli olabilecek bir bağlantıya sahip bir git depomuz var. Ayrıca kurulum adımlarıyla bir txt dokümanı. - Phil Hannent
Git'in ikili dosyalar için oldukça iyi çalıştığını düşünüyorum, vide Google Android'in repo'ların toplu kısmı, önceden oluşturulmuş yürütülebilir dosyaların git depolarıdır. - user377178


Git'i Windows sistemimin bir yedeği olarak kullanıyorum ve inanılmaz derecede faydalı oldu. Gönderinin alt kısmında, bir Windows sisteminde yapılandırmak için kullandığım komut dosyalarını gösteriyorum. Git'in herhangi bir sistem için yedek olarak kullanılması 2 büyük avantaj sağlar:

  1. Ticari çözümlerden farklı olarak genellikle kendi özel biçimlerini kullanırlar, yedeklemeniz yaygın olarak desteklenen ve çok iyi belgelenmiş açık kaynak biçimindedir. Bu, verilerinizi tam olarak kontrol etmenizi sağlar. Hangi dosyaların değiştiğini ve ne zaman olduğunu görmek çok kolay. Tarihinizi kısaltmak isterseniz, bunu da yapabilirsiniz. Tarihinizden bir şeyleri yok etmek mi istiyorsunuz? Sorun değil. Dosyanızın bir sürümünü geri almak, herhangi bir git komutu kadar basittir.
  2. İstediğiniz kadar ya da çok sayıda ayna gibi, hepsi de özelleştirilmiş yedekleme zamanlarına sahip olabilir. Yavaş internet trafiği ile yükü olmayan yerel aynayı alacaksınız ve böylece (1) gün boyunca daha sık yedeklemeler yapabileceğiniz ve (2) hızlı bir restorasyon süresi kazandırabileceksiniz. (Sık yedeklemeler. Örneğin, çocuk yanlışlıkla geçen 5 saat boyunca üzerinde çalıştığı bir belge üzerine yazar. Ben en çok zaman bulmak çünkü bir belge kullanıcı hatasından kaybetmek, büyük bir artı vardır) ancak alırsınız Yerel bir felaket veya hırsızlık durumunda veri korumanın avantajını veren uzak ayna. İnternet bant genişliğinizi korumak için uzak aynanızın özelleştirilmiş zamanda yedeklenmesini istediğinizi varsayalım? Sorun değil.

Alt satır: Bir git yedekleme, yedeklemelerinizin nasıl gerçekleştiğini kontrol etmede size inanılmaz miktarda güç sağlar.

Bunu Windows sistemimde yapılandırdım. İlk adım, tüm yerel verilerinizi gerçekleştireceğiniz yerel git repo'yu oluşturmaktır. Yerel bir ikinci sabit sürücüyü kullanmanızı öneriyorum, ancak aynı sabit diskin kullanılması da işe yarayacaktır (ancak bunun uzak bir yere ya da sabit diskiniz ölürse vidalanmanıza yol açması beklenir.)

Önce cygwin'i (rsync ile) kurmanız ve ayrıca Windows için git'i yüklemeniz gerekir: http://git-scm.com/download/win

Ardından, yerel git repo'unuzu oluşturun (yalnızca bir kez çalıştırın):

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%

Ardından, Windows Zamanlayıcı tarafından düzenli olarak çağrılacak olan yedekleme komut dosyası sarıcımız var:

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

Ardından, sarmalayıcının aradığı yedekleme komut dosyasına sahibiz:

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%

Tüm dosyaları göz ardı etmeye koyduğumuz exclude-from.txt dosyası var:

dışlamak-from.txt:

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

Herhangi bir uzak depoya gitmeli ve üzerinde 'git init --bare' yapmalısınız. Komut dosyasını, yedek komut dosyasını yürüterek test edebilirsiniz. Her şeyin işe yaradığını varsayarsak, Windows Zamanlayıcı'ya gidin ve vbs dosyasına doğru bir saatlik yedekleme yapın. Bundan sonra, her saat için bilgisayarınızın git geçmişine sahip olacaksınız. Son derece kullanışlı - her biri bir metin bölümünü yanlışlıkla siler ve özlüyor mu? Sadece git deposunu kontrol et.


6
2018-03-21 17:10



Sadece merak ediyorum - NetDrive veya Expandrive tarafından taklit edilenler gibi yavaş veya standart olmayan ağ sürücüleri için de çalışacak mı? Bu ağ sürücülerinde başarısız olan çoğu yedekleme yazılımını buluyorum. Ayrıca, yedeklemedeki tüm dosyaları listelemek ve tek tek dosyaları ayıklamak istiyorsanız, işler ağrılı bir şekilde yavaşlar ve zaman aşımına uğrar. Git bu sorunları çözebilir mi? - JustAMartin
@JustAMartin Ağ sürücülerinde hiç test etmedim, bu yüzden söyleyemem. Dosyaları bir git repo'yu aldığınızda, git çok verimlidir. - user64141


Bu kötü bir fikir değil, ama bence 2 tane kırmızı bayrak var:

  • Sabit disk başarısız olursa, başka bir sunucuya / sürücüye yüklemeyi zorlamıyorsanız, her şeyi kaybedersiniz. (Eğer bir planın varsa, bahsetmeyi tercih ederim.)

... ama yine de, yolsuzluklarla ilgili şeyler için iyi bir yedek olabilir. Ya da söylediğin gibi .git / klasör başka bir yerdeyse.

  • Bu yedekleme daima boyut olarak artacaktır. Budama, rotasyon veya herhangi bir şey yoktur.

... Bu yüzden, cronjob'nize etiket eklemesini söylemeniz gerekebilir ve etiketlenmeyen taahhütler temizlenecektir.


4
2017-12-15 13:40



Her ne kadar klasik olsa da, .git dizinini uzak bir sunucuya monte edebilirdik. rm -Rf / bize bazı sorunlara neden olur. Şu anki yedekleme sistemimiz 2 yıl veya 50 sürüm (hangisi bitiyorsa) için kalıyor, bu sayede yedeklerimiz sürekli olarak artıyor. Ama etiket ekleme fikrini beğendim, "günlük", "haftalık" vb. Etiketlerimiz olabilirdi. - Smudge
Sürekli büyüyen alan gereksinimleri için +1 - hafichuk
@sam git sürekli büyüyor. N yıldan daha eski geçmişi eritebilirsin. Mevcut sisteminizin yaptığını varsayalım. - rds
Boyuttaki artışla ilgili olarak, lütfen 'git gc'yi düzenli olarak veya başka bir (merkezi) sunucuya geçmeden önce yapın. Bu olmadan git repo, olması gerekenden daha fazla büyüyebilir. Bir kez 16 MB'ye küçültebilecek bir 346 MB git repo vardı. - Hendy Irawan


Tam bir sistemle denemedim ama bunu MySQL yedeklerim için kullanıyorum (--skip-extended-insert seçeneğiyle) ve gerçekten benim için çok işe yaradı.

İkili veri dosyalarıyla (tüm içeriği değişebilir ve değişecektir) sorun yaşayacaksınız ve .git klasör gerçekten büyük oluyor. Kurulumunu öneririm .gitignore Dosya ve sadece gerçekten ihtiyacınız olan metin dosyalarını yedekleme.


3
2017-12-15 13:23



--Extended-insert = false ile de MySQL yedeklemeleri için kullanıyorum. Düzenlemeden sonra düzenli olarak veya hemen "git gc" ye emin olun. - Hendy Irawan
Görmek Git'te bir MySQL veritabanını yedeklemek iyi bir fikir mi? - Michael Hampton♦


Bir zamanlar yıkıma dayalı bir yedekleme çözümü geliştirdim. Oldukça iyi çalıştı (ve git daha iyi çalışmalıdır), burada daha iyi çözümler olduğunu düşünüyorum.

düşünüyorum rsnapshot daha iyi biri olmak - eğer değilse  daha iyi. İyi bir sabit bağlantı ile, bir yıl boyunca geri, günlük, haftalık ve aylık yedekleme ile 300 GB dosya sunucusu (yarım milyon dosyaları) var. Toplam kullanılan disk alanı, yalnızca bir tam kopya + her bir yedeklemenin artımlı kısmıdır, ancak sabit diskler sayesinde bir tamamlayınız Yedeklerin her birinde "canlı" dizin yapısı. Diğer bir deyişle, dosyalara yalnızca günlük olarak (en yeni yedekleme) değil, günlük olarak (günde 1) (hafta içi) veya haftada 2 (iki hafta önce), vb. Doğrudan erişilemez.

Yedekleme klasörünü Samba ile yeniden yüklerken, kullanıcılarım PC'lerini yedekleme sunucusuna işaret ederek dosyayı yedeklerden alabilirler.

Başka bir çok iyi seçenek rdiff-backupama ben her zaman sadece Explorer'a \\ servername 'e gidip dosyaları erişilebilir kılmaktan hoşlandığım gibi, rsnapshot benim için daha iyi bir çözümdü.


3
2018-03-21 20:01



Rdiff yedeklemenin son sürümü 2009'dan itibaren. Son derece iyi tasarlanmış ve hiç güncellenmemiş mi yoksa sadece terk edilmiş bir proje mi? - Mateusz Konieczny
Maaşlı olup olmadığını bilmiyorum, ama temelde "bitti". - shodanshok
Bakmaktan savannah.nongnu.org/bugs/... 2015 gibi geç bir etkinlik olduğu görülüyor, ancak birçok hata raporu göz ardı ediliyor. Sanırım onu ​​terkedilmiş olarak sınıflandırıyorum. - Mateusz Konieczny


Temelde sürümlü yedeklemeye izin verdiği için git ile yedeklemenin aynı fikri vardı. Gördüğümde rdiff-backupBu işlevselliği sağlar (ve daha fazlası). Gerçekten güzel bir kullanıcı arayüzü var (CLI seçeneklerine bakın). Bundan oldukça memnunum. --remove-older-than 2W oldukça havalı. Sadece 2 haftadan eski sürümleri silmenizi sağlar. rdiff-backup sadece dosyaların dosyalarını saklar.


2
2017-12-15 18:07





Git için çok yeniyim, ancak varsayılan olarak şubeler yerel değil ve uzak depolara açıkça ittirilmeli mi? Bu nahoş ve beklenmedik bir sürpriz oldu. Sonuçta, istemiyorum herşey yerel repo'm sunucuya 'yedeklenecek' mi? Okuma git kitabı:

Yerel şubeleriniz, yazdığınız uzaktan kumandalara otomatik olarak senkronize edilmez. Paylaşmak istediğiniz şubeleri açıkça itmeniz gerekir. Bu şekilde paylaşmak istemediğiniz iş için özel şubeleri kullanabilir ve yalnızca üzerinde ortak çalışma yapmak istediğiniz konu dallarını yukarı kaldırabilirsiniz.

Bana göre bu yerel şubeler, yerel makinemdeki gitmeyen diğer dosyalar gibi, düzenli olmayan bazı yöntemlerle düzenli olarak yedeklenmedikçe kaybolma riski taşıyordu. Bunu yine de yapıyorum, ama repo'mdaki git 'her şeyi destekleme' hakkındaki varsayımlarımı kırdı. Bu konuda açıklama yapmayı çok isterim!


2
2018-03-06 13:22



Uzaktan kumanda ile gitme hakkında hemen hemen her şey yereldir. Bu tasarım gereğidir. Bir şeyi uzaktan kumandaya atabilir ve özellikle bu senaryoda olduğu gibi yedeklemede kullanılırsa. Şubeler için yine evet, bir uzaktan kumandaya eklenmesini istiyorsanız, onları açıkça zorlamanız gerekir. Gelişim için bu harikadır çünkü çoğu zaman bir şeyi test etmek istersiniz, ancak bu test dalının süresiz olarak korunmasına gerek yoktur. İhtiyacınız olan şeylere sahip olduktan sonra, muhtemelen bir dev dalı ve test dalını birleştireceksiniz. - LocalPCGuy


Bunu, dev kutularm için iyi bir metodoloji olarak buldum. Onları yalnızca bir dağıtım uç noktasına yedeklenmesi gereken bir şey olmaktan değiştirir.

Tüm yapılandırma ve paket kurulum bildirimleri Kukla'da saklanmakta ve kolay yeniden dağıtım ve yapılandırma güncellemelerine izin vermektedir. Kukla dizini git ile yedeklenir. Kickstart ilk dağıtımı yapmak için kullanılır.

O zamanda hangi paketler geliştiriliyorsa, özel bir YUMA deposu da saklıyorum. Bu, çalışmakta olduğumuz paketlerin yerel sistemde yalnızca katılımsız ikililere bırakılmadığı gibi bir yararı da beraberinde getiriyor - eğer bu olursa ve dosyalar iyi nuklu olsun. Birisi uygun prosedürü takip etmedi.


1
2017-12-15 14:47