Bu notta, bir yedekleme sunucusunda arşivler oluşturarak yedekleme gerçekleştiren yedekleme araçları anlatılmaktadır.
Gereksinimleri karşılayanlar arasında duplicity (deja dup şeklinde güzel bir arayüze sahip) ve duplicati yer alıyor.
Bir başka çok dikkat çekici yedekleme aracı da dardır, ancak çok kapsamlı bir seçenek listesine sahip olduğundan (test metodolojisi yapabileceklerinin ancak %10'unu kapsar) onu mevcut döngünün bir parçası olarak test etmiyoruz.
Beklenen Sonuçlar
Her iki aday da öyle ya da böyle arşiv oluşturduğu için normal tar rehber olarak kullanılabilir.
Ek olarak, yalnızca dosyaların tam kopyası ile mevcut durumu arasındaki veya önceki ve mevcut arşivler (artımlı, azalışlı vb.) arasındaki farkı içeren yedek kopyalar oluşturarak depolama sunucusundaki veri depolamanın ne kadar iyi optimize edildiğini değerlendireceğiz. .
Yedekleme oluştururken davranış:
- Yedekleme depolama sunucusunda nispeten az sayıda dosya bulunur (yedek kopya sayısıyla veya GB cinsinden veri boyutuyla karşılaştırılabilir), ancak boyutları oldukça büyüktür (onlarca ila yüzlerce megabayt).
- Depo boyutu yalnızca değişiklikleri içerecektir - hiçbir kopya saklanmayacaktır, dolayısıyla depo boyutu rsync tabanlı yazılıma göre daha küçük olacaktır.
- Sıkıştırma ve/veya şifreleme kullanırken ağır CPU yükü ve arşivleme ve/veya şifreleme işlemi bir yedek depolama sunucusunda çalışıyorsa muhtemelen oldukça yüksek ağ ve disk yükü beklenebilir.
Aşağıdaki komutu referans değeri olarak çalıştıralım:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"Uygulama sonuçları aşağıdaki gibidir:
Uygulama süresi 3 dakika 12 saniye. Örnekte olduğu gibi hızın, yedekleme depolama sunucusunun disk alt sistemi tarafından sınırlandığı görülebilir. . Sadece biraz daha hızlı, çünkü... kayıt tek bir dosyaya gider.
Ayrıca sıkıştırmayı değerlendirmek için aynı seçeneği çalıştıralım ancak yedekleme sunucusu tarafında sıkıştırmayı etkinleştirelim:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"Sonuçlar aşağıdaki gibidir:
Uygulama süresi 10 dakika 11 saniye. Büyük olasılıkla darboğaz, alıcı taraftaki tek akışlı kompresördür.
Aynı komut, ancak sıkıştırma ile orijinal verilerle birlikte sunucuya aktarılarak darboğazın tek iş parçacıklı bir kompresör olduğu hipotezini test eder.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"Şöyle ortaya çıktı:
Uygulama süresi 9 dakika 37 saniyeydi. Kompresörün bir çekirdek üzerindeki yükü açıkça görülebilir, çünkü Ağ aktarım hızı ve kaynak disk alt sistemindeki yük benzerdir.
Şifrelemeyi değerlendirmek için ek bir komut bağlayarak openssl veya gpg'yi kullanabilirsiniz. openssl veya gpg boru içinde. Referans olarak şöyle bir komut olacaktır:
cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"Sonuçlar şu şekilde çıktı:
Alıcı tarafta 10 işlem çalıştığından yürütme süresinin 30 dakika 2 saniye olduğu ortaya çıktı - darboğaz yine tek iş parçacıklı bir kompresör ve ayrıca küçük şifreleme yüküdür.
UPD: Bliznezz'in isteği üzerine pigz ile testler ekliyorum. Sadece kompresör kullanırsanız 6m30s, şifreleme de eklerseniz 7m civarında olur. Alt grafikteki düşüş, temizlenmemiş bir disk önbelleğidir:
Yinelenen test
Duplicity, tar formatında şifrelenmiş arşivler oluşturarak yedeklemeye yönelik bir python yazılımıdır.
Artımlı arşivler için librsync kullanılır, dolayısıyla burada açıklanan davranışı bekleyebilirsiniz. .
Yedeklemeler gnupg kullanılarak şifrelenebilir ve imzalanabilir; bu, yedeklemeleri depolamak için farklı sağlayıcılar (s3, backblaze, gdrive vb.) kullanıldığında önemlidir.
Bakalım sonuçlar ne olacak:
Şifreleme olmadan çalışırken elde ettiğimiz sonuçlar bunlar
bir şeyin önceden reklamı
Her test çalışmasının çalışma süresi:
1'i başlat
2'i başlat
3'i başlat
16m33s
17m20s
16m30s
8m29s
9m3s
8m45s
5m21s
6m04s
5m53s
Anahtar boyutu 2048 bit olan gnupg şifreleme etkinleştirildiğinde elde edilen sonuçlar şunlardır:
Aynı veriler üzerinde şifrelemeyle çalışma süresi:
1'i başlat
2'i başlat
3'i başlat
17m22s
17m32s
17m28s
8m52s
9m13s
9m3s
5m48s
5m40s
5m30s
Blok boyutu belirtildi - grafiklerde açıkça görülebilen 512 megabayt; İşlemci yükü aslında %50'de kaldı, bu da programın birden fazla işlemci çekirdeği kullanmadığı anlamına geliyor.
Programın çalışma prensibi de oldukça açık bir şekilde görülüyor: Bir parça veri aldılar, sıkıştırdılar ve oldukça yavaş olabilen bir yedekleme depolama sunucusuna gönderdiler.
Diğer bir özellik ise programın yalnızca değiştirilen verinin boyutuna bağlı olan öngörülebilir çalışma süresidir.
Şifrelemeyi etkinleştirmek programın çalışma süresini önemli ölçüde artırmadı ancak işlemci yükünü yaklaşık %10 artırdı, bu oldukça hoş bir bonus olabilir.
Ne yazık ki, bu program, dizinin yeniden adlandırılmasıyla ilgili durumu doğru bir şekilde algılayamadı ve ortaya çıkan depo boyutunun, değişikliklerin boyutuna eşit olduğu ortaya çıktı (yani, tamamı 18 GB), ancak yedekleme için güvenilmeyen bir sunucuyu kullanma yeteneği açıkça ortaya çıktı bu davranışı kapsar.
Yinelenen test
Bu yazılım C# ile yazılmıştır ve Mono'nun bir dizi kütüphanesini kullanarak çalışır. Bir GUI'nin yanı sıra bir CLI sürümü de var.
Ana özelliklerin yaklaşık listesi, çeşitli yedekleme depolama sağlayıcıları da dahil olmak üzere yinelemeye benzer, ancak yinelemenin aksine çoğu özellik, üçüncü taraf araçlar olmadan kullanılabilir. Bunun artı mı yoksa eksi mi olduğu özel duruma bağlıdır, ancak yeni başlayanlar için, Python için ek paketler yüklemek yerine tüm özelliklerin bir listesini aynı anda önlerinde bulundurmak büyük olasılıkla daha kolaydır. ikiyüzlülük durumu.
Başka bir küçük nüans - program, yedeklemeyi başlatan kullanıcı adına aktif olarak yerel bir sqlite veritabanı yazar, bu nedenle, işlem cli kullanılarak her başlatıldığında gerekli veritabanının doğru şekilde belirtildiğinden ek olarak emin olmanız gerekir. GUI veya WEBGUI üzerinden çalışırken ayrıntılar kullanıcıdan gizlenecektir.
Bu çözümün hangi göstergeleri üretebileceğini görelim:
Şifrelemeyi kapatırsanız (ve WEBGUI bunu yapmanızı önermez), sonuçlar aşağıdaki gibidir:
Saatleri:
1'i başlat
2'i başlat
3'i başlat
20m43s
20m13s
20m28s
5m21s
5m40s
5m35s
7m36s
7m54s
7m49s
Şifreleme etkinleştirildiğinde, aes kullanıldığında şöyle görünür:
Saatleri:
1'i başlat
2'i başlat
3'i başlat
29m9s
30m1s
29m54s
5m29s
6m2s
5m54s
8m44s
9m12s
9m1s
Ve gnupg harici programını kullanırsanız aşağıdaki sonuçlar ortaya çıkar:
1'i başlat
2'i başlat
3'i başlat
26m6s
26m35s
26m17s
5m20s
5m48s
5m40s
8m12s
8m42s
8m15s
Gördüğünüz gibi program birkaç iş parçacığında çalışabilir ancak bu onu daha verimli bir çözüm yapmaz ve şifreleme çalışmasını karşılaştırırsanız harici bir program başlatıyor
Mono setindeki kitaplığı kullanmaktan daha hızlı olduğu ortaya çıktı. Bunun nedeni harici programın daha optimize edilmiş olması olabilir.
Bir başka güzel şey de, havuzun boyutunun tam olarak değiştirilen gerçek veriler kadar almasıydı; duplicati bir dizinin yeniden adlandırıldığını tespit etti ve bu durumu doğru bir şekilde ele aldı. Bu, ikinci testi çalıştırırken görülebilir.
Genel olarak, programa ilişkin oldukça olumlu izlenimler var; buna yeni başlayanlar için oldukça arkadaş canlısı olması da dahil.
Bulgular
Her iki aday da oldukça yavaş çalıştı, ancak genel olarak normal tar ile karşılaştırıldığında, en azından kopyalarda ilerleme var. Böyle bir ilerlemenin bedeli de açıktır; gözle görülür bir yük
işlemci. Genel olarak sonuçların tahmin edilmesinde özel bir sapma yoktur.
Bulgular
Herhangi bir yere acele etmenize gerek yoksa ve ayrıca yedek bir işlemciniz varsa, dikkate alınan çözümlerden herhangi biri işinizi görecektir, her halükarda, katran üzerine sarma komut dosyaları yazarak tekrarlanmaması gereken çok fazla iş yapılmıştır. . Yedek kopyaların saklandığı sunucuya tam olarak güvenilemiyorsa, şifrelemenin varlığı çok gerekli bir özelliktir.
Çözüm bazlı ürünlerle karşılaştırıldığında - saf haliyle katranın rsync'ten% 20-30 daha hızlı çalışmasına rağmen performans birkaç kat daha kötü olabilir.
Deponun boyutunda tasarruf var, ancak yalnızca kopyalarla.
Duyuru
Yedekleme Bölüm 3: Yinelemeyi, yinelemeyi ve yinelemeyi inceleme ve test etme
Yedekleme Bölüm 4: zbackup, restic, borgbackup'ı gözden geçirme ve test etme
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