Yedekleme aracı olarak GIT


101

Bir sunucuda git yükleyin

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

Sonra /.git/bir ağ sürücüsüne (SAN, NFS, Samba neyse) ya da farklı bir diske işaret edin. Değişiklikleri güncellemek için her saat / gün vs.'de bir cron işi kullanın. .Git dizini, tüm sunucu dosyalarının versiyonlu bir kopyasını içerir (/ proc, / dev gibi işe yaramaz / karmaşık olanlar hariç)

Önemli bir geliştirme sunucusu için, uygun bir yedekleme sistemine kurmanın zorluğunu / maliyetini istemediğim ve yedeklemelerin yalnızca kolaylık sağlayacağı bir yerde (IE bu sunucuyu yedeklememiz gerekmiyor ; eğer bir şeyler ters giderse bir süre), bu geçerli bir yedekleme çözümü olabilir mi, yoksa büyük bir kaka yığını içinde mi kalacak?


3
benzer bir fikir kullanarak sparkleshare değil mi ??
B14D3

@ B14D3 Sparkleshare'nin daha çok bir tür dropbox türü olayı olduğunu düşünüyorum, ama içine bakacağım
Smudge

2
haklısın, ama fazla yedekleme şey çeşit yapmak için git kullanarak (birkaç pc kopyalama ve dosyaların sürümlerini yönetme);)
B14D3

Bununla ilgili en büyük sorun, merkezi bir kontrolün olmamasıdır - herhangi bir bakım veya yedekleme doğrulaması yapmak için makineye doğrudan (ssh) erişiminiz olması gerekir. Yedeklenecek kutulara her zaman bir uygulama yüklemeyi bulurum, sonra onları merkezi bir konumdan yönetmek çok daha büyük bir kazançtır.
hafichuk

@hafichuk Kukla / Aşçı gibi araçlarla bu kadar büyük bir sorun değil, ama amacınızı anlıyorum.
Leke

Yanıtlar:


88

Sen aptal bir insan değilsin. gitYedekleme mekanizması olarak kullanmak cazip gelebilir ve diğer kişilerin söylediklerine rağmen git, ikili dosyalar için gayet iyi çalışır. Bu konuyla ilgili daha fazla bilgi için Git Kitabından bu sayfayı okuyun . Çünkü Temelde, gitbir delta depolama mekanizması kullanmıyor, gerçekten umursamıyor neyi dosyalarınızı benziyor (ama faydası git diffstok yapılandırmasıyla ikili dosyalar için oldukça düşüktür).

gitYedeklemeyle ilgili en büyük sorun, çoğu dosya sistemi meta verisini korumamasıdır. Özellikle, gitkaydetmez:

  • dosya grupları
  • dosya sahipleri
  • dosya izinleri ("bu çalıştırılabilir" dır)
  • genişletilmiş özellikler

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

Git yedekleme meta verisi için bir Google araması, okumaya değer görünen bazı sonuçlar verir (burada ortaya koyduğum sorunları telafi etmeye çalışan bazı araçlar da dahil).

etckeeper yedekleme için geliştirildi /etcve bu sorunların çoğunu çözdü.


15
ACL'ler / izinlerden bahsettiği için +1
Larry Silverman

22
Git, boş dizinleri de saklamaz.
Flimm

ve ayrıca geçmişe göre dosya taşıma / yeniden adlandırma izlemede berbattır.
cregox

1
Git ikilik dosyalarla iyi ilgilenmediğinden, git ekine bakmak isteyebilirsiniz , bu da daha iyi yapmanıza yardımcı olur. Bununla birlikte, git'in ne olduğu fikrini değiştirir.
Wouter Verhelst

1
Bence verileri yedeklemek için git kullanabilirsiniz, ancak tüm sunucuları değil
EKanadily

21

Ben kullanmadım, ama git'e dayanan bir yedekleme aracı olan bup'a bakabilirsiniz .


Daha önce hiç bup görmedim, ilginç görünüyor
Smudge

1
Geçenlerde bup'u kullanmaya başladım, birkaç gün önce sabit diskim çöktü;
André Paramés

