Hangi web sitesi yedekleme için daha iyidir - rsync veya git push


16

Felaket kurtarma amacıyla farklı sağlayıcılarda 2 LAMP web sunucusu çalıştırıyorum - yüksek güçlü bir canlı sunucu ve düşük güçlü bir yedekleme sunucusu.

Şu anda her 4 saatte bir canlı sunucudan yedekleme sunucusuna tüm verileri rsync.

Bu iyi çalışıyor, ancak rsync hangi dosyaların değiştiğini anlarken sistem yükünü hızlandırıyor.

Tüm web siteleri de git depolarında yaşadığından, git push'un daha iyi bir yedekleme tekniği olup olmadığını merak ediyorum.

Git repo canlı yüklemeler klasörü dahil etmek gerekir; ve sonra yedekleme işlemi şöyle olur:

live$ git add .
live$ git commit -a -m "{data-time} snapshot"
live$ git push backup live_branch

ve ardından her basışta ödeme yapmak için yedekleme sunucusunda bir gönderme taahhüdü kancası bulundurun.

Her web sitesinin boyutu 50M ila 2GB arasında değişmektedir. Yaklaşık 50 ayrı git deposu ile karşılaşırdım.

Bu rsync'den "daha iyi" bir çözüm mü?

  • Git hangi dosyaların değiştiğinin hesaplanmasında daha iyi midir?
  • Git push rsync'den daha verimli mi?
  • Ne unuttum?

Teşekkürler!

---- Bazı karşılaştırma testlerinden elde edilen veriler ------

1) 52MB klasörü daha sonra yeni bir 500k klasör eklenir (çoğunlukla metin dosyaları)

rsync

sent 1.47K bytes  received 285.91K bytes  
total size is 44.03M  speedup is 153.22

real    0m0.718s    user    0m0.044s    sys     0m0.084s

git

Counting objects: 38, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (37/37), done.
Writing objects: 100% (37/37), 118.47 KiB, done.
Total 37 (delta 3), reused 0 (delta 0)

real    0m0.074s     user   0m0.029s    sys     0m0.045s

2) 1.4G klasörü daha sonra yeni bir 18M klasörü eklenir (çoğunlukla görüntüler)

rsync

sent 3.65K bytes  received 18.90M bytes
total size is 1.42G  speedup is 75.17

real    0m5.311s    user    0m0.784s    sys     0m0.328s

git

Counting objects: 108, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (106/106), done.
Writing objects: 100% (107/107), 17.34 MiB | 5.21 MiB/s, done.
Total 107 (delta 0), reused 0 (delta 0)

real    0m15.334s    user   0m5.202s    sys     0m1.040s

3) 52M klasörü daha sonra yeni bir 18M klasörü ekler (esas olarak görüntüler)

rsync

sent 2.46K bytes  received 18.27M bytes  4.06M bytes/sec
total size is 62.38M  speedup is 3.41

real    0m4.124s    user    0m0.640s    sys     0m0.188s

git

Counting objects: 108, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (106/106), done.
Writing objects: 100% (107/107), 17.34 MiB | 5.43 MiB/s, done.
Total 107 (delta 1), reused 0 (delta 0)

real    0m6.990s    user    0m4.868s    sys     0m0.573s

4) 1.4G klasörü daha sonra yeni bir 500k klasör ekleme (çoğunlukla metin)

rsync

sent 2.66K bytes  received 916.04K bytes  612.47K bytes/sec
total size is 1.42G  speedup is 1547.14

real    0m1.191s    user    0m0.180s    sys     0m0.268s

git

Counting objects: 49, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (48/48), done.
Writing objects: 100% (48/48), 177.90 KiB, done.
Total 48 (delta 3), reused 0 (delta 0)

real    0m1.776s    user    0m0.390s    sys     0m0.497s

5) 1.4G klasörü - değişiklik yok

rsync

