Backup Part 3: ການທົບທວນຄືນແລະການທົດສອບ duplicati, duplicati

ບັນທຶກນີ້ສົນທະນາກ່ຽວກັບເຄື່ອງມືສໍາຮອງທີ່ປະຕິບັດການສໍາຮອງຂໍ້ມູນໂດຍການສ້າງແຟ້ມຈັດເກັບໃນເຄື່ອງແມ່ຂ່າຍສໍາຮອງ.

ໃນບັນດາສິ່ງທີ່ຕອບສະຫນອງຄວາມຕ້ອງການແມ່ນ duplicati (ເຊິ່ງມີການໂຕ້ຕອບທີ່ສວຍງາມໃນຮູບແບບ deja dup) ແລະ duplicati.

ເຄື່ອງມືສໍາຮອງຂໍ້ມູນທີ່ໂດດເດັ່ນອີກອັນຫນຶ່ງແມ່ນ dar, ແຕ່ເນື່ອງຈາກວ່າມັນມີບັນຊີລາຍຊື່ຢ່າງກວ້າງຂວາງຂອງທາງເລືອກ - ວິທີການທົດສອບກວມເອົາເກືອບ 10% ຂອງສິ່ງທີ່ມັນມີຄວາມສາມາດ - ພວກເຮົາບໍ່ໄດ້ທົດສອບມັນເປັນສ່ວນຫນຶ່ງຂອງວົງຈອນປະຈຸບັນ.

ຜົນໄດ້ຮັບທີ່ຄາດວ່າຈະ

ນັບຕັ້ງແຕ່ຜູ້ສະຫມັກທັງສອງສ້າງແຟ້ມຈັດເກັບໃນວິທີການຫນຶ່ງຫຼືອື່ນ, tar ປົກກະຕິສາມາດຖືກນໍາໃຊ້ເປັນຄໍາແນະນໍາ.

ນອກຈາກນັ້ນ, ພວກເຮົາຈະປະເມີນວິທີການເກັບຮັກສາຂໍ້ມູນໃນເຊີຟເວີການເກັບຮັກສາຖືກປັບປຸງໃຫ້ດີທີ່ສຸດໂດຍການສ້າງສໍາເນົາສໍາຮອງທີ່ມີພຽງແຕ່ຄວາມແຕກຕ່າງລະຫວ່າງສໍາເນົາເຕັມແລະສະຖານະຂອງໄຟລ໌ໃນປະຈຸບັນ, ຫຼືລະຫວ່າງການເກັບຂໍ້ມູນທີ່ຜ່ານມາແລະປະຈຸບັນ (ເພີ່ມຂຶ້ນ, ຫຼຸດລົງ, ແລະອື່ນໆ). .

ພຶດ​ຕິ​ກໍາ​ໃນ​ການ​ສ້າງ​ການ​ສໍາ​ຮອງ​ຂໍ້​ມູນ​:

1. ຈໍານວນໄຟລ໌ທີ່ຂ້ອນຂ້າງຂ້ອນຂ້າງຢູ່ໃນເຄື່ອງແມ່ຂ່າຍການເກັບຮັກສາສໍາຮອງຂໍ້ມູນ (ທຽບກັບຈໍານວນຂອງສໍາເນົາສໍາຮອງຂໍ້ມູນຫຼືຂະຫນາດຂອງຂໍ້ມູນໃນ GB), ແຕ່ຂະຫນາດຂອງມັນແມ່ນຂ້ອນຂ້າງຫຼາຍ (ສິບຫາຫຼາຍຮ້ອຍ megabytes).
2. ຂະຫນາດຂອງ repository ຈະມີພຽງແຕ່ການປ່ຽນແປງ - ບໍ່ມີການຊ້ໍາກັນຈະຖືກເກັບໄວ້, ດັ່ງນັ້ນຂະຫນາດ repository ຈະນ້ອຍກວ່າກັບຊອບແວ rsync.
3. ຄາດຫວັງວ່າການໂຫຼດ CPU ໜັກເມື່ອໃຊ້ການບີບອັດ ແລະ/ຫຼືການເຂົ້າລະຫັດ, ແລະອາດຈະຂ້ອນຂ້າງສູງໃນການໂຫຼດເຄືອຂ່າຍ ແລະແຜ່ນຖ້າຂະບວນການເກັບຂໍ້ມູນ ແລະ/ຫຼືການເຂົ້າລະຫັດເຮັດວຽກຢູ່ໃນເຊີບເວີບ່ອນເກັບຂໍ້ມູນສຳຮອງ.

