Bu məqalədə məlumat axınını ayrı-ayrı komponentlərə (parçalara) bölərək, bir anbar təşkil edən ehtiyat nüsxə üçün proqram vasitələri müzakirə olunacaq.
Repozitor komponentləri əlavə olaraq sıxışdırıla və şifrələnə bilər və ən əsası təkrar ehtiyat nüsxələmə prosesləri zamanı onlar təkrar istifadə edilə bilər.
Belə bir depoda ehtiyat nüsxə, məsələn, müxtəlif hash funksiyalarına əsaslanan bir-biri ilə əlaqəli komponentlərin adlandırılmış zənciridir.
Bir neçə oxşar həll yolu var, mən 3-ə diqqət yetirəcəyəm: zbackup, borgbackup və restic.
Gözlənilən nəticələr
Bütün müraciət edənlər bu və ya digər şəkildə repozitoriyanın yaradılmasını tələb etdiyindən, ən vacib amillərdən biri deponun ölçüsü olacaqdır. İdeal olaraq, onun ölçüsü qəbul edilmiş metodologiyaya görə 13 GB-dan çox olmamalıdır və ya daha az olmalıdır - yaxşı optimallaşdırma şərti ilə.
Tar kimi arxivçilərdən istifadə etmədən faylların ehtiyat nüsxəsini çıxara bilmək, həmçinin rsync və sshfs kimi əlavə alətlər olmadan ssh/sftp ilə işləmək də çox arzuolunandır.
Ehtiyat nüsxələri yaratarkən davranış:
- Repozitoriyanın ölçüsü dəyişikliklərin ölçüsünə bərabər və ya daha az olacaq.
- Sıxılma və/və ya şifrələmədən istifadə edərkən yüksək CPU istifadəsi gözlənilir və arxivləşdirmə və/yaxud şifrələmə prosesi ehtiyat saxlama serverində işləyərsə, kifayət qədər ağır şəbəkə və disk alt sistemi yüklənməsi ehtimal olunur.
- Repozitoriya zədələnibsə, həm yeni ehtiyat nüsxələri yaratarkən, həm də bərpa etməyə çalışarkən gecikmiş xəta ola bilər. Anbarın bütövlüyünü təmin etmək üçün əlavə tədbirlər planlamalısınız və ya daxili bütövlüyü yoxlamalarından istifadə etməlisiniz.
Tarla işləmək əvvəlki məqalələrdən birində göstərildiyi kimi istinad dəyəri kimi qəbul edilir.
Zbackup sınaqdan keçirilir
Zbackup əməliyyatının ümumi mexanizmi proqramın daxil olan məlumat axınında eyni məlumatları ehtiva edən sahələri tapması, sonra isteğe bağlı olaraq onları sıxışdırması və şifrələməsi, hər bir sahəni cəmi 1 dəfə qənaət etməsidir.
Təkmilləşdirmə üçün 64-bitlik sürüşmə pəncərə hash ring funksiyası artıq mövcud məlumat blokları ilə uyğunluğu bayt-bayt yoxlamaq üçün istifadə olunur (onun rsync-də necə həyata keçirildiyinə bənzər).
Sıxılma üçün lzma və lzo çox yivli icrada, şifrələmə üçün isə aes istifadə olunur. Ən son versiyalarda gələcəkdə köhnə məlumatları depodan silmək mümkündür.
Proqram minimum asılılıqlarla C++ dilində yazılmışdır. Müəllif, görünür, unix-way-dən ilhamlanıb, ona görə də proqram ehtiyat nüsxələri yaratarkən stdin-də məlumatları alır, bərpa edərkən stdout-a oxşar məlumat axını verir. Beləliklə, öz ehtiyat həllərinizi yazarkən zbackup çox yaxşı bir "kərpic" kimi istifadə edilə bilər. Məsələn, məqalənin müəllifi üçün bu proqram təxminən 2014-cü ildən ev maşınları üçün əsas ehtiyat alət olmuşdur.
Başqa cür qeyd edilmədiyi halda, normal tar məlumat axını kimi istifadə olunacaq.
Nəticələrin nə olacağını görək:
İş 2 versiyada yoxlanılıb:
- repozitoriya yaradılır və orijinal verilənlərlə serverdə zbackup işə salınır, sonra deponun məzmunu ehtiyat saxlama serverinə ötürülür.
- ehtiyat saxlama serverində repozitoriya yaradılır, ehtiyat saxlama serverində ssh vasitəsilə zbackup işə salınır, ona boru vasitəsilə məlumatlar verilir.
Birinci variantın nəticələri aşağıdakı kimi idi: 43m11s - şifrələnməmiş depo və lzma kompressorundan istifadə edərkən, 19m13s - kompressoru lzo ilə əvəz edərkən.
İlkin məlumatlarla serverə yükləmə aşağıdakı kimi idi (lzma ilə bir nümunə göstərilir, lzo ilə təxminən eyni şəkil idi, lakin rsync-in payı vaxtın dörddə birinə bərabər idi):
Aydındır ki, belə bir ehtiyat nüsxə prosesi yalnız nisbətən nadir və kiçik dəyişikliklər üçün uyğundur. Zbackup-ın işini 1 iplə məhdudlaşdırmaq da çox arzuolunandır, əks halda çox yüksək CPU yükü olacaq, çünki. Proqram bir neçə mövzuda işləməyi çox yaxşı bacarır. Diskdəki yük kiçik idi, ümumiyyətlə ssd-yə əsaslanan müasir disk alt sistemi ilə nəzərə çarpmayacaqdır. Repozitor məlumatlarının uzaq bir serverə sinxronizasiya prosesinin başlanğıcını da aydın görə bilərsiniz, iş sürəti adi rsync ilə müqayisə edilə bilər və ehtiyat saxlama serverinin disk alt sisteminin işinə əsaslanır. Bu yanaşmanın dezavantajı yerli repozitoriyanın saxlanması və nəticədə məlumatların təkrarlanmasıdır.
Daha maraqlı və praktikada tətbiq oluna bilən ikinci seçimdir ki, zbackup-ı dərhal ehtiyat saxlama serverində işə salır.
Başlamaq üçün, iş lzma kompressoru ilə şifrələmədən istifadə etmədən yoxlanılacaq:
Hər testin işləmə müddəti:
1-i işə salın
2-i işə salın
3-i işə salın
39m45s
40m20s
40m3s
7m36s
8m3s
7m48s
15m35s
15m48s
15m38s
Aes istifadə edərək şifrələməni aktivləşdirsəniz, nəticələr olduqca yaxındır:
Şifrələmə ilə eyni verilənlər üzərində işləmə vaxtı:
1-i işə salın
2-i işə salın
3-i işə salın
43m40s
44m12s
44m3s
8m3s
8m15s
8m12s
15m0s
15m40s
15m25s
Şifrələmə lzo-da sıxılma ilə birləşdirilərsə, belə çıxır:
Saat:
1-i işə salın
2-i işə salın
3-i işə salın
18m2s
18m15s
18m12s
5m13s
5m24s
5m20s
8m48s
9m3s
8m51s
Nəticə deponun ölçüsü 13 GB-da nisbətən eyni idi. Bu o deməkdir ki, təkmilləşdirmə düzgün işləyir. Bundan əlavə, artıq sıxılmış məlumatlarda lzo-nun istifadəsi nəzərəçarpacaq təsir göstərir, ümumi işləmə müddəti baxımından zbackup ikiqat / dublikatlara çox yaxındır, lakin librsync-ə əsaslananlardan 2-5 dəfə geri qalır.
Faydaları göz qabağındadır - ehtiyat saxlama serverində disk sahəsinə qənaət. Repozitor yoxlama vasitələrinə gəldikdə, onlar zbackup müəllifi tərəfindən təmin edilmir, nasazlığa dözümlü disk massivi və ya bulud provayderindən istifadə etmək tövsiyə olunur.
Ümumiyyətlə, layihənin təxminən 3 ildir ki, dayanmasına baxmayaraq, çox yaxşı təəssürat (son xüsusiyyət sorğusu təxminən bir il əvvəl olub, lakin cavabsız).
borgbackup testi
Borgbackup çardaq çəngəlidir, zbackup-a bənzər başqa bir sistemdir. Pythonda yazılmış, zbackup-a bənzər funksiyaların siyahısı var, lakin əlavə olaraq:
- Qoruyucu ilə ehtiyat nüsxələri quraşdırın
- Anbarın məzmununu yoxlayın
- Müştəri-server rejimində işləmək
- Məlumat üçün müxtəlif kompressorlardan istifadə edin, həmçinin onu sıxarkən fayl növünün evristik təyini.
- 2 şifrələmə seçimi, aes və blake
- üçün quraşdırılmış alət
performans yoxlamaları
borgbackup benchmark crud ssh://backup_server/repo/path local_dir
Nəticələr belə çıxdı:
CZ-BIG 96.51 MB/s (10 100.00 MB tam sıfır fayl: 10.36s)
RZ-BIG 57.22 MB/s (10 100.00 MB tam sıfır fayl: 17.48s)
UZ-BIG 253.63 MB/s (10 100.00 MB tam sıfır fayl: 3.94s)
DZ-BIG 351.06 MB/s (10 100.00 MB tam sıfır fayl: 2.85s)
CR-BIG 34.30 MB/s (10 100.00 MB təsadüfi fayllar: 29.15s)
RR-BIG 60.69 MB/s (10 100.00 MB təsadüfi fayllar: 16.48s)
UR-BIG 311.06 MB/s (10 100.00 MB təsadüfi fayllar: 3.21s)
DR-BIG 72.63 MB/s (10 100.00 MB təsadüfi fayllar: 13.77s)
CZ-ORTA 108.59 MB/s (1000 1.00 MB tam sıfır fayl: 9.21s)
RZ-ORTA 76.16 MB/s (1000 1.00 MB tam sıfır fayl: 13.13s)
UZ-MEDIUM 331.27 MB/s (1000 1.00 MB tam sıfır fayl: 3.02s)
DZ-MEDIUM 387.36 MB/s (1000 1.00 MB tam sıfır fayl: 2.58s)
CR-ORTA 37.80 MB/s (1000 1.00 MB təsadüfi fayllar: 26.45s)
RR-ORTA 68.90 MB/s (1000 1.00 MB təsadüfi fayllar: 14.51s)
UR-ORTA 347.24 MB/s (1000 1.00 MB təsadüfi fayllar: 2.88s)
DR-MEDIUM 48.80 MB/s (1000 1.00 MB təsadüfi fayllar: 20.49s)
CZ-SMALL 11.72 MB/s (10000 10.00 kB tam sıfır fayl: 8.53s)
RZ-SMALL 32.57 MB/s (10000 10.00 kB tam sıfır fayl: 3.07s)
UZ-SMALL 19.37 MB/s (10000 10.00 kB tam sıfır fayl: 5.16s)
DZ-SMALL 33.71 MB/s (10000 10.00 kB tam sıfır fayl: 2.97s)
CR-SMALL 6.85 MB/s (10000 10.00 kB təsadüfi fayllar: 14.60s)
RR-KIÇIK 31.27 MB/s (10000 10.00 kB təsadüfi fayllar: 3.20s)
UR-KIÇIK 12.28 MB/s (10000 10.00 kB təsadüfi fayllar: 8.14s)
DR-SMALL 18.78 MB/s (10000 10.00 kB təsadüfi fayllar: 5.32s)
Sınaq zamanı fayl növünün tərifi ilə (avtomatik sıxılma) sıxılma zamanı evristikadan istifadə olunacaq və nəticələr aşağıdakı kimi olacaq:
Əvvəlcə işi şifrələmədən yoxlayaq:
Saat:
1-i işə salın
2-i işə salın
3-i işə salın
4m6s
4m10s
4m5s
56s
58s
54s
1m26s
1m34s
1m30s
Depozit avtorizasiyasını aktivləşdirsəniz (autentifikasiya rejimi), nəticələr yaxın olacaq:
Saat:
1-i işə salın
2-i işə salın
3-i işə salın
4m11s
4m20s
4m12s
1m0s
1m3s
1m2s
1m30s
1m34s
1m31s
Aes şifrələməsini aktivləşdirərkən nəticələr çox pisləşmədi:
1-i işə salın
2-i işə salın
3-i işə salın
4m55s
5m2s
4m58s
1m0s
1m2s
1m0s
1m49s
1m50s
1m50s
Əgər aes-i blake-ə dəyişdirsəniz, vəziyyət tamamilə yaxşılaşacaq:
Saat:
1-i işə salın
2-i işə salın
3-i işə salın
4m33s
4m43s
4m40s
59s
1m0s
1m0s
1m38s
1m43s
1m40s
Zbackup vəziyyətində olduğu kimi, deponun ölçüsü 13GB və hətta bir qədər az idi, bu, ümumiyyətlə, gözlənilir. İş vaxtından çox razı qaldım, o, librsync-ə əsaslanan həllərlə müqayisə oluna bilər, daha çox imkanlar təqdim edir. Avtomatik rejimdə borgbackup-dan istifadə edərkən çox ciddi üstünlük verən mühit dəyişənləri vasitəsilə müxtəlif parametrləri təyin etmək imkanı məni də qane etdi. Yedəkləmə zamanı yükdən də razı qaldım: prosessor yükünə görə, borgbackup 1 ipdə işləyir.
İstifadə edərkən xüsusi mənfi cəhətləri yox idi.
istirahət testi
Resticin kifayət qədər yeni bir həll olmasına baxmayaraq (ilk 2 namizəd 2013-cü ildən bəri məlumdur və daha yaşlı), kifayət qədər yaxşı xüsusiyyətlərə malikdir. Go-da yazılmışdır.
Zbackup ilə müqayisədə o, əlavə olaraq verir:
- Anbarın bütövlüyünün yoxlanılması (hissələrin yoxlanılması daxil olmaqla).
- Ehtiyat nüsxələrin saxlanması üçün dəstəklənən protokolların və provayderlərin böyük siyahısı, həmçinin bulud həlləri üçün rclone - rsync dəstəyi.
- 2 ehtiyat nüsxənin bir-biri ilə müqayisəsi.
- Sigorta ilə bir deponun quraşdırılması.
Ümumiyyətlə, funksiyaların siyahısı borgbackup-a olduqca yaxındır, bəzən daha çox, bəzən daha azdır. Xüsusiyyətlərdən - şifrələməni söndürmək mümkün deyil və buna görə də ehtiyat nüsxələri həmişə şifrələnəcəkdir. Bu proqramdan nəyin sıxışdırıla biləcəyini praktikada görək:
Nəticələr aşağıdakı kimidir:
Saat:
1-i işə salın
2-i işə salın
3-i işə salın
5m25s
5m50s
5m38s
35s
38s
36s
1m54s
2m2s
1m58s
Nəticələr həmçinin rsync əsaslı həllər ilə müqayisə edilə bilər və ümumiyyətlə, borgbackup-a çox yaxındır, lakin prosessor yükü daha yüksəkdir (birdən çox ip işləyir) və mişar dişi.
Çox güman ki, proqram rsync-də olduğu kimi saxlama serverindəki disk alt sisteminin işinə əsaslanır. Repozitoriyanın ölçüsü zbackup və ya borgbackup kimi 13 GB idi, bu həlldən istifadə edərkən heç bir açıq çatışmazlıq yox idi.
Tapıntılar
Əslində, bütün namizədlər oxşar nəticələr əldə etdilər, lakin fərqli qiymətlərlə. borgbackup ən yaxşı olduğunu sübut etdi, bir az yavaş - restic, zbackup, yəqin ki, istifadə etməyə başlamamalısınız,
və əgər o, artıq istifadədədirsə, onu borgbackup və ya restica dəyişdirməyə çalışın.
Tapıntılar
Restic ən perspektivli həll kimi görünür, çünki qabiliyyətlərin sürətə ən yaxşı nisbəti olan odur, lakin hələlik ümumi nəticələrə tələsməyəcəyik.
Borgbackup prinsipcə daha pis deyil, lakin zbackup əvəz etmək daha yaxşıdır. Bununla belə, zbackup-ın 3-2-1 qaydası onun işləməsi üçün hələ də istifadə edilə bilər. Məsələn, (lib)rsync əsaslı ehtiyat alətlərinə əlavə olaraq.
Duyurular
Yedəkləmə Hissəsi 5: Linux üçün bacula və veeam ehtiyat nüsxəsinin sınaqdan keçirilməsi
Yedəkləmə Hissəsi 6: Yedəkləmə Alətlərinin Müqayisə edilməsi
Yedək Hissə 7: Nəticələr
Yazının müəllifi: Pavel Demkoviç
Mənbə: www.habr.com