1
@ AndréParamés, yani söylediğiniz şey, sabit diskinizi düştükten hemen sonra ... mmmmhh ... :) sadece şaka yapıyorum
hofnarwillie

12

Geçerli bir yedekleme çözümü olabilir, etckeeper bu fikre dayanır. Ancak .gitdizinin izinlerine dikkat edin, aksi takdirde dizinde iterek /etc/shadowokunabilir .git.


11

Teknik olarak bunu yapabilirken, ona karşı iki uyarı koyardım:

1, İkili veriler için bir kaynak versiyon kontrol sistemi kullanıyorsunuz. Bu nedenle, tasarlanmadığı bir şey için kullanıyorsunuz.

2, yeni bir makine oluşturmak için bir işleminiz yoksa (dokümantasyon veya otomatik) geliştirme süreciniz için endişeleniyorum. Ya bir otobüs alırsan, ne yapılacağını ve neyin önemli olduğunu kim bilebilirdi?

Olağanüstü durum kurtarma önemlidir, ancak yeni bir geliştirme kutusunun kurulumunu her şeyi yedeklemekten daha otomatik hale getirmek (komut dosyası) daha iyidir. Komut / belgeniz için git git'i kullanın, ancak bilgisayardaki her dosya için değil.


4
Geliştirme kutularının tümü KickStart dosyalarından gelir ve aslında ortalama kutu yeniden oluşturulmadan önce yaklaşık 2 veya 3 ay sürer. Fakat insanlar yapılandırmaları değiştirip bir şeyler yapıyorlar, kutuları yeniden inşa ediyoruz ve insanlar “hey, kaynak kontrolüne koymadığımı biliyorum ama o kutuya bir şeyler koydum” der ve aptal oldukları için onlara gülerim. Her yerde, güzel zamanlar. İkili veriler bir fahişe olurdu, duştayken tamamen göz ardı ettiğim bir şey.
Leke

Temel prensipleri takip etmeyenlere karşı tavrınızı takdir ediyorum. Şahsen ben de size benzer bir durum var, ancak hepsini yakalamak için önemli olabilecek tüm yapılandırma dosyalarına bağlanan bir git deposuna sahibim. Ayrıca kurulum adımlarını içeren bir txt belgesi.
Phil Hannent

1
Git'in ikili dosyalar için oldukça iyi çalıştığını düşünüyorum, Google Android'in reponun büyük bölümünü önceden oluşturulmuş çalıştırılabilir dosyalarının git depoları olarak görüyorum.
user377178

6

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

  1. Ticari çözümlerin çoğu zaman kendi tescilli formatlarını kullanmasından farklı olarak, yedeklemeniz yaygın olarak desteklenen ve çok iyi belgelenmiş bir açık kaynak biçimindedir. Bu, verilerinizi tam olarak kontrol etmenizi sağlar. Hangi dosyaların ne zaman değiştiğini görmek çok kolaydır. Tarihinizi kısaltmak istiyorsanız, bunu da yapabilirsiniz. Tarihinizden bir şey silmek 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 çok veya az ayna, ve hepsinin özelleştirilmiş yedekleme süreleri olabilir. Yavaş İnternet trafiğinden etkilenmeyen yerel yansımayı elde edersiniz ve böylece (1) gün boyunca daha sık yedekleme yapma imkanı sunar ve (2) hızlı bir restorasyon süresi sağlar. (Sık yedeklemeler çok büyük bir artıdır, çünkü bir belgeyi en çok kaybettiğim zamanı kullanıcı hatalarına göre buluyorum. Örneğin, çocuğunuz yanlışlıkla son 5 saattir üzerinde çalıştığı bir belgenin üzerine yazar.) Yerel bir felaket veya hırsızlık durumunda veri korumanın avantajını sağlayan uzak ayna. Ve uzaktaki aynanızın İnternet bant genişliğinden tasarruf etmek için özelleştirilmiş bir zamanda yedeklenmesini istediğinizi varsayalım. Sorun değil.