ໃຫ້ດໍາເນີນການຄໍາສັ່ງຕໍ່ໄປນີ້ເປັນຄ່າອ້າງອີງ:

cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"

ຜົນ​ການ​ປະ​ຕິ​ບັດ​ດັ່ງ​ນີ້​:

ເວລາປະຕິບັດ 3m12s. ມັນສາມາດເຫັນໄດ້ວ່າຄວາມໄວແມ່ນຖືກຈໍາກັດໂດຍລະບົບຍ່ອຍຂອງແຜ່ນຂອງເຄື່ອງແມ່ຂ່າຍການເກັບຮັກສາສໍາຮອງຂໍ້ມູນ, ເຊັ່ນດຽວກັບຕົວຢ່າງ rsync. ພຽງ​ແຕ່​ໄວ​ພຽງ​ເລັກ​ນ້ອຍ​, ເນື່ອງ​ຈາກ​ວ່າ ... ການບັນທຶກໄປຫາໄຟລ໌ດຽວ.

ນອກຈາກນັ້ນ, ເພື່ອປະເມີນການບີບອັດ, ໃຫ້ພວກເຮົາດໍາເນີນການທາງເລືອກດຽວກັນ, ແຕ່ເປີດໃຊ້ການບີບອັດຢູ່ດ້ານເຄື່ອງແມ່ຂ່າຍສໍາຮອງຂໍ້ມູນ:

cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"

ຜົນໄດ້ຮັບແມ່ນ:

ເວລາປະຕິບັດ 10m11s. ສ່ວນຫຼາຍອາດຈະ, ຄໍຂວດແມ່ນເຄື່ອງອັດລົມດຽວຢູ່ປາຍຮັບ.

ຄໍາສັ່ງດຽວກັນ, ແຕ່ມີການບີບອັດທີ່ຖືກໂອນໄປຫາເຄື່ອງແມ່ຂ່າຍທີ່ມີຂໍ້ມູນຕົ້ນສະບັບເພື່ອທົດສອບສົມມຸດຕິຖານວ່າຄໍຂວດແມ່ນເຄື່ອງອັດກະທູ້ດຽວ.

cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"

ມັນ​ໄດ້​ກາຍ​ເປັນ​ດັ່ງ​ນີ້​:

ເວລາປະຕິບັດແມ່ນ 9m37s. ການໂຫຼດຢູ່ໃນແກນຫນຶ່ງໂດຍເຄື່ອງອັດແມ່ນເຫັນໄດ້ຊັດເຈນ, ເພາະວ່າ ຄວາມໄວໃນການໂອນເຄືອຂ່າຍແລະການໂຫຼດຢູ່ໃນລະບົບຍ່ອຍຂອງແຜ່ນແຫຼ່ງແມ່ນຄ້າຍຄືກັນ.

ເພື່ອປະເມີນການເຂົ້າລະຫັດ, ທ່ານສາມາດນໍາໃຊ້ 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"

ຜົນໄດ້ຮັບອອກມາເຊັ່ນນີ້:

ເວລາປະຕິບັດໄດ້ຫັນອອກເປັນ 10m30s, ນັບຕັ້ງແຕ່ 2 ຂະບວນການກໍາລັງແລ່ນຢູ່ໃນດ້ານທີ່ໄດ້ຮັບ - ຄໍຂວດແມ່ນອີກເທື່ອຫນຶ່ງເປັນເຄື່ອງບີບອັດກະທູ້ດຽວ, ບວກກັບການເຂົ້າລະຫັດຂະຫນາດນ້ອຍ overhead.

