Энэ тэмдэглэл нь нөөц сервер дээр архив үүсгэх замаар нөөцлөлтийг гүйцэтгэдэг нөөцлөх хэрэгслүүдийн талаар авч үзнэ.
Шаардлагуудыг хангасан зүйлсийн дунд давхардал (deja dup хэлбэрээр сайхан интерфейстэй) болон давхардсан байдаг.
Өөр нэг гайхалтай нөөцлөх хэрэгсэл бол dar, гэхдээ энэ нь маш өргөн сонголттой жагсаалттай тул туршилтын аргачлал нь чадавхынхаа бараг 10% -ийг хамардаг - бид үүнийг одоогийн мөчлөгийн нэг хэсэг болгон туршихгүй байна.
Хүлээгдэж буй үр дүн
Нэр дэвшигчид хоёулаа архив үүсгэдэг тул ердийн давирхайг гарын авлага болгон ашиглаж болно.
Нэмж дурдахад, бид файлуудын бүрэн хуулбар болон одоогийн төлөв, эсвэл өмнөх болон одоогийн архивуудын (өсөлт, бууралт гэх мэт) хоорондын ялгааг агуулсан нөөц хуулбарыг үүсгэх замаар хадгалах сервер дээрх өгөгдөл хадгалах нь хэр оновчтой болохыг үнэлэх болно. .
Нөөцлөлт үүсгэх үеийн зан байдал:
- Нөөц хадгалах сервер дээрх харьцангуй цөөн тооны файлууд (нөөц хуулбарын тоо эсвэл ГБ дахь өгөгдлийн хэмжээтэй харьцуулах боломжтой), гэхдээ тэдгээрийн хэмжээ нэлээд том (арваас хэдэн зуун мегабайт).
- Хадгалах сангийн хэмжээ нь зөвхөн өөрчлөлтийг багтаах болно - ямар ч хуулбарыг хадгалахгүй, тиймээс хадгалах сангийн хэмжээ нь rsync-д суурилсан программ хангамжаас бага байх болно.
- Шахалт ба/эсвэл шифрлэлт ашиглах үед CPU-ийн ачаалал их байх ба хэрэв архивлах болон/эсвэл шифрлэх процесс нөөц хадгалах сервер дээр ажиллаж байгаа бол сүлжээ болон дискний ачаалал нэлээд өндөр байх магадлалтай.
Дараах командыг лавлагааны утга болгон ажиллуулъя:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"Гүйцэтгэлийн үр дүн дараах байдалтай байв.
Гүйцэтгэх хугацаа 3м12с. Жишээн дээрх шиг хурд нь нөөц хадгалах серверийн дискний дэд системээр хязгаарлагдаж байгааг харж болно. . Жаахан хурдан, учир нь... бичлэг нь нэг файлд шилждэг.
Мөн шахалтыг үнэлэхийн тулд ижил сонголтыг ажиллуулъя, гэхдээ нөөц сервер талд шахалтыг идэвхжүүлнэ үү:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"Үр дүн нь:
Гүйцэтгэх хугацаа 10м11с. Хамгийн гол нь хүлээн авагч талын нэг урсгалтай компрессорын бөглөрөл байх магадлалтай.
Үүнтэй ижил тушаал, гэхдээ гацах нь нэг урсгалтай компрессор гэсэн таамаглалыг шалгахын тулд анхны өгөгдлийн хамт сервер рүү шахалтын тусламжтайгаар шилжүүлсэн.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"Энэ нь дараах байдалтай болсон.
Гүйцэтгэлийн хугацаа 9 м37 секунд байв. Компрессорын нэг цөм дээрх ачаалал тодорхой харагдаж байна, учир нь Сүлжээг дамжуулах хурд болон эх дискний дэд системийн ачаалал ижил байна.
Шифрлэлтийг үнэлэхийн тулд та нэмэлт командыг холбож openssl эсвэл gpg ашиглаж болно openssl буюу gpg хоолойд. Лавлагааны хувьд иймэрхүү тушаал байх болно:
cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"Үр дүн нь дараах байдлаар гарсан.
Хүлээн авах тал дээр 10 процесс ажиллаж байсан тул гүйцэтгэх хугацаа 30м2 секунд болсон - бөглөрөл нь дахин нэг урсгалтай компрессор, мөн жижиг шифрлэлтийн ачаалал юм.
UPD: Bliznezz-ийн хүсэлтээр би pigz-тэй туршилтуудыг нэмж байна. Хэрэв та зөвхөн компрессор ашигладаг бол 6м30 секунд, шифрлэлтийг нэмбэл 7м орчим болно. Доод график дахь зай нь цэвэрлээгүй дискний кэш юм:
Давхардсан туршилт
Duplicity нь tar форматаар шифрлэгдсэн архив үүсгэх замаар нөөцлөх зориулалттай python програм хангамж юм.
Өсөн нэмэгдэж буй архивын хувьд librsync-ийг ашигладаг тул та-д тайлбарласан үйлдлийг хүлээж болно .
Нөөцлөлтийг gnupg ашиглан шифрлэж, гарын үсэг зурж болох бөгөөд энэ нь нөөцлөлтийг хадгалахад өөр өөр үйлчилгээ үзүүлэгч (s3, backblaze, gdrive гэх мэт) ашиглахад чухал юм.
Үр дүн нь юу болохыг харцгаая:
Эдгээр нь шифрлэлтгүйгээр ажиллахад олж авсан үр дүн юм
хорлон сүйтгэгч
Туршилт бүрийн ажиллах хугацаа:
1-г эхлүүлэх
2-г эхлүүлэх
3-г эхлүүлэх
16м33с
17м20с
16м30с
8м29с
9м3с
8м45с
5м21с
6м04с
5м53с
2048 битийн түлхүүрийн хэмжээтэй gnupg шифрлэлтийг идэвхжүүлсэн үр дүнгүүд энд байна:
Шифрлэлттэй ижил өгөгдөл дээр ажиллах хугацаа:
1-г эхлүүлэх
2-г эхлүүлэх
3-г эхлүүлэх
17м22с
17м32с
17м28с
8м52с
9м13с
9м3с
5м48с
5м40с
5м30с
Блокийн хэмжээг зааж өгсөн - 512 мегабайт нь график дээр тодорхой харагдаж байна; Процессорын ачаалал үнэндээ 50% хэвээр байгаа бөгөөд энэ нь програм нь нэгээс илүү процессорын цөмийг ашигладаггүй гэсэн үг юм.
Хөтөлбөрийн ажиллах зарчим нь бас тодорхой харагдаж байна: тэд өгөгдлийн хэсгийг авч, шахаж, нөөц хадгалах сервер рүү илгээсэн бөгөөд энэ нь нэлээд удаан байж болно.
Өөр нэг онцлог шинж чанар нь зөвхөн өөрчлөгдсөн өгөгдлийн хэмжээнээс хамаардаг програмын ажиллах хугацааг урьдчилан таамаглах явдал юм.
Шифрлэлтийг идэвхжүүлснээр программын ажиллах хугацааг төдийлөн нэмэгдүүлээгүй ч CPU-ийн хэрэглээг ойролцоогоор 10%-иар нэмэгдүүлсэн нь маш сайн урамшуулал байж болох юм.
Харамсалтай нь, энэ програм нь лавлахын нэрийг өөрчлөхтэй холбоотой нөхцөл байдлыг зөв илрүүлж чадаагүй бөгөөд үр дүнд нь хадгалах сангийн хэмжээ нь өөрчлөлтийн хэмжээтэй (жишээ нь, бүх 18 ГБ) тэнцүү болсон боловч найдвартай серверийг нөөцлөхөд ашиглах боломжтой болсон. энэ зан үйлийг хамардаг.
Давхардсан туршилт
Энэхүү программ хангамж нь C# хэл дээр бичигдсэн бөгөөд Mono-ийн багц сангуудыг ашиглан ажилладаг. GUI болон CLI хувилбар байдаг.
Үндсэн функцүүдийн ойролцоо жагсаалт нь төрөл бүрийн нөөц хадгалах үйлчилгээ үзүүлэгчдийг багтаасан давхардалтай төстэй боловч давхардлаас ялгаатай нь ихэнх функцийг гуравдагч талын хэрэгсэлгүйгээр ашиглах боломжтой. Энэ нь нэмэх эсвэл хасах эсэх нь тухайн тохиолдлоос шалтгаална, гэхдээ эхлэгчдэд python-д зориулсан багцуудыг нэмж суулгахаас илүүтэйгээр бүх функцуудын жагсаалтыг нэг дор харуулах нь илүү хялбар байдаг. хоёрдмол утгатай хэрэг.
Өөр нэг жижиг нюанс - програм нь нөөцлөлтийг эхлүүлсэн хэрэглэгчийн нэрийн өмнөөс локал sqlite мэдээллийн санг идэвхтэй бичдэг тул cli-г ашиглаж эхлэх бүрт шаардлагатай мэдээллийн баазыг зөв зааж өгөх шаардлагатай. GUI эсвэл WEBGUI-ээр ажиллах үед дэлгэрэнгүй мэдээллийг хэрэглэгчээс нуух болно.
Энэхүү шийдэл нь ямар үзүүлэлтүүдийг гаргаж болохыг харцгаая:
Хэрэв та шифрлэлтийг унтраавал (мөн WEBGUI үүнийг хийхийг зөвлөдөггүй) үр дүн нь дараах байдалтай байна:
Ажлын цаг:
1-г эхлүүлэх
2-г эхлүүлэх
3-г эхлүүлэх
20м43с
20м13с
20м28с
5м21с
5м40с
5м35с
7м36с
7м54с
7м49с
Шифрлэлт идэвхжсэн үед aes ашиглан дараах байдлаар харагдана.
Ажлын цаг:
1-г эхлүүлэх
2-г эхлүүлэх
3-г эхлүүлэх
29м9с
30м1с
29м54с
5м29с
6м2с
5м54с
8м44с
9м12с
9м1с
Хэрэв та gnupg гадаад програмыг ашиглавал дараах үр дүн гарч ирнэ.
1-г эхлүүлэх
2-г эхлүүлэх
3-г эхлүүлэх
26м6с
26м35с
26м17с
5м20с
5м48с
5м40с
8м12с
8м42с
8м15с
Таны харж байгаагаар програм нь хэд хэдэн урсгалтай ажиллах боломжтой боловч энэ нь илүү үр дүнтэй шийдэл биш бөгөөд хэрэв та шифрлэлтийн ажлыг харьцуулж үзвэл энэ нь гадаад програмыг ажиллуулж байна.
Энэ нь Моно багцын номын санг ашиглахаас илүү хурдан болсон. Энэ нь гадны программыг илүү оновчтой болгосонтой холбоотой байж болох юм.
Өөр нэг сайхан зүйл бол репозиторын хэмжээ нь бодит өөрчлөгдсөн өгөгдлөөс яг ихийг авдаг явдал байв. duplicati нь лавлахын нэрийг өөрчилснийг илрүүлж, энэ байдлыг зөв зохицуулсан. Үүнийг хоёр дахь туршилтыг явуулахад харж болно.
Ерөнхийдөө хөтөлбөрийн талаар нэлээд эерэг сэтгэгдэл төрүүлсэн, тэр дундаа шинэхэн хүмүүст ээлтэй байна.
Результаты
Хоёр нэр дэвшигч хоёулаа нэлээд удаан ажилласан, гэхдээ ерөнхийдөө ердийн давирхайтай харьцуулахад ахиц дэвшил, наад зах нь давхардсан байна. Ийм ахиц дэвшлийн үнэ бас тодорхой байна - мэдэгдэхүйц ачаалал
процессор. Ерөнхийдөө үр дүнг урьдчилан таамаглахад онцгой хазайлт байхгүй.
үр дүн нь
Хэрэв та хаашаа ч яарах шаардлагагүй, мөн сэлбэг процессортой бол авч үзсэн шийдлүүдийн аль нэг нь хийх болно, ямар ч тохиолдолд tar дээр боодлын скрипт бичих замаар давтагдах ёсгүй маш их ажил хийгдсэн. . Хэрэв нөөц хуулбарыг хадгалах серверт бүрэн итгэх боломжгүй бол шифрлэлт байгаа нь маш чухал шинж чанар юм.
Шийдэлд суурилсан шийдэлтэй харьцуулахад - цэвэр хэлбэрээр tar нь rsync-ээс 20-30% хурдан ажилладаг байсан ч гүйцэтгэл хэд дахин муу байж болно.
Хадгалах сангийн хэмжээ хэмнэлттэй, гэхдээ зөвхөн давхардсан тоогоор.
Зарлал
Нөөцлөлт 3-р хэсэг: Давхардал, давхардал, deja dup-ийг хянаж, турших
Нөөцлөх 4-р хэсэг: zbackup, restic, borgbackup-г шалгаж, туршиж байна
Нөөцлөх хэсэг 5: Линуксийн хувьд bacula болон veeam нөөцлөлтийг турших
Нөөцлөх 6-р хэсэг: Нөөцлөх хэрэгслүүдийг харьцуулах
Нөөц 7-р хэсэг: Дүгнэлт
Нийтэлсэн: Павел Демкович
Эх сурвалж: www.habr.com