Alt satır: Git yedekleme, yedekleme işleminizin nasıl yapıldığını kontrol etme konusunda size inanılmaz miktarda güç sağlar.

Bunu Windows sistemimde yapılandırdım. İlk adım, tüm yerel verilerinizi taahhüt edeceğiniz yerel git repoyu oluşturmaktır. Yerel ikinci bir sabit sürücü kullanmanızı öneririm, ancak aynı sabit sürücüyü kullanmak işe yarayacaktır (ancak bunu sabit bir yere itmeniz ya da sabit sürücü ölürse başka bir şekilde vidalanmanız beklenir).

Öncelikle 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 deponuzu 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%

Sonra, düzenli olarak Windows Zamanlayıcı tarafından çağrılacak olan yedekleme komut dosyası sarmalayı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

Daha sonra, sarmalayıcının çağırdığı yedekleme komut dosyasının kendisi var:

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%

Bütün dosyaları yoksaymaya koyduğumuz exclude-from.txt dosyasına sahibiz:

dışlamak-from.txt:

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

Herhangi bir uzak depoya gitmeniz ve üzerinde 'git init --bare' yapmanız gerekecek. Komut dosyasını yedekleme komut dosyasını çalıştırarak test edebilirsiniz. Her şeyin işe yaradığını varsayarak, Windows Zamanlayıcı'ya gidin ve vbs dosyasına doğru saatlik bir yedekleme yapın. Bundan sonra, her saat başı bilgisayarınızın gitme geçmişine sahip olacaksınız. Son derece kullanışlıdır - her yanlışlıkla bir metin bölümünü silip kaçırır mı? Git deponuzu kontrol edin.


Merak ediyorum - NetDrive veya Expandrive tarafından taklit edilenler gibi yavaş veya standart olmayan ağ sürücüleri için de işe yarar mı? Çoğu yedekleme yazılımını bu ağ sürücülerinde başarısız buluyorum. Ayrıca, yedeklemedeki tüm dosyaları listelemek ve tek tek dosyaları ayıklamak istersem işler daha yavaş ve zaman aşımına uğruyor. Git bu sorunları çözebilir mi?
JustAMartin

@JustAMartin Bunu ağ sürücülerinde hiç test etmedim, bu yüzden söyleyemem. Bir git repo IN dosyaları aldığınızda, git çok verimlidir.
user64141 16:15

4

Bu kötü bir fikir değil, ama 2 tane kırmızı bayrak olduğunu düşünüyorum.

  • Sabit disk arızalanırsa, taahhüdünüzü başka bir sunucuya / sürücüye zorlamazsanız her şeyinizi kaybedersiniz. (Etkinlik için bir planınız varsa, bahsetmeyi tercih ederim.)

... ama yine de, yolsuzlukla ilgili şeyler için iyi bir yedek olabilir. Ya da dediğiniz gibi, .git / klasörü başka bir yerdeyse.

  • Bu yedekleme her zaman boyutta artacaktır. Varsayılan olarak budama veya döndürme ya da herhangi bir şey yoktur.

... Bu nedenle, cronjob'ınıza etiketler eklemesini söylemeniz gerekebilir ve daha sonra etiketli olmayanların temizlendiğinden emin olun.


Klasik bir sorun çıkarsa da muhtemelen .git dizinini uzaktaki bir sunucuya yüklerdik rm -Rf /. Mevcut yedekleme sistemimiz 2 yıl veya 50 versiyon için (hangisi son gelirse) eşyaları tutar, böylece yedeklememiz sürekli artmaktadır. Ancak etiket ekleme fikrini seviyorum, "günlük", "haftalık" vs. etiketlere sahip olabiliriz. Etiketler
Smudge

Sürekli büyüyen alan ihtiyaçları için +1
hafichuk

@ sam git büyüyor. Tarihi N yıldan daha eskilere kurulayamazsın. Sanırım şu anki sisteminiz var.
rds