UPS: ຕາມຄໍາຮ້ອງຂໍຂອງ bliznezz ຂ້ອຍກໍາລັງເພີ່ມການທົດສອບກັບ pigz. ຖ້າທ່ານໃຊ້ພຽງແຕ່ເຄື່ອງອັດ, ມັນຈະໃຊ້ເວລາ 6m30s, ຖ້າທ່ານເພີ່ມການເຂົ້າລະຫັດ, ມັນຈະປະມານ 7m. ການຈຸ່ມໃສ່ກຣາບລຸ່ມສຸດແມ່ນ cache ດິສກ໌ທີ່ບໍ່ໄດ້ລ້າງ:

ການທົດສອບຊ້ໍາກັນ

Duplicity ແມ່ນຊອບແວ python ສໍາລັບການສໍາຮອງຂໍ້ມູນໂດຍການສ້າງການເຂົ້າລະຫັດລັບໃນຮູບແບບ tar.

ສໍາລັບການເກັບຂໍ້ມູນເພີ່ມຂຶ້ນ, librsync ຖືກນໍາໃຊ້, ດັ່ງນັ້ນທ່ານສາມາດຄາດຫວັງວ່າພຶດຕິກໍາທີ່ອະທິບາຍໄວ້ໃນ ຕອບທີ່ຜ່ານມາໃນຊຸດ.

ການສໍາຮອງຂໍ້ມູນສາມາດຖືກເຂົ້າລະຫັດແລະລົງນາມໂດຍໃຊ້ gnupg, ເຊິ່ງເປັນສິ່ງສໍາຄັນໃນເວລາທີ່ນໍາໃຊ້ຜູ້ໃຫ້ບໍລິການທີ່ແຕກຕ່າງກັນສໍາລັບການເກັບຮັກສາສໍາຮອງຂໍ້ມູນ (s3, backblaze, gdrive, ແລະອື່ນໆ).

ມາ​ເບິ່ງ​ກັນ​ວ່າ​ຜົນ​ຈະ​ເປັນ​ແນວ​ໃດ:

ເຫຼົ່ານີ້ແມ່ນຜົນໄດ້ຮັບທີ່ພວກເຮົາໄດ້ຮັບໃນເວລາທີ່ແລ່ນໂດຍບໍ່ມີການເຂົ້າລະຫັດ

spoiler

ເວລາແລ່ນແຕ່ລະໄລຍະທົດສອບ:

ເປີດຕົວ 1
ເປີດຕົວ 2
ເປີດຕົວ 3

16m33 ວິ
17m20 ວິ
16m30 ວິ

8m29 ວິ
9m3 ວິ
8m45 ວິ

5m21 ວິ
6m04 ວິ
5m53 ວິ

ແລະນີ້ແມ່ນຜົນໄດ້ຮັບໃນເວລາທີ່ການເຂົ້າລະຫັດ gnupg ຖືກເປີດໃຊ້, ດ້ວຍຂະຫນາດທີ່ສໍາຄັນຂອງ 2048 bits:

ເວລາປະຕິບັດງານໃນຂໍ້ມູນດຽວກັນ, ດ້ວຍການເຂົ້າລະຫັດ:

ເປີດຕົວ 1
ເປີດຕົວ 2
ເປີດຕົວ 3

17m22 ວິ
17m32 ວິ
17m28 ວິ

8m52 ວິ
9m13 ວິ
9m3 ວິ

5m48 ວິ
5m40 ວິ
5m30 ວິ

ຂະຫນາດຕັນໄດ້ຖືກຊີ້ໃຫ້ເຫັນ - 512 megabytes, ເຊິ່ງເຫັນໄດ້ຊັດເຈນໃນກາຟ; ຕົວຈິງແລ້ວການໂຫຼດຂອງໂປເຊດເຊີຍັງຄົງຢູ່ທີ່ 50%, ຊຶ່ງຫມາຍຄວາມວ່າໂປລແກລມໃຊ້ບໍ່ເກີນຫນຶ່ງຫຼັກຂອງໂປເຊດເຊີ.