sent 1.72K bytes  received 716.44K bytes  287.26K bytes/sec
total size is 1.42G  speedup is 1979.18

real    0m1.092s    user    0m0.168s    sys     0m0.272s

git

nothing to commit (working directory clean)

real    0m0.636s    user    0m0.268s    sys     0m0.348s

5) 52M klasörü - değişiklik yok

rsync

sent 528 bytes  received 88.40K bytes  59.29K bytes/sec
total size is 62.38M  speedup is 701.41

real    0m0.779s    user    0m0.044s    sys     0m0.144s

git

nothing to commit (working directory clean)

real    0m0.156s    user    0m0.057s    sys     0m0.097s

3
"güzel rsync" ne olacak? Sistem yükü artışı tam olarak istediğiniz şeydir: AFAP işlemini bitirin ve web sitesinin çalışmasını etkilemediği sürece sorun yok.

1
Teşekkürler - Ben zaten yardımcı olan bir "güzel rsync" yapıyorum
David Laing

Yanıtlar:


4

Aslında her ikisinin dengeli bir karışımını kullanmanızı öneririm. Ana yedeklemeniz her gece gitmeye (en azından) bağlı olmalıdır. Haftada bir veya iki kez rsync kullanarak üretim kutusundan uzak tutulan başka bir makineyle senkronize edin.

Git, anında kurtarma işleminde size yardımcı olacaktır ve yedeklemenizin sürüm düzenlenmiş olması ve bir değişiklik günlüğüne sahip olması nedeniyle verilerin analizini kolaylaştırır. Verilerde yapılan büyük değişikliklerden sonra, bir taahhütte bulunup manuel olarak git'e basabilir ve nedeni changelog'a koyabilirsiniz. Git bozulursa, rsync kurtarmaya gelir, ancak rsync'in sıklığına bağlı olarak hala veri kaybedeceğinizi unutmayın.

Temel kural: yedekleme ve olağanüstü durum kurtarma söz konusu olduğunda, hiçbir şey size% 100 kurtarma vermeyi garanti edemez.


2

Rsync harika bir senkronizasyon aracıdır, ancak Git'i sunucu (lar) üzerinde çalıştırırken ve güncellemeler yaparken pushveya pullgüncellerken çok daha fazla çok yönlülük elde edersiniz .

Sunucumuzda kullanıcı tarafından oluşturulan içeriği izlemem ve yedeklemem gerekiyor. productionSunucu git repo bir kopyası vardır ve her gece otomatik ekler ve cron ile yeni dosyaların tümü taahhüt. Bunlar push, daha sonra sunucuların geri kalanını senkronize etmek için kancaları kullanan gitolit sunucumuzda düzenlenir.

Sunucularda repo kopyaları bulunduğundan, yalnızca bir anlık görüntü değil, sunucunuza bir şey olursa sizi kolayca kurtarabilecek ayrıntılı geçmiş bilgileri alırsınız.

Sanırım her ikisinin de sundukları konusunda iyi bir anlayışa sahip olduğunuzu düşünüyorum, sadece kod tabanını kontrol eden / dışa aktaran sunuculardan sadece kendi depolarına sahip olan düşünce tarzınızı değiştirirdim. Başka bir düşünce, medya dosyalarınızı yeniden senkronize edebileceğiniz (bu sitelerin bazıları için 2GB dediniz, bu da beni çok fazla dosya türü olduğunu düşündürüyor mu?) Ve Git'te izleyememeniz.


Bazı performans verileri ekledim; Bu da rsync'in neredeyse her zaman git'ten daha hızlı olduğunu gösterir. Bununla birlikte, canlı sunucuda git depolarının olmasının ekstra gücü hakkında puanlarınızı beğendim - Değişikliklerin git repo'suna itilmesiyle melez bir yaklaşımın en iyi olmadığını merak ediyorum ve sonra git depoları yedeklemeye yeniden yönlendiriliyor sunucusu ...
David Laing
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.