1
Boyuttaki artış ile ilgili olarak, lütfen düzenli olarak veya başka bir (merkezi) sunucuya gitmeden önce 'git gc' yapın. Bu olmadan git repo olması gerekenden daha büyüyebilir. Bir zamanlar 16 MB'a daralan 346 MB git deposu vardı.
Hendy Irawan

3

Tam bir sistemle henüz denemedim ama MySQL yedeklemelerim için kullanıyorum (--skip-extension-insert seçeneği ile) ve gerçekten benim için iyi çalıştı.

İkili veri dosyalarında sorun yaşayacaksınız (içerikleri değişebilir ve değişecektir) ve .gitklasörün gerçekten büyük olması ile ilgili sorunlar yaşayabilirsiniz . Bir .gitignoredosya ayarlamanızı ve yalnızca gerçekten ihtiyacınız olduğunu bildiğiniz metin dosyalarını yedeklemenizi öneririm .


Bunu, MySQL yedekleri için de kullanıyorum, --extended-insert = false. Taahhüt ettikten hemen sonra veya düzenli olarak "git gc" yazdığınızdan emin olun.
Hendy Irawan


3

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

Ben düşünün rsnapshot değilse - Daha iyi biri olmak daha iyi. Hard link'i iyi kullandığımda, bir yıl öncesine kadar günlük, haftalık ve aylık yedeklemeli 300 GB dosya sunucusuna (yarım milyon dosya ile) sahibim. Toplam kullanılan disk alanı yalnızca bir tam kopya + her yedeklemenin artımlı kısmıdır, ancak hardlinks sayesinde her bir yedeklemede eksiksiz bir "canlı" dizin yapısına sahibim . Başka bir deyişle, dosyalara yalnızca günlük.0 (en son yedek) altında değil, günlük.1 (yestarday) veya haftada.2 (iki hafta önce) vb.

Yedekleme klasörünü Samba ile yeniden paylaştığımda, kullanıcılarım, bilgisayarlarını yedekleme sunucusuna işaret ederek dosyayı yedeklemelerden çekebilir.

Bir başka çok iyi seçenek de rdiff-backup , ancak dosyaları sadece Explorer \ \ servername \ 'e giderek her zaman erişilebilir kılmak istediğim için, rsnapshot benim için daha iyi bir çözümdü.


Rdiff-backup'ın son sürümü 2009'dan itibaren. Son derece iyi tasarlanmış ve hiç bir güncelleme gerektirmiyor mu, yoksa sadece terk edilmiş bir proje mi?
Mateusz Konieczny

Maiteli olup olmadığını bilmiyorum, ama temelde "yapıldı".
shodanshok,

Savannah.nongnu.org/bugs/… adresine bakıldığında, 2015 yılına kadar bir miktar faaliyet olduğu görülüyor ancak birçok hata raporu yok sayılıyor. Sanırım onu ​​terk edilmiş olarak sınıflandırırım.
Mateusz Konieczny

2

Temelde sürüm yedeklemesine izin verdiği için git ile yedekleme yapmak için aynı fikre sahiptim. Sonra bu işlevselliği sağlayan rdiff-backup'u gördüm (ve çok daha fazlası). Gerçekten güzel bir kullanıcı arayüzü var (CLI seçeneklerine bakınız). Bundan oldukça memnunum. --remove-older-than 2WOldukça serin. Yalnızca 2 haftadan daha eski sürümleri silmenizi sağlar. rdiff-backupsadece farklı dosyaları saklar.


2

Git için son derece yeniyim, ancak şubeler varsayılan olarak yerel değiller ve açıkça uzak havuzlara itilmeli mi? Bu hoş olmayan ve beklenmedik bir sürprizdi. Sonuçta, yerel repolarımın hepsinin sunucuya yedeklenmesini istemiyorum ? Git kitabını okumak :

Yerel şubeleriniz otomatik olarak yazmakta olduğunuz uzaktan kumandalarla senkronize edilmez - açıkça paylaşmak istediğiniz dalları itmeniz gerekir. Bu şekilde, paylaşmak istemediğiniz işler için özel dalları kullanabilir ve yalnızca birlikte çalışmak istediğiniz konu dallarını yukarı çekebilirsiniz.