ຫຼັກການຂອງການດໍາເນີນງານຂອງໂຄງການແມ່ນຍັງເຫັນໄດ້ຊັດເຈນ: ພວກເຂົາເອົາຂໍ້ມູນຫນຶ່ງ, ບີບອັດມັນ, ແລະສົ່ງມັນໄປຫາເຄື່ອງແມ່ຂ່າຍການເກັບຮັກສາສໍາຮອງຂໍ້ມູນ, ເຊິ່ງອາດຈະຊ້າຫຼາຍ.
ຄຸນນະສົມບັດອີກອັນຫນຶ່ງແມ່ນໄລຍະເວລາແລ່ນຂອງໂປລແກລມທີ່ຄາດເດົາໄດ້, ເຊິ່ງຂຶ້ນກັບຂະຫນາດຂອງຂໍ້ມູນທີ່ປ່ຽນແປງເທົ່ານັ້ນ.

ການເປີດໃຊ້ງານການເຂົ້າລະຫັດບໍ່ໄດ້ເພີ່ມເວລາແລ່ນຂອງໂປລແກລມຢ່າງຫຼວງຫຼາຍ, ແຕ່ມັນໄດ້ເພີ່ມການໂຫຼດຂອງໂປເຊດເຊີປະມານ 10%, ເຊິ່ງອາດຈະເປັນເງິນທີ່ດີຫຼາຍ.

ແຕ່ຫນ້າເສຍດາຍ, ໂປລແກລມນີ້ບໍ່ສາມາດກວດສອບສະຖານະການໄດ້ຢ່າງຖືກຕ້ອງກັບການປ່ຽນຊື່ຂອງໄດເລກະທໍລີ, ແລະຂະຫນາດຂອງ repository ຜົນໄດ້ຮັບແມ່ນເທົ່າກັບຂະຫນາດຂອງການປ່ຽນແປງ (i. e. , ທັງຫມົດ 18GB), ແຕ່ຄວາມສາມາດໃນການໃຊ້ເຄື່ອງແມ່ຂ່າຍທີ່ບໍ່ຫນ້າເຊື່ອຖືສໍາລັບການສໍາຮອງຂໍ້ມູນຢ່າງຊັດເຈນ. ກວມເອົາພຶດຕິກໍານີ້.

ການທົດສອບຊ້ໍາກັນ

ຊອບແວນີ້ຖືກຂຽນໄວ້ໃນ C# ແລະເຮັດວຽກໂດຍໃຊ້ຊຸດຫ້ອງສະໝຸດຈາກ Mono. ມີ GUI ເຊັ່ນດຽວກັນກັບຮຸ່ນ CLI.

ບັນຊີລາຍຊື່ໂດຍປະມານຂອງລັກສະນະຕົ້ນຕໍແມ່ນຄ້າຍຄືກັນກັບ duplicity, ລວມທັງຜູ້ໃຫ້ບໍລິການເກັບຮັກສາສໍາຮອງຂໍ້ມູນຕ່າງໆ, ແນວໃດກໍ່ຕາມ, ບໍ່ເຫມືອນກັບ duplicity, ຄຸນນະສົມບັດສ່ວນໃຫຍ່ສາມາດໃຊ້ໄດ້ໂດຍບໍ່ມີເຄື່ອງມືພາກສ່ວນທີສາມ. ບໍ່ວ່າຈະເປັນບວກຫຼືລົບແມ່ນຂຶ້ນກັບກໍລະນີສະເພາະ, ແຕ່ສໍາລັບຜູ້ເລີ່ມຕົ້ນ, ມັນເປັນໄປໄດ້ງ່າຍທີ່ສຸດທີ່ຈະມີບັນຊີລາຍຊື່ຂອງຄຸນສົມບັດທັງຫມົດຢູ່ທາງຫນ້າຂອງພວກເຂົາໃນເວລາດຽວກັນ, ແທນທີ່ຈະມີການຕິດຕັ້ງແພັກເກັດເພີ່ມເຕີມສໍາລັບ python, ເຊັ່ນດຽວກັບ. ກໍລະນີທີ່ມີການຊໍ້າຊ້ອນ.

