Bu qeyd ehtiyat nüsxə serverində arxiv yaratmaqla ehtiyat nüsxələri həyata keçirən ehtiyat nüsxə alətlərindən bəhs edir.
Tələblərə cavab verənlər arasında dublicity (deja dup şəklində gözəl interfeysə malikdir) və duplicati var.
Digər çox diqqətəlayiq ehtiyat nüsxə aləti dardır, lakin onun çox geniş seçim siyahısına malik olduğu üçün - sınaq metodologiyası bacardıqlarının ancaq 10%-ni əhatə edir - biz onu cari dövrün bir hissəsi kimi sınaqdan keçirmirik.
Gözlənilən nəticələr
Hər iki namizəd bu və ya digər şəkildə arxiv yaratdığından, adi tar bələdçi kimi istifadə edilə bilər.
Bundan əlavə, biz faylların tam surəti ilə cari vəziyyəti və ya əvvəlki və cari arxivlər arasında (artan, azalan və s.) .
Ehtiyat nüsxələri yaratarkən davranış:
- Ehtiyat saxlama serverində nisbətən az sayda fayl (yedək nüsxələrin sayı və ya GB-da məlumatların ölçüsü ilə müqayisə edilə bilər), lakin onların ölçüsü kifayət qədər böyükdür (onlarla yüzlərlə meqabayt).
- Repozitorun ölçüsü yalnız dəyişiklikləri əhatə edəcək - heç bir dublikat saxlanmayacaq, ona görə də deponun ölçüsü rsync əsaslı proqram təminatı ilə müqayisədə daha kiçik olacaq.
- Sıxılma və/və ya şifrələmədən istifadə edərkən CPU-nun ağır yüklənməsini və arxivləşdirmə və/və ya şifrələmə prosesi ehtiyat saxlama serverində işləyirsə, çox güman ki, kifayət qədər yüksək şəbəkə və disk yükünü gözləyin.
İstinad dəyəri olaraq aşağıdakı əmri yerinə yetirək:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"İcra nəticələri aşağıdakı kimi oldu:
İcra müddəti 3m12s. Sürətin nümunədə olduğu kimi ehtiyat saxlama serverinin disk alt sistemi ilə məhdudlaşdığını görmək olar. . Bir az daha sürətli, çünki... qeyd bir fayla gedir.
Həmçinin, sıxılmanı qiymətləndirmək üçün eyni seçimi işə salaq, lakin ehtiyat server tərəfində sıxılmanı aktivləşdirək:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"Nəticələr bunlardır:
İcra müddəti 10m11s. Çox güman ki, darboğaz qəbuledici tərəfdəki tək axınlı kompressordur.
Eyni əmr, lakin sıxılma ilə serverə ötürülən orijinal məlumatlarla birlikdə darboğazın tək yivli bir kompressor olduğu fərziyyəsini yoxlamaq üçün.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"Belə çıxdı:
İcra müddəti 9m37s idi. Kompressor tərəfindən bir nüvəyə yük aydın görünür, çünki Şəbəkə ötürmə sürəti və mənbə disk alt sistemindəki yük oxşardır.
Şifrələməni qiymətləndirmək üçün əlavə bir əmr bağlayaraq openssl və ya gpg istifadə edə bilərsiniz openssl və ya gpg boruda. İstinad üçün belə bir əmr olacaq:
cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"Nəticələr belə çıxdı:
Qəbul edən tərəfdə 10 proses işlədiyi üçün icra müddəti 30m2s oldu - darboğaz yenə tək yivli kompressor, üstəlik kiçik şifrələmə yüküdür.
UPS: Bliznezz tələbi ilə mən pigz ilə testlər əlavə edirəm. Yalnız kompressordan istifadə etsəniz, 6m30s, şifrələmə də əlavə etsəniz, təxminən 7m olacaq. Aşağıdakı diaqramdakı eniş təmizlənməmiş disk keşidir:
Dublikat testi
Duplicity, tar formatında şifrələnmiş arxivlər yaratmaqla ehtiyat nüsxə üçün nəzərdə tutulmuş python proqramıdır.
Artan arxivlər üçün librsync istifadə olunur, buna görə də təsvir olunan davranışı gözləmək olar .
Yedəkləmələr gnupg istifadə edərək şifrələnə və imzalana bilər, bu, ehtiyat nüsxələri saxlamaq üçün müxtəlif provayderlərdən (s3, backblaze, gdrive və s.) istifadə edərkən vacibdir.
Nəticələrin nə olacağını görək:
Şifrələmə olmadan işləyərkən əldə etdiyimiz nəticələr bunlardır
spoyler
Hər testin işləmə müddəti:
1-i işə salın
2-i işə salın
3-i işə salın
16m33s
17m20s
16m30s
8m29s
9m3s
8m45s
5m21s
6m04s
5m53s
2048 bit açar ölçüsü ilə gnupg şifrələməsi aktivləşdirildikdə nəticələr bunlardı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
17m22s
17m32s
17m28s
8m52s
9m13s
9m3s
5m48s
5m40s
5m30s
Blokun ölçüsü göstərildi - 512 meqabayt, qrafiklərdə aydın görünür; Prosessor yükü əslində 50% səviyyəsində qaldı, yəni proqram birdən çox prosessor nüvəsindən istifadə etmir.
Proqramın işləmə prinsipi də olduqca aydın görünür: onlar bir məlumat parçası götürdülər, sıxdılar və olduqca yavaş ola biləcək ehtiyat saxlama serverinə göndərdilər.
Başqa bir xüsusiyyət, proqramın proqnozlaşdırıla bilən işləmə müddətidir, bu, yalnız dəyişdirilmiş məlumatların ölçüsündən asılıdır.
Şifrələmənin aktivləşdirilməsi proqramın işləmə müddətini əhəmiyyətli dərəcədə artırmadı, lakin prosessor yükünü təxminən 10% artırdı ki, bu da olduqca gözəl bonus ola bilər.
Təəssüf ki, bu proqram kataloqun adının dəyişdirilməsi ilə bağlı vəziyyəti düzgün aşkar edə bilmədi və nəticədə repozitorun ölçüsü dəyişikliklərin ölçüsünə (yəni, hamısı 18 GB) bərabər oldu, lakin ehtiyat nüsxə üçün etibarsız serverdən istifadə etmək imkanı aydın oldu. bu davranışı əhatə edir.
Dublikat testi
Bu proqram C# dilində yazılmışdır və Mono-dan bir sıra kitabxanalardan istifadə etməklə işləyir. GUI və CLI versiyası var.
Əsas xüsusiyyətlərin təxmini siyahısı müxtəlif ehtiyat saxlama provayderləri də daxil olmaqla ikiliyə bənzəyir, lakin ikilikdən fərqli olaraq, əksər xüsusiyyətlər üçüncü tərəf alətləri olmadan mövcuddur. Bunun müsbət və ya mənfi olması konkret vəziyyətdən asılıdır, lakin yeni başlayanlar üçün python üçün əlavə paketlər quraşdırmaqdansa, bütün xüsusiyyətlərin siyahısını bir anda onların qarşısında saxlamaq daha asandır. ikitərəfli iş.
Başqa bir kiçik nüans - proqram ehtiyat nüsxəsini işə salan istifadəçi adından aktiv olaraq yerli sqlite verilənlər bazası yazır, ona görə də cli-dən istifadə etməklə hər dəfə prosesə başlayanda əlavə olaraq tələb olunan verilənlər bazasının düzgün göstərilməsini təmin etməlisiniz. GUI və ya WEBGUI ilə işləyərkən, təfərrüatlar istifadəçidən gizlənəcək.
Bu həllin hansı göstəriciləri yarada biləcəyinə baxaq:
Şifrələməni söndürsəniz (və WEBGUI bunu etməyi tövsiyə etmir), nəticələr aşağıdakı kimidir:
Saat:
1-i işə salın
2-i işə salın
3-i işə salın
20m43s
20m13s
20m28s
5m21s
5m40s
5m35s
7m36s
7m54s
7m49s
Şifrələmə aktiv olduqda, aes istifadə edərək, belə görünür:
Saat:
1-i işə salın
2-i işə salın
3-i işə salın
29m9s
30m1s
29m54s
5m29s
6m2s
5m54s
8m44s
9m12s
9m1s
Xarici proqram gnupg istifadə etsəniz, aşağıdakı nəticələr çıxır:
1-i işə salın
2-i işə salın
3-i işə salın
26m6s
26m35s
26m17s
5m20s
5m48s
5m40s
8m12s
8m42s
8m15s
Gördüyünüz kimi, proqram bir neçə mövzuda işləyə bilər, lakin bu, onu daha məhsuldar bir həll etmir və şifrələmə işini müqayisə etsəniz, xarici proqramı işə salır.
Mono dəstindəki kitabxanadan istifadə etməkdən daha sürətli olduğu ortaya çıxdı. Bu, xarici proqramın daha optimallaşdırılması ilə bağlı ola bilər.
Başqa bir gözəl şey, repozitoriyanın ölçüsünün faktiki dəyişdirilmiş məlumatlar qədər götürməsi idi, yəni. duplicati bir kataloq adının dəyişdirilməsini aşkar etdi və bu vəziyyəti düzgün idarə etdi. Bunu ikinci sınaqdan keçirərkən görmək olar.
Ümumiyyətlə, proqramın kifayət qədər müsbət təəssüratları, o cümlədən yeni başlayanlar üçün kifayət qədər dostluq.
Tapıntılar
Hər iki namizəd kifayət qədər ləng işləyirdi, lakin ümumiyyətlə, adi tarla müqayisədə ən azı dublikatlarla irəliləyiş var. Belə bir irəliləyişin qiyməti də aydındır - nəzərə çarpan bir yük
prosessor. Ümumiyyətlə, nəticələrin proqnozlaşdırılmasında heç bir xüsusi sapma yoxdur.
Tapıntılar
Heç bir yerə tələsmək lazım deyilsə, həmçinin ehtiyat prosessorunuz varsa, nəzərdən keçirilən həllərdən hər hansı biri kömək edəcək, hər halda, tarın üstünə sarğı skriptləri yazmaqla təkrarlanmamalı olan kifayət qədər iş görülmüşdür. . Ehtiyat nüsxələri saxlamaq üçün serverə tam etibar etmək mümkün olmadıqda şifrələmənin olması çox zəruri bir xüsusiyyətdir.
Əsaslı həllər ilə müqayisədə - təmiz formada tar rsync-dən 20-30% daha sürətli işləməsinə baxmayaraq, performans bir neçə dəfə pis ola bilər.
Anbarın ölçüsünə qənaət var, ancaq dublikatlarla.
Duyurular
Yedəkləmə Hissəsi 3: Təkrarlanma, dublikat, deja dup-in nəzərdən keçirilməsi və sınaqdan keçirilməsi
Yedəkləmə Hissəsi 4: zbackup, restic, borgbackup-ın nəzərdən keçirilməsi və sınaqdan keçirilməsi
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