Bana göre bu, yerel makinemdeki diğer git dosyaları gibi yerel şubelerin, git gitmeyen bazı yöntemlerle düzenli olarak desteklenmediği sürece kaybolma riski taşıdığı anlamına geliyordu. Yine de bunu yapıyorum, ancak gitmedeki 'her şeyi yedekleme' depomdaki varsayımlarım kırıldı. Bu konuya açıklık getirmeyi çok isterim!


1
Uzaktan kumanda hariç, git hakkında hemen hemen her şey yereldir. Bu tasarım gereğidir. Bir şeyleri uzaktan kumandaya itebilir ve özellikle bu senaryoda olduğu gibi yedekleme için kullanılıyorsa gerekir. Dallar için, yine, evet, bir kumandanın eklenmesini istiyorsanız açıkça onları itmeniz gerekir. Gelişim için, bu harika çünkü çoğu zaman bir şeyi denemek istiyorsunuz, ancak o test dalının süresiz olarak korunmasına gerek yoktur. İhtiyacınız olanı elde ettikten sonra, muhtemelen bir dev dala birleştirip test dalını delireceksiniz.
LocalPCGuy

1

Bunu, kutularım için iyi bir metodoloji olarak buldum. Onları, yalnızca bir dağıtım bitiş noktasına yedeklenmesi gereken bir şey olmalarından değiştirir.

Tüm konfigürasyon ve paket kurulum manifestosu Puppet'te saklanır, böylece yeniden dağıtım ve konfigürasyon güncellemelerinin kolayca yapılması sağlanır. Kukla dizini git ile yedeklenir. Kickstart, ilk konuşlandırmayı yapmak için kullanılır.

Ayrıca, o sırada geliştirilmekte olan paketler için özel bir YUM deposu da tutuyorum. Bu, birlikte çalıştığımız paketlerin yerel sistemde katılımsız ikili dosyalar olarak bırakılmaması - eğer böyle bir şey olursa ve dosyalar nükleer olarak kullanılmayacaksa, ek avantajı vardır. Birisi uygun prosedürü takip etmedi.



1

Kullanılan bir yaklaşım, mantıklı.

Keepconf bu iş için rsync ve git'i kullanır, bu işi kolaylaştırmak için bu araçların üzerine bir sarıcıdır .

Yalnızca yedekleme sunucularına erişim için yapılandırılmış ssh tuşlarına sahip bir merkezi sunucuya ve yapılandırma dosyasında birkaç satır yeterlidir. Örneğin, bu, / etc / ve yüklü debian paketlerini tutmak için kendi dosyam:

[hosts]
192.168.1.10
192.168.1.11
192.168.1.12

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

Bununla rsync yedeklemesine sahibim ve git taahhüdüm var.


0

Benim kişisel görüşüm, bunun temelde tümünün geriye dönük olduğu. Dosyaları dışarı çekmek yerine yedekleme çözümüne zorluyorsunuz.

Çok daha iyisi, sunucunun konfigürasyonunu ilk etapta merkezileştirmek ve sonra kukla gibi bir şey kullanarak aşağı çekmek olacaktır.

Bu işe yarayabilir dedi, sadece bu kadar iyi olacağını sanmıyorum.

Backuppc içine bakmayı deneyin - kurmak oldukça kolay ve açıkçası mükemmel.


0

Biraz işe yarayacak, ancak iki uyarı.

  1. Taahhüt ettiğinizde dosya ekleri otomatik olarak alınmaz. Taahhüt yapmadan önce eklenecek yeni şeyler bulmak için --porcelean om git durumunu kullanın.

  2. Neden .ssh için uzaktaki bir bağın zorluğu? Kırılgan Bd olur, başarısız olduğunu bilemezsiniz. Normal bir ssh anahtar girişiyle en uç kısım için çıplak bir depo kullanın. Depo çıplak olduğu ve yalnızca bir kaynaktan zorladığınız sürece, bir birleştirme ile çalışmanız garanti edilir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.