nuance ຂະຫນາດນ້ອຍອີກອັນຫນຶ່ງ - ໂປລແກລມຂຽນຖານຂໍ້ມູນ sqlite ທ້ອງຖິ່ນຢ່າງຫ້າວຫັນໃນນາມຂອງຜູ້ໃຊ້ທີ່ເລີ່ມຕົ້ນການສໍາຮອງຂໍ້ມູນ, ດັ່ງນັ້ນທ່ານຈໍາເປັນຕ້ອງຮັບປະກັນວ່າຖານຂໍ້ມູນທີ່ຕ້ອງການຖືກກໍານົດຢ່າງຖືກຕ້ອງໃນແຕ່ລະເວລາທີ່ຂະບວນການເລີ່ມຕົ້ນໂດຍໃຊ້ cli. ເມື່ອເຮັດວຽກຜ່ານ GUI ຫຼື WEBGUI, ລາຍລະອຽດຈະຖືກເຊື່ອງໄວ້ຈາກຜູ້ໃຊ້.

ໃຫ້​ເຮົາ​ເບິ່ງ​ວ່າ​ຕົວ​ຊີ້​ວັດ​ການ​ແກ້​ໄຂ​ນີ້​ສາ​ມາດ​ຜະ​ລິດ​ໄດ້​:

ຖ້າທ່ານປິດການເຂົ້າລະຫັດ (ແລະ WEBGUI ບໍ່ແນະນໍາໃຫ້ເຮັດ), ຜົນໄດ້ຮັບແມ່ນດັ່ງຕໍ່ໄປນີ້:

ເວລາເຮັດວຽກ:

ເປີດຕົວ 1
ເປີດຕົວ 2
ເປີດຕົວ 3

20m43 ວິ
20m13 ວິ
20m28 ວິ

5m21 ວິ
5m40 ວິ
5m35 ວິ

7m36 ວິ
7m54 ວິ
7m49 ວິ

ດ້ວຍການເປີດໃຊ້ການເຂົ້າລະຫັດ, ໂດຍໃຊ້ aes, ມັນເບິ່ງຄືວ່າ:

ເວລາເຮັດວຽກ:

ເປີດຕົວ 1
ເປີດຕົວ 2
ເປີດຕົວ 3

29m9 ວິ
30m1 ວິ
29m54 ວິ

5m29 ວິ
6m2 ວິ
5m54 ວິ

8m44 ວິ
9m12 ວິ
9m1 ວິ

ແລະຖ້າທ່ານໃຊ້ໂປແກຼມພາຍນອກ gnupg, ຜົນໄດ້ຮັບຕໍ່ໄປນີ້ອອກມາ:

ເປີດຕົວ 1
ເປີດຕົວ 2
ເປີດຕົວ 3

26m6 ວິ
26m35 ວິ
26m17 ວິ

5m20 ວິ
5m48 ວິ
5m40 ວິ

8m12 ວິ
8m42 ວິ
8m15 ວິ

ດັ່ງທີ່ເຈົ້າເຫັນ, ໂຄງການສາມາດເຮັດວຽກໄດ້ໃນຫຼາຍຫົວຂໍ້, ແຕ່ນີ້ບໍ່ໄດ້ເຮັດໃຫ້ມັນເປັນການແກ້ໄຂທີ່ມີປະສິດທິພາບຫຼາຍ, ແລະຖ້າທ່ານປຽບທຽບການເຮັດວຽກຂອງການເຂົ້າລະຫັດ, ມັນຈະເປີດຕົວໂຄງການພາຍນອກ.
ໄດ້ກາຍເປັນໄວກວ່າການນໍາໃຊ້ຫ້ອງສະຫມຸດຈາກຊຸດ Mono. ນີ້ອາດຈະເປັນຍ້ອນຄວາມຈິງທີ່ວ່າໂຄງການພາຍນອກຖືກປັບປຸງໃຫ້ດີທີ່ສຸດ.

ສິ່ງທີ່ດີອີກອັນຫນຶ່ງແມ່ນຄວາມຈິງທີ່ວ່າຂະຫນາດຂອງ repository ໃຊ້ເວລາຫຼາຍເທົ່າກັບຂໍ້ມູນການປ່ຽນແປງຕົວຈິງ, i.e. duplicati ກວດພົບການປ່ຽນຊື່ໄດເລກະທໍລີແລະຈັດການສະຖານະການນີ້ຢ່າງຖືກຕ້ອງ. ນີ້ສາມາດເຫັນໄດ້ໃນເວລາທີ່ແລ່ນການທົດສອບຄັ້ງທີສອງ.

