Bu makalede, veri akışını ayrı bileşenlere (parçalara) bölerek bir depo oluşturan yedekleme yazılımı ele alınacaktır.
Depo bileşenleri daha da sıkıştırılıp şifrelenebilir ve en önemlisi, tekrarlanan yedekleme işlemleri sırasında yeniden kullanılabilir.
Böyle bir depodaki yedek kopya, örneğin çeşitli karma işlevlerine dayalı olarak birbirine bağlı bileşenlerin adlandırılmış bir zinciridir.
Birkaç benzer çözüm var, 3'e odaklanacağım: zbackup, borgbackup ve restic.
Beklenen Sonuçlar
Tüm başvuru sahipleri öyle ya da böyle bir arşiv oluşturulmasını talep ettiğinden, en önemli faktörlerden biri arşivin boyutunu tahmin etmek olacaktır. İdeal olarak, kabul edilen metodolojiye göre boyutu 13 GB'tan fazla olmamalı veya iyi optimizasyona bağlı olarak daha az olmalıdır.
Ayrıca, tar gibi arşivleyicileri kullanmadan doğrudan dosyaların yedek kopyalarını oluşturabilmek ve ayrıca rsync ve sshfs gibi ek araçlar olmadan ssh/sftp ile çalışabilmek de son derece arzu edilen bir durumdur.
Yedekleme oluştururken davranış:
- Havuzun boyutu değişikliklerin boyutuna eşit veya daha az olacaktır.
- Sıkıştırma ve/veya şifreleme kullanıldığında ağır CPU yükü beklenir ve arşivleme ve/veya şifreleme işlemi bir yedek depolama sunucusunda çalışıyorsa oldukça yüksek ağ ve disk yükü olması muhtemeldir.
- Depo hasar görmüşse, hem yeni yedeklemeler oluştururken hem de geri yüklemeye çalışırken gecikmeli bir hata oluşması muhtemeldir. Havuzun bütünlüğünü sağlamak için ek önlemler planlamak veya bütünlüğünü kontrol etmek için yerleşik araçları kullanmak gerekir.
Önceki makalelerden birinde gösterildiği gibi tar ile çalışmak referans değeri olarak alınmıştır.
Zbackup'ı test etme
Zbackup'ın genel mekanizması, programın giriş veri akışında aynı verileri içeren alanları bulması, ardından isteğe bağlı olarak bunları sıkıştırıp şifrelemesi ve her alanı yalnızca bir kez kaydetmesidir.
Veri tekilleştirme, mevcut veri bloklarıyla bayt bayt eşleşmeleri kontrol etmek için kayan pencereli 64 bit halka karma işlevi kullanır (rsync'in bunu nasıl uyguladığına benzer).
Çok iş parçacıklı lzma ve lzo sıkıştırma için, aes ise şifreleme için kullanılır. En son sürümler, gelecekte eski verileri depodan silme özelliğine sahiptir.
Program minimum bağımlılıkla C++ ile yazılmıştır. Yazar görünüşe göre unix yolundan ilham almış, bu nedenle program yedeklemeler oluştururken stdin'deki verileri kabul ediyor ve geri yükleme sırasında stdout'ta benzer bir veri akışı üretiyor. Böylece zbackup, kendi yedekleme çözümlerinizi yazarken çok iyi bir “yapı taşı” olarak kullanılabilir. Örneğin makalenin yazarı, bu programı yaklaşık 2014'ten beri ev makineleri için ana yedekleme aracı olarak kullanıyor.
Aksi belirtilmediği sürece veri akışı normal bir tar olacaktır.
Bakalım sonuçlar ne olacak:
Çalışma 2 seçenekte kontrol edildi:
- bir depo oluşturulur ve kaynak verilerle birlikte sunucuda zbackup başlatılır, ardından havuzun içeriği yedekleme depolama sunucusuna aktarılır.
- Yedekleme depolama sunucusunda bir depo oluşturulur, yedekleme depolama sunucusunda zbackup ssh aracılığıyla başlatılır ve veri ona boru yoluyla gönderilir.
İlk seçeneğin sonuçları şu şekildeydi: 43dk11s - şifrelenmemiş bir depo ve lzma kompresörü kullanıldığında, 19dk13s - kompresörü lzo ile değiştirirken.
Sunucudaki orijinal verilerle ilgili yük şu şekildeydi (lzma ile bir örnek gösteriliyor; lzo ile yaklaşık olarak aynı resim vardı, ancak rsync'in payı yaklaşık dörtte biri kadardı):
Böyle bir yedekleme işleminin yalnızca nispeten nadir ve küçük değişiklikler için uygun olduğu açıktır. Ayrıca zbackup'ın 1 iş parçacığıyla sınırlandırılması şiddetle tavsiye edilir, aksi takdirde çok yüksek bir CPU yükü olacaktır, çünkü Program birden fazla iş parçacığında çalışma konusunda çok iyidir. Disk üzerindeki yük küçüktü ve bu, genel olarak modern SSD tabanlı disk alt sistemiyle fark edilmiyordu. Ayrıca, depo verilerini uzak bir sunucuya senkronize etme işleminin başlangıcını da açıkça görebilirsiniz; işlem hızı, normal rsync ile karşılaştırılabilir ve yedek depolama sunucusunun disk alt sisteminin performansına bağlıdır. Bu yaklaşımın dezavantajı yerel bir havuzun depolanması ve bunun sonucunda verilerin çoğaltılmasıdır.
Daha ilginç ve pratikte uygulanabilir olanı, zbackup'ı doğrudan yedekleme depolama sunucusunda çalıştıran ikinci seçenektir.
Öncelikle lzma kompresörü ile şifreleme kullanmadan işlemi test edeceğiz:
Her test çalışmasının çalışma süresi:
1'i başlat
2'i başlat
3'i başlat
39m45s
40m20s
40m3s
7m36s
8m3s
7m48s
15m35s
15m48s
15m38s
Aes kullanarak şifrelemeyi etkinleştirirseniz sonuçlar oldukça yakındır:
Aynı veriler üzerinde şifrelemeyle çalışma süresi:
1'i başlat
2'i başlat
3'i başlat
43m40s
44m12s
44m3s
8m3s
8m15s
8m12s
15m0s
15m40s
15m25s
Şifreleme lzo kullanılarak sıkıştırmayla birleştirilirse şöyle görünür:
Saatleri:
1'i başlat
2'i başlat
3'i başlat
18m2s
18m15s
18m12s
5m13s
5m24s
5m20s
8m48s
9m3s
8m51s
Ortaya çıkan havuzun boyutu 13 GB ile nispeten aynıydı. Bu, veri tekilleştirmenin doğru çalıştığı anlamına gelir. Ayrıca, halihazırda sıkıştırılmış veriler üzerinde lzo kullanmak gözle görülür bir etki sağlar; toplam çalışma süresi açısından zbackup, kopya/duplicati'ye yaklaşır, ancak librsync'e dayalı olanların 2-5 kat gerisinde kalır.
Avantajları açıktır; yedekleme depolama sunucusunda disk alanından tasarruf edilmesi. Depo kontrol araçlarına gelince, zbackup'ın yazarı bunları sağlamaz; hataya dayanıklı bir disk dizisi veya bulut sağlayıcı kullanılması önerilir.
Projenin yaklaşık 3 yıldır beklemede olmasına rağmen genel olarak çok iyi bir izlenim (son özellik talebi yaklaşık bir yıl önceydi ancak herhangi bir yanıt alınamadı).
Borgbackup'ı test etme
Borgbackup, zbackup'a benzer başka bir sistem olan çatı katının bir çatalıdır. Python ile yazılmış olup zbackup'a benzer bir yetenek listesine sahiptir, ancak ayrıca şunları da yapabilir:
- Yedeklemeleri sigorta aracılığıyla bağlayın
- Depo içeriğini kontrol edin
- İstemci-sunucu modunda çalışın
- Veriler için çeşitli sıkıştırıcıların yanı sıra, sıkıştırırken dosya türünün sezgisel olarak belirlenmesini kullanın.
- 2 şifreleme seçeneği, aes ve blake
- İçin yerleşik araç
performans kontrolleri
borgbackup kıyaslama crud ssh://backup_server/repo/path local_dir
Sonuçlar aşağıdaki gibiydi:
CZ-BIG 96.51 MB/sn (10 100.00 MB tamamı sıfır dosyalar: 10.36s)
RZ-BIG 57.22 MB/sn (10 100.00 MB tamamı sıfır dosyalar: 17.48s)
UZ-BIG 253.63 MB/sn (10 100.00 MB tamamı sıfır dosyalar: 3.94s)
DZ-BIG 351.06 MB/sn (10 100.00 MB tamamı sıfır dosyalar: 2.85s)
CR-BIG 34.30 MB/sn (10 100.00 MB rastgele dosyalar: 29.15s)
RR-BÜYÜK 60.69 MB/sn (10 100.00 MB rastgele dosyalar: 16.48s)
UR-BÜYÜK 311.06 MB/sn (10 100.00 MB rastgele dosyalar: 3.21s)
DR-BIG 72.63 MB/sn (10 100.00 MB rastgele dosyalar: 13.77s)
CZ-ORTA 108.59 MB/sn (1000 1.00 MB tamamı sıfır dosyalar: 9.21s)
RZ-ORTA 76.16 MB/sn (1000 1.00 MB tamamı sıfır dosyalar: 13.13s)
UZ-ORTA 331.27 MB/s (1000 1.00 MB tamamı sıfır dosyalar: 3.02s)
DZ-ORTA 387.36 MB/s (1000 1.00 MB tamamı sıfır dosyalar: 2.58s)
CR-ORTA 37.80 MB/sn (1000 1.00 MB rastgele dosyalar: 26.45s)
RR-ORTA 68.90 MB/sn (1000 1.00 MB rastgele dosyalar: 14.51s)
UR-ORTA 347.24 MB/sn (1000 1.00 MB rastgele dosyalar: 2.88s)
DR-ORTA 48.80 MB/sn (1000 1.00 MB rastgele dosyalar: 20.49s)
CZ-KÜÇÜK 11.72 MB/sn (10000 10.00 kB tamamı sıfır dosyalar: 8.53s)
RZ-KÜÇÜK 32.57 MB/sn (10000 10.00 kB tamamı sıfır dosyalar: 3.07s)
UZ-KÜÇÜK 19.37 MB/s (10000 10.00 kB tamamı sıfır dosyalar: 5.16s)
DZ-KÜÇÜK 33.71 MB/sn (10000 10.00 kB tamamı sıfır dosyalar: 2.97s)
CR-KÜÇÜK 6.85 MB/sn (10000 10.00 kB rastgele dosyalar: 14.60s)
RR-KÜÇÜK 31.27 MB/sn (10000 10.00 kB rastgele dosyalar: 3.20s)
UR-KÜÇÜK 12.28 MB/sn (10000 10.00 kB rastgele dosyalar: 8.14s)
DR-KÜÇÜK 18.78 MB/sn (10000 10.00 kB rastgele dosyalar: 5.32s)
Test sırasında dosya türünü belirlemek için sıkıştırma buluşsal yöntemi kullanılacaktır (otomatik sıkıştırma) ve sonuçlar aşağıdaki gibi olacaktır:
Öncelikle şifreleme olmadan nasıl çalıştığını kontrol edelim:
Saatleri:
1'i başlat
2'i başlat
3'i başlat
4m6s
4m10s
4m5s
56s
58s
54s
1m26s
1m34s
1m30s
Depo yetkilendirmesini etkinleştirirseniz (kimlik doğrulamalı mod), sonuçlar birbirine yakın olacaktır:
Saatleri:
1'i başlat
2'i başlat
3'i başlat
4m11s
4m20s
4m12s
1m0s
1m3s
1m2s
1m30s
1m34s
1m31s
Aes şifreleme etkinleştirildiğinde sonuçlar pek bozulmadı:
1'i başlat
2'i başlat
3'i başlat
4m55s
5m2s
4m58s
1m0s
1m2s
1m0s
1m49s
1m50s
1m50s
Aes'i Blake olarak değiştirirseniz durum tamamen düzelecektir:
Saatleri:
1'i başlat
2'i başlat
3'i başlat
4m33s
4m43s
4m40s
59s
1m0s
1m0s
1m38s
1m43s
1m40s
Zbackup örneğinde olduğu gibi, depo boyutu 13GB ve hatta biraz daha azdı ki bu da genel olarak bekleniyor. Çalışma süresinden çok memnun kaldım; çok daha geniş yetenekler sağlayan librsync tabanlı çözümlerle karşılaştırılabilir. Ayrıca, borgbackup'ı otomatik modda kullanırken çok ciddi bir avantaj sağlayan, ortam değişkenleri aracılığıyla çeşitli parametreleri ayarlama yeteneğinden de memnun kaldım. Yedekleme sırasındaki yükten de memnun kaldım: işlemci yüküne bakılırsa borgbackup 1 iş parçacığında çalışıyor.
Kullanırken özel bir dezavantaj yoktu.
restik test
Restic'in oldukça yeni bir çözüm olmasına rağmen (ilk 2 aday 2013 ve daha eski yıllarda biliniyordu), oldukça iyi özelliklere sahip. Go'da yazılmıştır.
Zbackup ile karşılaştırıldığında ayrıca şunları sağlar:
- Deponun bütünlüğünün kontrol edilmesi (parçaların kontrol edilmesi dahil).
- Yedeklemeleri depolamak için desteklenen çok sayıda protokol ve sağlayıcının yanı sıra bulut çözümleri için rclone - rsync desteği.
- 2 yedeklemenin birbiriyle karşılaştırılması.
- Deponun sigorta aracılığıyla montajı.
Genel olarak, özellikler listesi borgbackup'a oldukça yakındır, bazı yerlerde daha fazla, diğerlerinde daha az. Özelliklerinden biri, şifrelemeyi devre dışı bırakmanın bir yolu olmaması ve bu nedenle yedek kopyaların her zaman şifrelenmesidir. Pratikte bu yazılımdan nelerin çıkarılabileceğini görelim:
Sonuçlar aşağıdaki gibiydi:
Saatleri:
1'i başlat
2'i başlat
3'i başlat
5m25s
5m50s
5m38s
35s
38s
36s
1m54s
2m2s
1m58s
Performans sonuçları aynı zamanda rsync tabanlı çözümlerle karşılaştırılabilir ve genel olarak borgbackup'a çok yakındır, ancak CPU yükü daha yüksektir (birden fazla iş parçacığı çalışır) ve testere dişidir.
Büyük olasılıkla program, rsync'te olduğu gibi, veri depolama sunucusundaki disk alt sisteminin performansıyla sınırlıdır. Depo boyutu 13GB'tı, tıpkı zbackup veya borgbackup gibi, bu çözümü kullanırken bariz bir dezavantaj yoktu.
Bulgular
Aslında tüm adaylar benzer sonuçlara ulaştı ancak farklı fiyatlarda. Borgbackup en iyi performansı sergiledi, restic biraz daha yavaştı, zbackup muhtemelen kullanmaya başlamaya değmez,
ve eğer zaten kullanılıyorsa, onu borgbackup veya restic olarak değiştirmeyi deneyin.
Bulgular
En umut verici çözüm tutucu gibi görünüyor, çünkü... Yeteneklerin çalışma hızına göre en iyi oranına sahip olan odur, ancak şimdilik genel sonuçlara varmak için acele etmeyelim.
Borgbackup temelde daha kötü değil, ancak zbackup'ın değiştirilmesi muhtemelen daha iyi. Doğru, 3-2-1 kuralının işe yaradığından emin olmak için zbackup hala kullanılabilir. Örneğin (lib)rsync tabanlı yedekleme olanaklarına ek olarak.
Duyuru
Yedekleme Bölüm 5: Linux için bacula ve Veeam yedeklemesini test etme
Yedekleme Bölüm 6: Yedekleme Araçlarını Karşılaştırma
Yedekleme Bölüm 7: Sonuçlar
Tarafından gönderildi: Pavel Demkoviç
Kaynak: habr.com