Bu məqalədə ehtiyat nüsxələrinin yaradılması vasitələrinin müqayisəsi aparılacaq, amma əvvəlcə onların ehtiyat nüsxələrindən məlumatların bərpasında necə sürətli və yaxşı işlədiklərini öyrənmək lazımdır.
Müqayisəni asanlaşdırmaq üçün tam ehtiyat nüsxəsindən bərpa məsələsi nəzərə alınacaq, çünki bu iş rejimini bütün namizədlər dəstəkləyir. Asanlıq olsun deyə, ədədlər artıq orta dəyərlər olaraq götürülüb (bir neçə icra üzrə arifmetik orta). Nəticələr cədvəldə toplanacaq ki, burada həm də imkanlar haqqında məlumatlar olacaq: veb-interfeys mövcudluğu, konfiqurasiya və işin asanlığı, avtomatlaşdırma qabiliyyəti, müxtəlif əlavə imkanların (məsələn, məlumatların bütövlüyünün yoxlanılması) olub-olmaması və s. Qrafiklər serverdə yükü göstərəcək ki, burada məlumatlar tətbiq ediləcək (beşlik ehtiyat nüsxələrinin saxlanıldığı server deyil).
Məlumatların bərpası
İstinad nöqtəsi olaraq rsync və tar istifadə ediləcək, çünki ehtiyat nüsxələrinin alınması üçün ən sadə ssenarilərin əsasını təşkil edir.
Rsync test məlumatlar dəstini 4 dəqiqə 28 saniyəyə uğurla başa çatdırdı, bu isə
belə bir yükün olmasını göstərdi.
Bərpa prosesi ehtiyat nüsxələri saxlayan serverin disk alt sisteminin məhdudiyyətinə rast gəldi (dişli qrafiklər). Ayrıca, bir prosessorun yükünün aydın şəkildə görünməsi (aşağı iowait və softirq — disk və şəbəkə ilə bağlı problemlər yoxdur). Digər iki proqram, yəni rdiff-backup və rsnapshot, rsync-ə əsaslandığı üçün və bərpa vasitəsi kimi adi rsync təqdim etdiyi üçün onların yük profili və ehtiyat nüsxəsinin bərpa müddəti buna bənzər olacaq.
Tar biraz daha sürətli işləyərək
2 dəqiqə 43 saniyəyə başa çatdı:
Sistemin tam yüklənməsi ortalama olaraq 20% daha yüksək idi, çünki softirq artmışdı — şəbəkə alt sistemindəki xərclər artmışdı.
Əgər arxiv əlavə sıxılarsa, bərpa müddəti 3 dəqiqə 19 saniyəyə yüksəlir və
əsas serverdə belə bir yük ilə (əsas serverin tərəfində açılma):
Açma prosesi hər iki prosessor nüvəsini işğal edir, çünki iki proses işləyir. Ümumilikdə — gözlənilən nəticədir. Həmçinin, gzip-i ehtiyat nüsxələri serverinin tərəfində işə salmaqla bənzər bir nəticə (3 dəqiqə 20 saniyə) əldə olundu, əsas serverdəki yük profili gzip sıxma olmadan tar-ı işə salmaqla çox bənzər oldu (əvvəlki qrafikə baxın).
İ rdiff-backup son yaradılmış ehtiyat nüsxəni adi rsync ilə sinxronizasiya etmək olar (nəticələr oxşar olacaq), amma daha köhnə ehtiyat nüsxələri hələ də rdiff-backup proqramı ilə bərpa edilməlidir, bu da 17 dəqiqə 17 saniyəyə bərpa etməyi mümkün etdi, belə bir yükü göstərərək:
Belə görünür ki, bu, məhz belə düşünülmüşdü, ən azından sürət məhdudiyyəti üçün müəlliflər
belə bir həll təklif edirlər. . Backup bərpa prosesinin özü bir nüvənin yarısından azını alır, disk və şəbəkə ilə rsync-də müvafiq müqayisəli performans (yəni 2-5 dəfə yavaş) nümayiş etdirir.
Rsnapshot bərpa üçün adi rsync istifadə etməyi tövsiyə edir, buna görə də onun nəticələri eyni olacaq. Ümumilikdə, belə oldu.
Burp bərpa vəzifəsini 7 dəqiqə 2 saniyəyə yerinə yetirdi
belə yük altında:
Kifayət qədər sürətli işləyirdi və ən azından təmiz rsync-dən daha rahatdır: heç bir bayrağı xatırlamağa ehtiyac yoxdur, sadə və intuitiv cli interfeysi, bir neçə nüsxənin daxili dəstəyi - amma iki dəfə daha yavaşdır. Əgər məlumat son edilmiş backup-dan bərpa edilməlidirsə - rsync-dən istifadə edə bilərsiniz, yalnız kiçik fikirlərlə.
Təxminən eyni sürəti və yükü proqram BackupPC rsync ötürmə rejimini aktiv etdikdə göstərdi, backup-ı açaraq
7 dəqiqə 42 saniyəyə:
Amma tar ilə məlumat ötürmə rejimində BackupPC daha yavaş oldu: 12 dəqiqə 15 saniyə, bu halda CPU yükü ümumiyyətlə daha aşağı oldu
1.5 dəfə:
Duplicity şifrələmə olmadan biraz daha yaxşı nəticələr göstərdi, backup-ı 10 dəqiqə 58 saniyəyə bərpa etdi. Gpg ilə şifrələməni aktivləşdirsəniz - bərpa vaxtı 15 dəqiqə 3 saniyəyə yüksəlir. Həmçinin, nüsxələrin saxlanması üçün repository yaradıldığında daxil olan məlumatların axında istifadəsi üçün arxiv ölçüsünü göstərə bilərsiniz. Ümumilikdə, adi sərt disklərdə, tək-nüvəli iş rejimi ilə əlaqədar, əhəmiyyətli bir fərq yoxdur. O, fərqli blok ölçüləri istifadə edildikdə hibrid anbarlar istifadə olunduqda meydana çıxacaq. Bərpa zamanı əsas serverdə yük belə idi:
şifrələmə olmadan
şifrələmə ilə
Duplicati bərpa sürətini müqayisəli şəkildə göstərdi, 13 dəqiqə 45 saniyəyə işini tamamlamağı bacardı. Yenidən bərpa olunmuş məlumatların düzgünlüyünü yoxlamaq üçün daha 5 dəqiqə vaxt sərf olundu (ümumilikdə təxminən 19 dəqiqə). Bu zaman aşkar yük
kifayət qədər yüksək idi:
Daxili vasitələrlə aes şifrələmə aktivləşdikdə, bərpa müddəti 21 dəqiqə 40 saniyəyə bərabər oldu, bu zaman CPU yükü maksimuma çatdı (hər iki nüvə!) bərpa zamanı; məlumatların yoxlanması zamanı yalnız bir iplik aktiv idi, bir nüvəni tutdu. Bərpa olunan məlumatların yoxlanılması 5 dəqiqə çəkdi (ümumilikdə demək olar ki, 27 dəqiqə).
Nəticə
Duplicati, gpg xarici proqramından şifrələmək üçün istifadə edildiyində bərpa işini biraz daha sürətlə tamamlayırdı, amma ümumilikdə əvvəlki rejimdən fərqlər minimaldır. İş vaxtı 16 dəqiqə 30 saniyə oldu, məlumatların yoxlanılması isə 6 dəqiqə çəkdi. Yük belə idi:
belə:
AMANDA, tar istifadə edərək, 2 dəqiqə 49 saniyəyə başa çatdı ki, bu da, əslində, adi tar-a olduqca yaxındır. Sistem yükü ümumilikdə
eyni:
Yedəkləmə bərpası zamanı zbackup aşağıdakı nəticələr əldə edildi:
şifrləmə, lzma sıxılması
İş zamanı 11 dəqiqə 8 saniyə
şifrləmə aes, lzma sıxılması
İş zamanı 14 dəqiqə
şifrləmə aes, lzo sıxılması
İş zamanı 6 dəqiqə 19 saniyə
Ümumilikdə, yaxşıdır. Hər şey yedəkləmə serverinin prosessorunun sürətinə bağlıdır ki, bu da müxtəlif sıxıcılar ilə proqramın işləmə vaxtında aydın şəkildə görünür. Yedəkləmə serverinin tərəfdən adi tar icra edilmişdir, buna görə bununla müqayisədə - bərpa 3 dəfə daha yavaş işləyir. Bəlkə də iki dənəylə daha çox iplik sayı ilə çox iplikli rejimdə iş bağlamağı yoxlamaq lazımdır.
BorgBackup şifrləmə rejimində tar-dan bir az yavaş, 2 dəqiqə 45 saniyə ilə başa çatdı, lakin, eyni tar-dan fərqli olaraq, depozit deduplikasiyası imkanı yarandı. Bu halda yük
aşağıdakı oldu:
Şifrləmə blake əsaslı aktivləşdirildikdə, yedəkləmə bərpasının sürəti bir az yavaşlayır. Bu rejimdə bərpa müddəti 3 dəqiqə 19 saniyədir, yük isə
belədir:
Şifrləmə aes bir az yavaş çalışır, bərpa müddəti 3 dəqiqə 23 saniyədir, yük isə xüsusi
deyil:
Borg bir çox iplikli rejimdə işləyə bildiyi üçün - prosessor yükü maksimuma çatır, eyni zamanda əlavə funksiyaların aktivləşdirilməsi yalnız iş vaxtını artırır. Görünür, zbackup ilə oxşar olaraq çox iplikliliyi araşdırmağa dəyər.
Restic bərpa etməyi bir az daha yavaş başa çatdırdı, işləmə müddəti 4 dəqiqə 28 saniyədir. Bu halda yük
belə:
Görünür, bərpa prosesi bir neçə iplikdə işləyir, lakin BorgBackup-la müqayisədə effektivlik o qədər yüksək deyil, amma adi rsync ilə vaxt baxımından müqayisə olunur.
İlə UrBackup məlumatları 8 dəqiqə 19 saniyəyə bərpa edə bildi, bu zaman yük
belə:
həmçinin görünür ki, yük çox da yüksək deyil, hətta tar-dan daha aşağıdır. Yer yer sıçrayışlar var, lakin bir nüvənin yükündən çox deyil.
Müqayisə üçün meyarların seçimi və əsaslandırılması
Əvvəlki məqalələrdən birində qeyd edildiyi kimi, yedəkləmə sistemi aşağıdakı meyarlara cavab verməlidir:
- İşin asanlığı
- Universallıq
- Stabillik
- Sürət
Hər bir bəndi ayrı-ayrılıqda daha ətraflı müzakirə etməyə dəyər.
İstifadə sadəliyi
Bütün şeyləri tam həyata keçirmək üçün bir düymənin olması ən yaxşısıdır, amma real proqramlara qayıtsaq - ən rahat olacaq müəyyən bir tanış və standart iş prinsipi.
Əksər istifadəçilər üçün CLI üçün bir çox açarları yadda saxlamağa ehtiyac qalmadan, web və ya tui vasitəsilə müxtəlif, çox vaxt anlaşılmayan seçimləri tənzimləmədən, uğursuz işlə bağlı bildirişlərin tənzimlənməsindən daha yaxşı olacağı düşünülür. Buraya, mövcud infrastruktura ehtiyat nüsxələrini asanlıqla "yazmaq" və ehtiyat nüsxə prosesini avtomatlaşdırmaq imkanı da daxildir. Eyni zamanda, paket meneceri ilə quraşdırma imkanı, yaxud bir-iki komandaya "endirmə və açma" kimi əmrlərlə də həyata keçirilə bilər. curl link | sudo bash — mürəkkəb metod, çünki bağlantıdan gələn məlumatı yoxlamaq lazımdır.
Məsələn, nəzərdən keçirilən namizədlər arasında sadə həll burp, rdiff-backup və resticdir ki, bunların da müxtəlif iş rejimləri üçün mnemonik açarları var. Bir az daha mürəkkəb olanlar borg və duplicitydir. Ən mürəkkəb olanı AMANDA oldu. Digərləri isə istifadə asanlığı baxımından ortada yerləşir. Hər halda, istifadəçi təlimatını oxumaq üçün 30 saniyədən çox vaxt tələb olunarsa, ya Google və ya başqa axtarış sisteminə müraciət etmək lazım olarsa, ya da uzun bir kömək sənədini keçməyə ehtiyac varsa — bu, mürəkkəb bir həll olsa belə.
İnceleme olunan namizədlərin bəziləri avtomatik olaraq e-mailjabber vasitəsilə mesaj göndərə bilir, digər isə sistemdəki ayarlanmış bildirişlərə əsaslanır. Bu zaman daha çox mürəkkəb həllərin bildiriş ayarları çox vaxt aydın olmayıb. Hər halda, əgər ehtiyat nüsxə proqramı sıfırdan fərqli bir kod döndərsə və bu sistemin dövri vəzifələrə aid servis tərəfindən düzgün başa düşülürsə (sistem administratoruna ya da monitorinqə bir mesaj göndəriləcək) — vəziyyət asandır. Ancaq ehtiyat nüsxə sistemi, ehtiyat nüsxə serveri üzərində işləmirsə, problemi aydın bir şəkildə bildirməkdə çətinlik çəkirsə — bu, artıq lazımsız mürəkkəblikdir. Hər halda, xəbərdarlıqların və digər mesajların yalnız veb-interfeysin və ya jurnalın içərisində verilməsi pis praktikadır, çünki bunların çox vaxt göz ardı ediləcəyi ehtimal olunur.
Avtomatlaşdırmaya gəldikdə — sadə proqram mühit dəyişkənlərini oxumağı bacarır, hansı ki, onun iş rejimini müəyyən edir, ya da tam veb-interfeysdə işləyərkən olduğu davranışı tam olaraq təkrarlaya bilən inkişaf etmiş bir CLI-yə sahibdir. Buraya axın işinin aparılması, genişlənmə imkanlarının olması və s. daxildir.
Universallıq
Qismən avtomatizasiya ilə bağlı əvvəlki bölmə ilə üst-üstə düşür, ehtiyat nüsxə prosesini mövcud infrastruktura "yazmaq" heç bir problem yaratmamalıdır.
Xüsusilə veb interfeysdən (o cümlədən) kənar portların istifadəsi, şifrələmənin qeyri-standart üsullarla həyata keçirilməsi, qeyri-standart protokollarla məlumat mübadiləsi — universal olmayan həllərin əlamətləridir. Çox vaxt bütün namizədlərin bu xüsusiyyətləri vardır, çünki sadəlik və universallıq adətən bir-biri ilə uyğun gəlmir. İstisna olaraq — burp, digər həllər də mövcuddur.
Bir əlamət olaraq — adi ssh istifadə edərək işləmə imkanı.
İş vaxtı
Ən mübahisəli və mübahisəli məqam. Bir tərəfdən — prosesi işə saldıq, o maksimum sürətlə işləyir və əsas vəzifələrə mane olmur. Digər tərəfdən — ehtiyat nüsxə zamanı trafik və prosessorun yükünün artması. Həmçinin, ən sürətli nüsxə götürmə proqramlarının, istifadəçilər üçün vacib olan funksiyalar baxımından daha az imkan təqdim etməsi qeyd olunmalıdır. Yenə də: bir çətinlik olan bir neçə on baytlıq mətn faylını parolla götürmək üçün bütün xidmətin dayanması lazım olduğunu anlayıram (bəli, burada ehtiyat nüsxə prosesi ən çox günahkar olmur), eyni zamanda bütün faylları ardıcıl olaraq oxumaq və ya tam bir arxiv açmaq lazım olur — ehtiyat nüsxə sistemi bir dəfə də sürətli olmur. Həmçinin, nüsxənin arxivdən bərpasının sürəti də tez-tez problemli bir məsələ olur. Burada faylları müvafiq yerə çoxsaylı manipulyasiyalar olmadan sadəcə kopyalayıb ya da köçürə bilənlərin (məsələn, rsync) açıq üstünlüyü var, amma çox vaxt problemi təşkilatlanma yolu ilə həll etmək, empiric şəkildə: ehtiyat nüsxənin bərpa vaxtını ölçmək və bunu istifadəçilərə açıq bildirmək lazım gəlir.
Stabillik
Belə başa düşmək lazımdır: bir tərəfdən, ehtiyat nüsxəni mütləq geri açmaq imkanı olmalıdır, digər tərəfdən — müxtəlif problemlərə qarşı dayanıqlılıq: şəbəkənin kəsilməsi, diskdə nasazlıq, depozitariyadan bir hissənin silinməsi.
Ehtiyat nüsxə vasitələrinin müqayisəsi
Nüsxə yaradılma vaxtı
Nüsxənin bərpa vaxtı
Asan quraşdırma
Sadə konfiqurasiya
Sadə istifadə
Sadə automatlaşdırma
Kliyen-serverə ehtiyac varmı?
Depozitarın bütövlük yoxlaması
Fərqli nüsxələr
Pipe vasitəsilə işləmə
Universallıq
Müstəqillik
Depozitarın şəffaflığı
Şifrləmə
Sıxılma
Deduplication
Veb-interfeysi
Buluda yükləmə
Windows dəstəyi
Ball
Rsync
4d15s
4d28s
bəli
yox
yox
yox
bəli
yox
yox
bəli
yox
bəli
bəli
yox
yox
yox
yox
yox
bəli
6
Tar
pure
3d12s
2d43s
bəli
yox
yox
yox
yox
yox
bəli
bəli
yox
bəli
yox
yox
yox
yox
yox
yox
bəli
8,5
gzip
9d37s
3d19s
bəli
Rdiff-backup
16d26s
17d17s
bəli
bəli
bəli
bəli
bəli
yox
bəli
yox
bəli
yox
bəli
yox
bəli
bəli
bəli
yox
bəli
11
Rsnapshot
4d19s
4d28s
bəli
bəli
bəli
bəli
yox
yox
bəli
yox
bəli
yox
bəli
yox
yox
bəli
bəli
yox
bəli
12,5
Burp
11d9s
7d2s
bəli
yox
bəli
bəli
bəli
bəli
bəli
yox
bəli
bəli
yox
yox
bəli
yox
bəli
yox
bəli
10,5
Duplicity
şifrələmə yoxdur
16d48s
10d58s
bəli
bəli
yox
bəli
yox
bəli
bəli
yox
yox
bəli
yox
bəli
bəli
yox
bəli
yox
bəli
11
gpg
17d27s
15d3s
Duplicati
şifrələmə yoxdur
20d28s
13d45s
yox
bəli
yox
yox
yox
bəli
bəli
yox
yox
bəli
yox
bəli
bəli
bəli
bəli
bəli
bəli
11
aes
29d41s
21d40s
gpg
26d19s
16d30s
Zbackup
şifrələmə yoxdur
40d3s
11d8s
bəli
bəli
yox
yox
yox
bəli
bəli
bəli
yox
bəli
yox
bəli
bəli
bəli
yox
yox
yox
10
aes
42d0s
14d1s
aes+lzo
18d9s
6d19s
BorgBackup
şifrələmə yoxdur
4d7s
2d45s
bəli
bəli
bəli
bəli
bəli
bəli
bəli
bəli
bəli
bəli
yox
bəli
bəli
bəli
bəli
yox
bəli
16
aes
4d58s
3d23s
blake2
4d39s
3d19s
Restic
5d38s
4d28s
bəli
bəli
bəli
bəli
yox
bəli
bəli
bəli
bəli
bəli
yox
bəli
yox
bəli
yox
bəli
bəli
15,5
UrBackup
8d21s
8d19s
bəli
bəli
bəli
yox
bəli
yox
bəli
yox
bəli
bəli
yox
bəli
bəli
bəli
bəli
yox
bəli
12
Amanda
9d3s
2d49s
bəli
yox
yox
bəli
bəli
bəli
bəli
yox
bəli
bəli
bəli
bəli
bəli
yox
bəli
bəli
bəli
13
BackupPC
rsync
12d22s
7d42s
bəli
yox
bəli
bəli
bəli
bəli
bəli
yox
bəli
yox
yox
bəli
bəli
yox
bəli
yox
bəli
10,5
tar
12d34s
12d15s
Cədvəlin legendası:
- Yaşıl, iş vaxtı beş dəqiqədən azdır, ya da cavab 'Bəli' ( 'Kliyen-serverə ehtiyac varmı?' sütunu istisna olmaqla), 1 bal
- Sarı, iş vaxtı beş-on dəqiqə, 0.5 bal
- Qırmızı, iş vaxtı on dəqiqədən çoxdur, ya "Xeyir" cavabı ("Müştəri-server lazım?" sütunu istisna olmaqla), 0 bal
Yuxarıdakı cədvəldə ən sadə, sürətli və eyni zamanda rahat və güclü ehtiyat nüsxə aləti BorgBackup-dır. İkinci yerdə Restic-dir, digər müzakirə olunan namizədlər isə bir-birinə bənzər bir-ballıq bölgüdə yerləşdilər.
Mən bu dövrü sona qədər oxuyan hər kəsə təşəkkür edirəm, variantları müzakirə etməyi və varsa, özünüzü təqdim etməyi təklif edirəm. Müzakirə əsnasında cədvəl əlavə edilə bilər.
Dövrün nəticəsi olaraq, ideal, sürətli və idarə olunan ehtiyat nüsxə vasitəsi təqdim olunacaq ki, bu da nüsxəni geri qaytarmağı sürətləndirsin və eyni zamanda qurma və dəstək təmin etsin.
Elan
Ehtiyat nüsxəsi, hissə 6: Ehtiyat nüsxəsi vasitələrinin müqayisəsi
Ehtiyat nüsxə, hissə 7: Nəticələr
Mənbə: habr.com