ໂດຍລວມແລ້ວ, ມີຄວາມປະທັບໃຈໃນແງ່ດີຕໍ່ໂຄງການ, ລວມທັງການເປັນມິດກັບຜູ້ໃໝ່.

Результаты

ຜູ້ສະຫມັກທັງສອງເຮັດວຽກຂ້ອນຂ້າງຊ້າ, ແຕ່ໂດຍທົ່ວໄປ, ເມື່ອທຽບກັບ tar ປົກກະຕິ, ມີຄວາມຄືບຫນ້າ, ຢ່າງຫນ້ອຍກັບ duplicati. ລາຄາຂອງຄວາມຄືບຫນ້າດັ່ງກ່າວຍັງຈະແຈ້ງ - ເປັນພາລະທີ່ສັງເກດເຫັນ
ໂຮງງານຜະລິດ. ໂດຍທົ່ວໄປ, ບໍ່ມີ deviations ພິເສດໃນການຄາດຄະເນຜົນໄດ້ຮັບ.

ການຄົ້ນພົບ

ຖ້າທ່ານບໍ່ ຈຳ ເປັນຕ້ອງຮີບຮ້ອນໄປບ່ອນໃດ, ແລະຍັງມີໂປເຊດເຊີ spare, ວິທີແກ້ໄຂໃດ ໜຶ່ງ ທີ່ພິຈາລະນາກໍ່ຈະເຮັດ, ໃນກໍລະນີໃດກໍ່ຕາມ, ວຽກງານທີ່ຂ້ອນຂ້າງຫຼາຍໄດ້ຖືກເຮັດແລ້ວທີ່ບໍ່ຄວນເຮັດຊ້ໍາອີກໂດຍການຂຽນ wrapper scripts ຢູ່ເທິງສຸດຂອງ tar. . ການປະກົດຕົວຂອງການເຂົ້າລະຫັດເປັນຊັບສິນທີ່ຈໍາເປັນຫຼາຍຖ້າຫາກວ່າເຄື່ອງແມ່ຂ່າຍສໍາລັບການເກັບຮັກສາສໍາເນົາສໍາຮອງບໍ່ສາມາດເຊື່ອຖືໄດ້ຢ່າງເຕັມສ່ວນ.

ເມື່ອປຽບທຽບກັບວິທີແກ້ໄຂໂດຍອີງໃສ່ rsync - ການປະຕິບັດສາມາດຫຼາຍຄັ້ງຮ້າຍແຮງກວ່າເກົ່າ, ເຖິງວ່າຈະມີຄວາມຈິງທີ່ວ່າໃນຮູບແບບທີ່ບໍລິສຸດຂອງມັນ tar ເຮັດວຽກ 20-30% ໄວກວ່າ rsync.
ມີເງິນຝາກປະຢັດກ່ຽວກັບຂະຫນາດຂອງ repository, ແຕ່ວ່າມີພຽງແຕ່ duplicati.

ແຈ້ງການ

ການ​ສໍາ​ຮອງ​ຂໍ້​ມູນ​, ສ່ວນ​ທີ 1​: ເປັນ​ຫຍັງ​ຈຶ່ງ​ສໍາ​ຮອງ​ຂໍ້​ມູນ​, ສະ​ພາບ​ລວມ​ຂອງ​ວິ​ທີ​ການ​, ເຕັກ​ໂນ​ໂລ​ຊີ​
Backup Part 2: ການທົບທວນຄືນແລະການທົດສອບເຄື່ອງມືສໍາຮອງຂໍ້ມູນ rsync
Backup Part 3: ທົບທວນແລະທົດສອບ duplicati, duplicati, deja dup
Backup Part 4: ການທົບທວນຄືນແລະການທົດສອບ zbackup, restic, borgbackup
Backup Part 5: ການທົດສອບ bacula ແລະ veeam backup ສໍາລັບ linux
Backup Part 6: ການປຽບທຽບເຄື່ອງມື Backup
Backup Part 7: ສະຫຼຸບ

ຜູ້ຂຽນໂພສ: Pavel Demkovich

ແຫຼ່ງຂໍ້ມູນ: www.habr.com