Энэ нийтлэлд өгөгдлийн урсгалыг салангид бүрэлдэхүүн хэсгүүдэд (хэсэг) хуваах замаар репозитор үүсгэдэг нөөц програм хангамжийг авч үзэх болно.
Хадгалах сангийн бүрэлдэхүүн хэсгүүдийг цаашид шахаж, шифрлэх боломжтой бөгөөд хамгийн чухал нь дахин нөөцлөх явцад дахин ашиглах боломжтой.
Ийм агуулах дахь нөөц хуулбар нь өөр хоорондоо холбогдсон бүрэлдэхүүн хэсгүүдийн нэрлэгдсэн хэлхээ юм, жишээлбэл, янз бүрийн хэш функц дээр үндэслэсэн.
Хэд хэдэн ижил төстэй шийдлүүд байдаг, би 3 дээр анхаарлаа хандуулах болно: zbackup, borgbackup болон restic.
Хүлээгдэж буй үр дүн
Бүх өргөдөл гаргагчид ямар нэгэн байдлаар репозитор үүсгэхийг шаарддаг тул хамгийн чухал хүчин зүйлүүдийн нэг нь хадгалах сангийн хэмжээг тооцоолох явдал юм. Хамгийн тохиромжтой нь түүний хэмжээ нь хүлээн зөвшөөрөгдсөн аргачлалын дагуу 13 ГБ-аас ихгүй, эсвэл сайн оновчлолын дагуу түүнээс бага байх ёстой.
Мөн tar гэх мэт архивлагч ашиглахгүйгээр шууд файлуудын нөөц хуулбарыг үүсгэх, мөн rsync, sshfs гэх мэт нэмэлт хэрэгсэлгүйгээр ssh/sftp-тэй ажиллах боломжтой байх нь зүйтэй юм.
Нөөцлөлт үүсгэх үеийн зан байдал:
- Хадгалах сангийн хэмжээ нь өөрчлөлтийн хэмжээтэй тэнцүү буюу түүнээс бага байх болно.
- Шахалт ба/эсвэл шифрлэлт ашиглах үед CPU-ийн ачаалал их байх ба хэрэв архивлах болон/эсвэл шифрлэх процесс нөөц хадгалах сервер дээр ажиллаж байгаа бол сүлжээ болон дискний ачаалал нэлээд өндөр байх магадлалтай.
- Хэрэв репозитор гэмтсэн бол шинээр нөөцлөлт үүсгэх болон сэргээх оролдлого хийх үед алдаа гарах магадлалтай. Хадгалах сангийн бүрэн бүтэн байдлыг хангах нэмэлт арга хэмжээг төлөвлөх эсвэл түүний бүрэн бүтэн байдлыг шалгахын тулд суурилуулсан хэрэгслийг ашиглах шаардлагатай.
Өмнөх нийтлэлүүдийн аль нэгэнд үзүүлсэн шиг давирхайтай ажиллах нь жишиг утга болгон авсан болно.
zbackup-г туршиж байна
Zbackup-ийн ерөнхий механизм нь програм нь ижил өгөгдөл агуулсан оролтын өгөгдлийн урсгалын хэсгүүдийг олж, дараа нь тэдгээрийг шахаж, шифрлэх замаар хэсэг бүрийг зөвхөн нэг удаа хадгалдаг явдал юм.
Хувилбар нь гүйдэг цонхтой 64 битийн цагираган хэш функцийг ашиглан одоо байгаа өгөгдлийн блокуудтай байт байт таарч байгаа эсэхийг шалгадаг (rsync үүнийг хэрхэн хэрэгжүүлдэгтэй адил).
Олон урсгалтай lzma болон lzo нь шахалтанд, aes нь шифрлэхэд ашиглагддаг. Хамгийн сүүлийн үеийн хувилбарууд нь хуучин өгөгдлийг ирээдүйд хадгалах сангаас устгах чадвартай.
Програм нь C++ хэл дээр хамгийн бага хамааралтайгаар бичигдсэн. Зохиогч нь unix-way-ээс санаа авсан бололтой, програм нь нөөцлөлт үүсгэх үед stdin дээрх өгөгдлийг хүлээн авч, сэргээх үед stdout дээр ижил төстэй өгөгдлийн урсгал үүсгэдэг. Тиймээс zbackup-ийг өөрийн нөөцийн шийдлүүдийг бичихэд маш сайн "барилгын блок" болгон ашиглаж болно. Жишээлбэл, нийтлэлийн зохиогч энэ програмыг ойролцоогоор 2014 оноос хойш гэрийн машинуудын үндсэн нөөц хэрэгсэл болгон ашиглаж байна.
Өөрөөр заагаагүй бол өгөгдлийн урсгал нь ердийн tar байх болно.
Үр дүн нь юу болохыг харцгаая:
Ажлыг 2 хувилбараар шалгасан.
- репозитор үүсгэж, zbackup-ийг эх өгөгдөл бүхий сервер дээр ажиллуулсны дараа репозиторын агуулгыг нөөц хадгалах сервер рүү шилжүүлнэ.
- нөөц хадгалах сервер дээр репозитор үүсгэж, zbackup-г нөөц хадгалах сервер дээр ssh-ээр ажиллуулж, өгөгдөл дамжуулах хоолойгоор дамжуулан илгээдэг.
Эхний хувилбарын үр дүн дараах байдалтай байв: 43m11s - шифрлэгдээгүй репозитор болон lzma компрессор ашиглах үед, 19m13s - компрессорыг lzo-ээр солих үед.
Анхны өгөгдөл бүхий сервер дээрх ачаалал дараах байдалтай байв (lzma-тай жишээг үзүүлэв; lzo-д ойролцоогоор ижил зураг байсан боловч rsync-ийн эзлэх хувь цаг хугацааны дөрөвний нэг орчим байсан):
Ийм нөөцлөх үйл явц нь зөвхөн харьцангуй ховор, жижиг өөрчлөлтөд тохиромжтой нь тодорхой байна. Мөн zbackup-ийг 1 урсгалаар хязгаарлахыг зөвлөж байна, эс тэгвээс CPU-ийн ачаалал маш өндөр байх болно, учир нь Програм нь олон урсгалтай ажиллахад маш сайн. Диск дээрх ачаалал бага байсан бөгөөд энэ нь ерөнхийдөө орчин үеийн ssd-д суурилсан дискний дэд системд мэдэгдэхүйц биш байв. Та репозиторын өгөгдлийг алсын сервертэй синхрончлох үйл явцын эхлэлийг тодорхой харж болно; үйл ажиллагааны хурд нь ердийн rsync-тэй харьцуулж болох бөгөөд нөөц хадгалах серверийн дискний дэд системийн гүйцэтгэлээс хамаарна. Энэ аргын сул тал нь локал репозиторыг хадгалах, үүний үр дүнд өгөгдөл давхардах явдал юм.
Практикт илүү сонирхолтой бөгөөд хэрэглэх боломжтой нь zbackup-г шууд нөөц хадгалах сервер дээр ажиллуулах хоёр дахь сонголт юм.
Эхлээд бид lzma компрессор ашиглан шифрлэлт ашиглахгүйгээр үйл ажиллагааг турших болно.
Туршилт бүрийн ажиллах хугацаа:
1-г эхлүүлэх
2-г эхлүүлэх
3-г эхлүүлэх
39м45с
40м20с
40м3с
7м36с
8м3с
7м48с
15м35с
15м48с
15м38с
Хэрэв та aes ашиглан шифрлэлтийг идэвхжүүлбэл үр дүн нь ойролцоо байна:
Шифрлэлттэй ижил өгөгдөл дээр ажиллах хугацаа:
1-г эхлүүлэх
2-г эхлүүлэх
3-г эхлүүлэх
43м40с
44м12с
44м3с
8м3с
8м15с
8м12с
15м0с
15м40с
15м25с
Хэрэв шифрлэлтийг lzo ашиглан шахалттай хослуулсан бол дараах байдалтай харагдана.
Ажлын цаг:
1-г эхлүүлэх
2-г эхлүүлэх
3-г эхлүүлэх
18м2с
18м15с
18м12с
5м13с
5м24с
5м20с
8м48с
9м3с
8м51с
Үүссэн агуулахын хэмжээ нь 13 ГБ хэмжээтэй харьцангуй ижил байв. Энэ нь давхардал зөв ажиллаж байна гэсэн үг. Түүнчлэн, аль хэдийн шахсан өгөгдөл дээр lzo ашиглах нь мэдэгдэхүйц нөлөө үзүүлдэг; нийт ажиллах хугацааны хувьд zbackup нь давхардал/давхардсан тоонд ойртдог боловч librsync дээр суурилсан хувилбараас 2-5 дахин хоцорч байна.
Давуу тал нь ойлгомжтой - нөөц хадгалах сервер дээр дискний зайг хэмнэх. Репозиторий шалгах хэрэгслүүдийн хувьд zbackup-ийн зохиогч тэдгээрийг өгдөггүй тул алдааг тэсвэрлэх чадвартай дискний массив эсвэл үүлэн үйлчилгээ үзүүлэгчийг ашиглахыг зөвлөж байна.
Төсөл 3 жил орчим хугацаанд зогссон ч гэсэн ерөнхийдөө маш сайн сэтгэгдэл төрүүлэв (хамгийн сүүлийн онцлог хүсэлт жилийн өмнө байсан боловч хариу өгөөгүй).
Borgbackup-г туршиж байна
Borgbackup бол дээврийн хөндийн салаа, zbackup-тай төстэй өөр нэг систем юм. Python дээр бичигдсэн энэ нь zbackup-тай төстэй боломжуудын жагсаалттай боловч нэмэлтээр:
- Нөөцлөлтийг гал хамгаалагчаар холбоно
- Хадгалах сангийн агуулгыг шалгана уу
- Үйлчлүүлэгч-сервер горимд ажиллах
- Мэдээллийн хувьд янз бүрийн компрессор ашиглах, түүнчлэн файлын төрлийг шахахдаа эвристик тодорхойлох.
- Шифрлэлтийн 2 сонголт, aes болон blake
- Суурилуулсан хэрэгсэл
гүйцэтгэлийн шалгалт
borgbackup бенчмарк crud ssh://backup_server/repo/path local_dir
Үр дүн нь дараах байдалтай байв.
CZ-BIG 96.51 MB/s (10 100.00 MB бүх тэг файлууд: 10.36 сек)
RZ-BIG 57.22 MB/s (10 100.00 MB бүх тэг файлууд: 17.48 сек)
UZ-BIG 253.63 MB/s (10 100.00 MB бүх тэг файлууд: 3.94 сек)
DZ-BIG 351.06 MB/s (10 100.00 MB бүх тэг файлууд: 2.85 сек)
CR-BIG 34.30 MB/s (10 100.00 MB санамсаргүй файлууд: 29.15 сек)
RR-BIG 60.69 MB/s (10 100.00 MB санамсаргүй файлууд: 16.48 сек)
UR-BIG 311.06 MB/s (10 100.00 MB санамсаргүй файлууд: 3.21 сек)
DR-BIG 72.63 MB/s (10 100.00 MB санамсаргүй файлууд: 13.77 сек)
CZ-ДУНД 108.59 MB/s (1000 1.00 MB бүх тэг файлууд: 9.21 сек)
RZ-ДУНД 76.16 MB/s (1000 1.00 MB бүх тэг файлууд: 13.13 сек)
UZ-MEDIUM 331.27 MB/s (1000 1.00 MB бүх тэг файлууд: 3.02 сек)
DZ-MEDIUM 387.36 MB/s (1000 1.00 MB бүх тэг файлууд: 2.58 сек)
CR-MEDIUM 37.80 MB/s (1000 1.00 MB санамсаргүй файлууд: 26.45 сек)
RR-ДУНД 68.90 МБ/с (1000 1.00 MB санамсаргүй файлууд: 14.51 сек)
UR-ДУНД 347.24 МБ/с (1000 1.00 MB санамсаргүй файлууд: 2.88 сек)
DR-MEDIUM 48.80 MB/s (1000 1.00 MB санамсаргүй файлууд: 20.49 сек)
CZ-ЖИЖИГ 11.72 MB/s (10000 10.00 кБ бүх тэг файлууд: 8.53 сек)
RZ-ЖИЖИГ 32.57 MB/s (10000 10.00 кБ бүх тэг файлууд: 3.07 сек)
UZ-ЖИЖИГ 19.37 MB/s (10000 10.00 кБ бүх тэг файлууд: 5.16 сек)
DZ-SMALL 33.71 MB/s (10000 10.00 кБ бүх тэг файлууд: 2.97 сек)
CR-SMALL 6.85 MB/s (10000 10.00 кБ санамсаргүй файлууд: 14.60 сек)
RR-ЖИЖИГ 31.27 MB/s (10000 10.00 кБ санамсаргүй файлууд: 3.20 сек)
UR-ЖИЖИГ 12.28 МБ/с (10000 10.00 кБ санамсаргүй файлууд: 8.14 сек)
DR-SMALL 18.78 MB/s (10000 10.00 кБ санамсаргүй файлууд: 5.32 сек)
Туршилт хийхдээ файлын төрлийг (автоматаар шахах) тодорхойлохын тулд шахалтын эвристикийг ашиглах бөгөөд үр дүн нь дараах байдалтай байна.
Эхлээд шифрлэлтгүйгээр хэрхэн ажилладагийг шалгая:
Ажлын цаг:
1-г эхлүүлэх
2-г эхлүүлэх
3-г эхлүүлэх
4м6с
4м10с
4м5с
56s
58s
54s
1м26с
1м34с
1м30с
Хэрэв та репозиторын зөвшөөрлийг (баталгаажуулсан горим) идэвхжүүлбэл үр дүн нь ойр байх болно:
Ажлын цаг:
1-г эхлүүлэх
2-г эхлүүлэх
3-г эхлүүлэх
4м11с
4м20с
4м12с
1м0с
1м3с
1м2с
1м30с
1м34с
1м31с
Aes шифрлэлтийг идэвхжүүлсэн үед үр дүн төдийлөн муудсангүй:
1-г эхлүүлэх
2-г эхлүүлэх
3-г эхлүүлэх
4м55с
5м2с
4м58с
1м0с
1м2с
1м0с
1м49с
1м50с
1м50с
Хэрэв та aes-ийг блэйк болгон өөрчилбөл нөхцөл байдал бүрэн сайжирна:
Ажлын цаг:
1-г эхлүүлэх
2-г эхлүүлэх
3-г эхлүүлэх
4м33с
4м43с
4м40с
59s
1м0с
1м0с
1м38с
1м43с
1м40с
Zbackup-ийн нэгэн адил хадгалах сангийн хэмжээ 13 ГБ, бүр бага зэрэг бага байсан нь ерөнхийдөө хүлээгдэж буй зүйл юм. Ажиллах хугацаандаа би маш их сэтгэл хангалуун байсан; энэ нь librsync дээр суурилсан шийдлүүдтэй харьцуулахад илүү өргөн боломжийг олгодог. Автомат горимд borgbackup ашиглахад маш ноцтой давуу тал болох орчны хувьсагчаар дамжуулан янз бүрийн параметрүүдийг тохируулах чадварт би бас сэтгэл хангалуун байсан. Нөөцлөх явцад ачаалал их байгаад сэтгэл хангалуун байсан: процессорын ачааллаас харахад borgbackup нь 1 урсгалтай ажилладаг.
Үүнийг ашиглахад ямар ч тодорхой сул тал байгаагүй.
амралтын туршилт
Рестик бол нэлээд шинэ шийдэл боловч (эхний 2 нэр дэвшигч нь 2013 ба түүнээс дээш хугацаанд мэдэгдэж байсан) нэлээд сайн шинж чанартай. Go дээр бичсэн.
zbackup-тай харьцуулахад энэ нь нэмэлтээр өгдөг:
- Хадгалах сангийн бүрэн бүтэн байдлыг шалгах (хэсгүүдийг шалгах гэх мэт).
- Нөөцлөлтийг хадгалахад зориулагдсан дэмжигдсэн протокол, үйлчилгээ үзүүлэгчдийн асар том жагсаалт, мөн rclone - rsync for cloud solutions-ийн дэмжлэг.
- 2 нөөцлөлтийг өөр хоорондоо харьцуулж байна.
- Репозиторыг гал хамгаалагчаар холбож байна.
Ерөнхийдөө функцүүдийн жагсаалт нь borgbackup-тай нэлээд ойрхон, зарим газарт илүү, заримд нь бага байдаг. Үүний нэг онцлог нь шифрлэлтийг идэвхгүй болгох арга байхгүй тул нөөц хуулбарууд үргэлж шифрлэгдсэн байх болно. Энэ програм хангамжаас юу шахаж болохыг практик дээр харцгаая.
Үр дүн нь дараах байдалтай байв.
Ажлын цаг:
1-г эхлүүлэх
2-г эхлүүлэх
3-г эхлүүлэх
5м25с
5м50с
5м38с
35s
38s
36s
1м54с
2м2с
1м58с
Гүйцэтгэлийн үр дүнг rsync-д суурилсан шийдлүүдтэй харьцуулах боломжтой бөгөөд ерөнхийдөө borgbackup-тай маш ойрхон боловч CPU-ийн ачаалал өндөр (олон утас ажиллаж байгаа) болон хөрөөний шүдтэй байдаг.
Энэ програм нь rsync-ийн нэгэн адил өгөгдөл хадгалах сервер дээрх дискний дэд системийн гүйцэтгэлээр хязгаарлагдаж магадгүй юм. Хадгалах сангийн хэмжээ нь zbackup эсвэл borgbackup шиг 13 ГБ байсан тул энэ шийдлийг ашиглахад тодорхой сул тал байгаагүй.
Результаты
Үнэн хэрэгтээ бүх нэр дэвшигчид ижил төстэй үр дүнд хүрсэн боловч өөр өөр үнээр авсан. Borgbackup нь хамгийн сайн гүйцэтгэлтэй байсан, restic арай удаан байсан, zbackup ашиглаж эхлэх нь үнэ цэнэтэй биш байж магадгүй юм.
Хэрэв аль хэдийн ашиглагдаж байгаа бол үүнийг borgbackup эсвэл restic болгон өөрчилж үзээрэй.
үр дүн нь
Хамгийн ирээдүйтэй шийдэл нь тайван байх шиг байна, учир нь... Энэ бол түүний чадавхи болон үйл ажиллагааны хурд хамгийн сайн харьцаатай хүн боловч одоохондоо ерөнхий дүгнэлт рүү яарах хэрэггүй.
Borgbackup нь үндсэндээ муу зүйл биш ч zbackup нь илүү сайн солигдсон байх. Үнэн, zbackup-ийг 3-2-1 дүрмийг хэрэгжүүлэхийн тулд ашиглаж болно. Жишээлбэл, (lib) rsync-д суурилсан нөөцлөх байгууламжуудаас гадна.
Зарлал
Нөөцлөх хэсэг 5: Линуксийн хувьд bacula болон veeam нөөцлөлтийг турших
Нөөцлөх 6-р хэсэг: Нөөцлөх хэрэгслүүдийг харьцуулах
Нөөц 7-р хэсэг: Дүгнэлт
Нийтэлсэн: Павел Демкович
Эх сурвалж: www.habr.com