Backup Part 6: ການປຽບທຽບເຄື່ອງມື Backup

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

ການກູ້ຄືນຂໍ້ມູນ

rsync ແລະ tar ຈະຖືກນໍາໃຊ້ເປັນຈຸດອ້າງອິງນັບຕັ້ງແຕ່ ປົກກະຕິແລ້ວແມ່ນອີງໃສ່ພວກມັນ scripts ງ່າຍດາຍສໍາລັບການເຮັດສໍາເນົາສໍາຮອງ.

Rsync ຮັບມືກັບຂໍ້ມູນການທົດສອບທີ່ກໍານົດໄວ້ໃນ 4 ນາທີ 28 ວິນາທີ, ສະແດງໃຫ້ເຫັນ

ການໂຫຼດດັ່ງກ່າວ

ຂະ​ບວນ​ການ​ຟື້ນ​ຕົວ​ໄດ້​ຕີ​ຂໍ້​ຈໍາ​ກັດ​ຂອງ​ລະ​ບົບ​ຍ່ອຍ​ແຜ່ນ​ຂອງ​ເຄື່ອງ​ແມ່​ຂ່າຍ​ການ​ເກັບ​ຮັກ​ສາ​ສໍາ​ຮອງ​ຂໍ້​ມູນ (ກາ​ຟ sawtooth​)​. ນອກນັ້ນທ່ານຍັງສາມາດເຫັນໄດ້ຊັດເຈນການໂຫຼດຂອງຫນຶ່ງ kernel ໂດຍບໍ່ມີບັນຫາໃດໆ (iowait ຕ່ໍາແລະ softirq - ບໍ່ມີບັນຫາກັບແຜ່ນແລະເຄືອຂ່າຍ, ຕາມລໍາດັບ). ເນື່ອງຈາກວ່າອີກສອງໂຄງການ, ຄື rdiff-backup ແລະ rsnapshot, ແມ່ນອີງໃສ່ rsync ແລະຍັງສະເຫນີ rsync ປົກກະຕິເປັນເຄື່ອງມືການຟື້ນຕົວ, ພວກເຂົາເຈົ້າຈະມີປະມານການໂຫຼດຂໍ້ມູນດຽວກັນແລະເວລາການຟື້ນຕົວສໍາຮອງຂໍ້ມູນ.

Tar ເຮັດໄດ້ໄວຂຶ້ນໜ້ອຍໜຶ່ງ

2 ນາທີ 43 ວິນາທີ:

ການໂຫຼດຂອງລະບົບທັງຫມົດແມ່ນສູງກວ່າໂດຍສະເລ່ຍ 20% ເນື່ອງຈາກ softirq ເພີ່ມຂຶ້ນ - ຄ່າໃຊ້ຈ່າຍຕໍ່ຫົວໃນໄລຍະການດໍາເນີນງານຂອງລະບົບຍ່ອຍເຄືອຂ່າຍເພີ່ມຂຶ້ນ.

ຖ້າຮວບຮວມຖືກບີບອັດຕື່ມອີກ, ເວລາການຟື້ນຕົວຈະເພີ່ມຂຶ້ນເປັນ 3 ນາທີ 19 ວິນາທີ.
ດ້ວຍການໂຫຼດດັ່ງກ່າວຢູ່ໃນເຊີບເວີຫຼັກ (unpacking ຢູ່ຂ້າງຂອງເຄື່ອງແມ່ຂ່າຍຕົ້ນຕໍ):

ຂະບວນການ decompression ໃຊ້ເວລາເຖິງທັງສອງແກນປະມວນຜົນເນື່ອງຈາກວ່າມີສອງຂະບວນການແລ່ນ. ໂດຍທົ່ວໄປ, ນີ້ແມ່ນຜົນໄດ້ຮັບທີ່ຄາດໄວ້. ນອກຈາກນີ້, ຜົນໄດ້ຮັບປຽບທຽບ (3 ນາທີແລະ 20 ວິນາທີ) ໄດ້ຮັບໃນເວລາທີ່ແລ່ນ gzip ໃນດ້ານເຊີຟເວີດ້ວຍການສໍາຮອງ; ໂປຣໄຟລ໌ການໂຫຼດຢູ່ໃນເຄື່ອງແມ່ຂ່າຍຕົ້ນຕໍແມ່ນຄ້າຍຄືກັນກັບການແລ່ນ tar ໂດຍບໍ່ມີເຄື່ອງອັດ gzip (ເບິ່ງເສັ້ນສະແດງກ່ອນຫນ້າ).

В rdiff-ສໍາຮອງຂໍ້ມູນ ທ່ານ​ສາ​ມາດ synchronize ການ​ສໍາ​ຮອງ​ຂໍ້​ມູນ​ສຸດ​ທ້າຍ​ທີ່​ທ່ານ​ເຮັດ​ໄດ້​ໂດຍ​ໃຊ້ rsync ປົກ​ກະ​ຕິ (ຜົນ​ໄດ້​ຮັບ​ຈະ​ຄ້າຍ​ຄື​ກັນ​)​, ແຕ່​ການ​ສໍາ​ຮອງ​ຂໍ້​ມູນ​ເກົ່າ​ຍັງ​ຈໍາ​ເປັນ​ຕ້ອງ​ໄດ້​ຮັບ​ການ​ຟື້ນ​ຟູ​ການ​ນໍາ​ໃຊ້​ໂຄງ​ການ rdiff-backup​, ເຊິ່ງ​ສໍາ​ເລັດ​ການ​ຟື້ນ​ຟູ​ໃນ 17 ນາ​ທີ​ແລະ 17 ວິ​ນາ​ທີ​, ສະ​ແດງ​ໃຫ້​ເຫັນ

ໂຫຼດນີ້:

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

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

ແຕກ ຂ້າ​ພະ​ເຈົ້າ​ສໍາ​ເລັດ​ວຽກ​ງານ​ຂອງ​ການ​ຟື້ນ​ຟູ​ສໍາ​ຮອງ​ຂໍ້​ມູນ​ໃນ 7 ນາ​ທີ​ແລະ 2 ວິ​ນາ​ທີ​ທີ່​ມີ​
ດ້ວຍການໂຫຼດນີ້:

ມັນເຮັດວຽກໄດ້ໄວ, ແລະຢ່າງ ໜ້ອຍ ກໍ່ສະດວກກວ່າ rsync ບໍລິສຸດ: ທ່ານບໍ່ ຈຳ ເປັນຕ້ອງຈື່ທຸງໃດໆ, ການໂຕ້ຕອບ cli ງ່າຍດາຍແລະ intuitive, ສະຫນັບສະຫນູນໃນຕົວສໍາລັບການສໍາເນົາຫຼາຍ - ເຖິງແມ່ນວ່າມັນຈະຊ້າກວ່າສອງເທົ່າ. ຖ້າທ່ານຕ້ອງການຟື້ນຟູຂໍ້ມູນຈາກການສໍາຮອງຄັ້ງສຸດທ້າຍທີ່ທ່ານເຮັດ, ທ່ານສາມາດນໍາໃຊ້ rsync, ໂດຍມີຂໍ້ແນະນໍາເລັກນ້ອຍ.

ໂຄງການສະແດງໃຫ້ເຫັນປະມານຄວາມໄວດຽວກັນແລະການໂຫຼດ BackupPC ໃນ​ເວ​ລາ​ທີ່​ເປີດ​ໃຊ້​ງານ​ຮູບ​ແບບ​ການ​ໂອນ rsync​, deploying ການ​ສໍາ​ຮອງ​ຂໍ້​ມູນ​ສໍາ​ລັບ​ການ​

7 ນາທີ 42 ວິນາທີ:

ແຕ່ໃນໂຫມດການໂອນຂໍ້ມູນ, BackupPC ຮັບມືກັບ tar ຊ້າກວ່າ: ໃນ 12 ນາທີແລະ 15 ວິນາທີ, ການໂຫຼດຂອງໂປເຊດເຊີໂດຍທົ່ວໄປແມ່ນຕ່ໍາ.

ເວລາຫນຶ່ງແລະເຄິ່ງຫນຶ່ງ:

ຄວາມທົນທານ ໂດຍບໍ່ມີການເຂົ້າລະຫັດສະແດງໃຫ້ເຫັນຜົນໄດ້ຮັບທີ່ດີກວ່າເລັກນ້ອຍ, ການຟື້ນຟູການສໍາຮອງຂໍ້ມູນໃນ 10 ນາທີແລະ 58 ວິນາທີ. ຖ້າທ່ານເປີດໃຊ້ການເຂົ້າລະຫັດໂດຍໃຊ້ gpg, ເວລາການຟື້ນຕົວຈະເພີ່ມຂຶ້ນເປັນ 15 ນາທີ ແລະ 3 ວິນາທີ. ນອກຈາກນີ້, ໃນເວລາທີ່ສ້າງ repository ສໍາລັບການເກັບຮັກສາສໍາເນົາ, ທ່ານສາມາດກໍານົດຂະຫນາດ archive ທີ່ຈະຖືກນໍາໃຊ້ໃນເວລາທີ່ແຍກກະແສຂໍ້ມູນຂາເຂົ້າ. ໂດຍທົ່ວໄປແລ້ວ, ໃນຮາດດິດແບບດັ້ງເດີມ, ຍັງເນື່ອງມາຈາກໂຫມດປະຕິບັດການກະທູ້ດຽວ, ບໍ່ມີຄວາມແຕກຕ່າງກັນຫຼາຍ. ມັນອາດຈະປາກົດຢູ່ໃນຂະຫນາດບລັອກທີ່ແຕກຕ່າງກັນເມື່ອການເກັບຮັກສາປະສົມຖືກນໍາໃຊ້. ການໂຫຼດຢູ່ໃນເຄື່ອງແມ່ຂ່າຍຕົ້ນຕໍໃນລະຫວ່າງການຟື້ນຕົວແມ່ນດັ່ງຕໍ່ໄປນີ້:

ບໍ່ມີການເຂົ້າລະຫັດ

ດ້ວຍການເຂົ້າລະຫັດ

ເຮັດຊ້ ຳ ສະ​ແດງ​ໃຫ້​ເຫັນ​ອັດ​ຕາ​ການ​ຟື້ນ​ຕົວ​ທີ່​ສົມ​ທຽບ​, ເຮັດ​ໃຫ້​ສໍາ​ເລັດ​ໃນ 13 ນາ​ທີ​ແລະ 45 ວິ​ນາ​ທີ​. ມັນໃຊ້ເວລາອີກປະມານ 5 ນາທີເພື່ອກວດສອບຄວາມຖືກຕ້ອງຂອງຂໍ້ມູນທີ່ຖືກກູ້ຄືນມາ (ທັງໝົດປະມານ 19 ນາທີ). ການໂຫຼດແມ່ນ

ຂ້ອນຂ້າງສູງ:

ເມື່ອການເຂົ້າລະຫັດ aes ຖືກເປີດໃຊ້ພາຍໃນ, ເວລາການຟື້ນຕົວແມ່ນ 21 ນາທີ 40 ວິນາທີ, ດ້ວຍການໃຊ້ CPU ສູງສຸດ (ທັງສອງແກນ!) ໃນລະຫວ່າງການຟື້ນຕົວ; ເມື່ອກວດເບິ່ງຂໍ້ມູນ, ມີພຽງແຕ່ກະທູ້ດຽວເທົ່ານັ້ນທີ່ເຮັດວຽກ, ຄອບຄອງຫນຶ່ງຫຼັກຂອງໂປເຊດເຊີ. ການກວດສອບຂໍ້ມູນຫຼັງຈາກການຟື້ນຕົວໃຊ້ເວລາດຽວກັນ 5 ນາທີ (ເກືອບທັງຫມົດ 27 ນາທີ).

ຜົນ

duplicati ແມ່ນໄວຂຶ້ນເລັກນ້ອຍກັບການຟື້ນຕົວໃນເວລາທີ່ການນໍາໃຊ້ໂຄງການ gpg ພາຍນອກສໍາລັບການເຂົ້າລະຫັດ, ແຕ່ໂດຍທົ່ວໄປຄວາມແຕກຕ່າງຈາກໂຫມດທີ່ຜ່ານມາແມ່ນຫນ້ອຍ. ເວລາປະຕິບັດງານແມ່ນ 16 ນາທີ 30 ວິນາທີ, ການກວດສອບຂໍ້ມູນໃນ 6 ນາທີ. ການໂຫຼດແມ່ນ

ເຊັ່ນ:

AMANDA, ການນໍາໃຊ້ tar, ສໍາເລັດມັນໃນ 2 ນາທີ 49 ວິນາທີ, ເຊິ່ງ, ໃນຫຼັກການ, ແມ່ນໃກ້ຊິດກັບ tar ປົກກະຕິ. ໂຫຼດໃນລະບົບໃນຫຼັກການ

ຄື​ກັນ:

ເມື່ອຟື້ນຟູການສໍາຮອງຂໍ້ມູນໂດຍໃຊ້ zbackup ຜົນໄດ້ຮັບຕໍ່ໄປນີ້ແມ່ນໄດ້ຮັບ:

ການເຂົ້າລະຫັດ, ການບີບອັດ lzma

ເວລາແລ່ນ 11 ນາທີ 8 ວິນາທີ

ການເຂົ້າລະຫັດ AES, ການບີບອັດ lzma

ເວລາປະຕິບັດງານ 14 ນາທີ

ການເຂົ້າລະຫັດ AES, ການບີບອັດ lzo

ໄລຍະເວລາ 6 ນາທີ 19 ວິນາທີ

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

BorgBackup ໃນຮູບແບບທີ່ບໍ່ໄດ້ເຂົ້າລະຫັດມັນຊ້າກວ່າ tar ເລັກນ້ອຍ, ໃນ 2 ນາທີ 45 ວິນາທີ, ແນວໃດກໍ່ຕາມ, ບໍ່ເຫມືອນກັບ tar, ມັນເປັນໄປໄດ້ທີ່ຈະ deduplicate repository. ການໂຫຼດໄດ້ຫັນອອກເປັນ

ຕໍ່ໄປນີ້:

ຖ້າທ່ານເປີດໃຊ້ການເຂົ້າລະຫັດແບບ blake, ຄວາມໄວການກູ້ຄືນການສຳຮອງຂໍ້ມູນຈະຊ້າລົງເລັກນ້ອຍ. ເວລາຟື້ນຕົວໃນໂຫມດນີ້ແມ່ນ 3 ນາທີ 19 ວິນາທີ, ແລະການໂຫຼດໄດ້ຫມົດໄປ

ແບບນີ້:

ການເຂົ້າລະຫັດ AES ແມ່ນຊ້າລົງເລັກນ້ອຍ, ເວລາການຟື້ນຕົວແມ່ນ 3 ນາທີ 23 ວິນາທີ, ການໂຫຼດແມ່ນໂດຍສະເພາະແມ່ນ

ບໍ່​ໄດ້​ມີ​ການ​ປ່ຽນ​ແປງ​:

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

ທີ່ຫາຍາກ ຮັບ​ມື​ກັບ​ການ​ຟື້ນ​ຕົວ​ໄດ້​ຊ້າ​ຂຶ້ນ​ພຽງ​ເລັກ​ນ້ອຍ​, ທີ່​ໃຊ້​ເວ​ລາ​ປະ​ຕິ​ບັດ​ແມ່ນ 4 ນາ​ທີ 28 ວິ​ນາ​ທີ​. ການໂຫຼດເບິ່ງຄືວ່າ

ດັ່ງນັ້ນ:

ປາກົດຂື້ນວ່າຂະບວນການຟື້ນຕົວເຮັດວຽກຢູ່ໃນຫຼາຍກະທູ້, ແຕ່ປະສິດທິພາບບໍ່ສູງເທົ່າກັບ BorgBackup, ແຕ່ສາມາດປຽບທຽບໄດ້ກັບ rsync ປົກກະຕິ.

ດ້ວຍຄວາມຊ່ວຍເຫຼືອຂອງ ສຳ ຮອງຂໍ້ມູນ ມັນເປັນໄປໄດ້ທີ່ຈະຟື້ນຟູຂໍ້ມູນໃນ 8 ນາທີແລະ 19 ວິນາທີ, ການໂຫຼດແມ່ນ

ເຊັ່ນ:

ການໂຫຼດແມ່ນຍັງບໍ່ສູງຫຼາຍ, ເຖິງແມ່ນວ່າຕ່ໍາກວ່າຂອງ tar. ໃນບາງບ່ອນມີການລະເບີດ, ແຕ່ບໍ່ມີຫຼາຍກ່ວາການໂຫຼດຂອງແກນຫນຶ່ງ.

ການ​ຄັດ​ເລືອກ​ແລະ​ຄວາມ​ຍຸດ​ຕິ​ທໍາ​ຂອງ​ມາດ​ຖານ​ສໍາ​ລັບ​ການ​ປຽບ​ທຽບ​

ດັ່ງທີ່ໄດ້ກ່າວໄວ້ໃນຫນຶ່ງໃນບົດຄວາມທີ່ຜ່ານມາ, ລະບົບສໍາຮອງຕ້ອງຕອບສະຫນອງເງື່ອນໄຂດັ່ງຕໍ່ໄປນີ້:

• ຄວາມ​ງ່າຍ​ຂອງ​ການ​ການ​ນໍາ​ໃຊ້
• Versatility
• ຄວາມ ໝັ້ນ ຄົງ
• ຄວາມວ່ອງໄວ

ມັນເປັນມູນຄ່າການພິຈາລະນາແຕ່ລະຈຸດແຍກຕ່າງຫາກໃນລາຍລະອຽດເພີ່ມເຕີມ.

ຄວາມງ່າຍຂອງການດໍາເນີນງານ

ມັນດີທີ່ສຸດເມື່ອມີປຸ່ມຫນຶ່ງ "ເຮັດທຸກຢ່າງໄດ້ດີ," ແຕ່ຖ້າທ່ານກັບຄືນໄປຫາໂຄງການທີ່ແທ້ຈິງ, ສິ່ງທີ່ສະດວກທີ່ສຸດຈະເປັນຫຼັກການການດໍາເນີນງານແລະມາດຕະຖານບາງຢ່າງ.
ຜູ້ໃຊ້ສ່ວນໃຫຍ່ອາດຈະດີກວ່າຖ້າພວກເຂົາບໍ່ ຈຳ ເປັນຕ້ອງຈື່ ຈຳ ກະແຈ ສຳ ລັບ cli, ຕັ້ງຄ່າຕົວເລືອກຕ່າງໆທີ່ແຕກຕ່າງກັນ, ມັກຈະບໍ່ຊັດເຈນຜ່ານທາງເວັບຫຼື tui, ຫຼືຕັ້ງການແຈ້ງເຕືອນກ່ຽວກັບການປະຕິບັດງານທີ່ບໍ່ປະສົບຜົນສໍາເລັດ. ນີ້ຍັງປະກອບມີຄວາມສາມາດໃນການ "ເຫມາະ" ການແກ້ໄຂການສໍາຮອງຂໍ້ມູນໄດ້ຢ່າງງ່າຍດາຍເຂົ້າໄປໃນໂຄງສ້າງພື້ນຖານທີ່ມີຢູ່ແລ້ວ, ເຊັ່ນດຽວກັນກັບອັດຕະໂນມັດຂອງຂະບວນການສໍາຮອງຂໍ້ມູນ. ນອກຈາກນີ້ຍັງມີຄວາມເປັນໄປໄດ້ຂອງການຕິດຕັ້ງໂດຍໃຊ້ຕົວຈັດການຊຸດ, ຫຼືໃນຫນຶ່ງຫຼືສອງຄໍາສັ່ງເຊັ່ນ "ດາວໂຫລດແລະ unpack". curl ссылка | sudo bash - ວິທີການສະລັບສັບຊ້ອນ, ນັບຕັ້ງແຕ່ທ່ານຈໍາເປັນຕ້ອງກວດເບິ່ງສິ່ງທີ່ມາຮອດໂດຍຜ່ານການເຊື່ອມຕໍ່.

ສໍາລັບຕົວຢ່າງ, ຂອງຜູ້ສະຫມັກພິຈາລະນາ, ການແກ້ໄຂງ່າຍໆແມ່ນ burp, rdiff-backup ແລະ restic, ທີ່ມີປຸ່ມ mnemonic ສໍາລັບຮູບແບບການເຮັດວຽກທີ່ແຕກຕ່າງກັນ. ສະລັບສັບຊ້ອນເລັກນ້ອຍຫຼາຍແມ່ນ borg ແລະ duplicity. ຄວາມຫຍຸ້ງຍາກທີ່ສຸດແມ່ນ AMANDA. ສ່ວນທີ່ເຫຼືອແມ່ນບາງບ່ອນຢູ່ກາງໃນແງ່ຂອງຄວາມສະດວກໃນການນໍາໃຊ້. ໃນກໍລະນີໃດກໍ່ຕາມ, ຖ້າທ່ານຕ້ອງການຫຼາຍກວ່າ 30 ວິນາທີເພື່ອອ່ານຄູ່ມືຜູ້ໃຊ້, ຫຼືທ່ານຈໍາເປັນຕ້ອງໄປຫາ Google ຫຼືເຄື່ອງຈັກຊອກຫາອື່ນ, ແລະຍັງເລື່ອນຜ່ານເອກະສານຍາວຂອງການຊ່ວຍເຫຼືອ, ການຕັດສິນໃຈແມ່ນມີຄວາມຫຍຸ້ງຍາກ, ວິທີການຫນຶ່ງຫຼືອື່ນ.

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

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

Versatility

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

ເປັນສັນຍານ - ຄວາມສາມາດໃນການເຮັດວຽກໂດຍໃຊ້ ssh ປົກກະຕິ.

ຄວາມໄວໃນການເຮັດວຽກ

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

ຄວາມ ໝັ້ນ ຄົງ

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

ການປຽບທຽບເຄື່ອງມືສໍາຮອງ

ສຳເນົາເວລາສ້າງ
ສຳເນົາເວລາການກູ້ຂໍ້ມູນ
ຕິດຕັ້ງງ່າຍ
ຕິດຕັ້ງງ່າຍ
ການ ນຳ ໃຊ້ງ່າຍດາຍ
ອັດຕະໂນມັດແບບງ່າຍດາຍ
ທ່ານຕ້ອງການເຄື່ອງແມ່ຂ່າຍຂອງລູກຄ້າບໍ?
ການກວດສອບຄວາມສົມບູນຂອງ repository
ສຳເນົາທີ່ແຕກຕ່າງ
ເຮັດວຽກຜ່ານທໍ່
Versatility
ເອ​ກະ​ລາດ
ຄວາມໂປ່ງໃສຂອງບ່ອນເກັບມ້ຽນ
ການເຂົ້າລະຫັດ
ການບີບອັດ
ການຍົກເລີກການຊໍ້າຊ້ອນ
ການໂຕ້ຕອບເວັບ
ຕື່ມໃສ່ເມຄ
ຮອງຮັບ Windows
ຈຸດ

Rsync
4m15 ວິ
4m28 ວິ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ບໍ່​ມີ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ບໍ່​ມີ
ບໍ່​ມີ
ບໍ່​ມີ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
6

Tar
ບໍລິສຸດ
3m12 ວິ
2m43 ວິ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ບໍ່​ມີ
ບໍ່​ມີ
ບໍ່​ມີ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ບໍ່​ມີ
ບໍ່​ມີ
ບໍ່​ມີ
ບໍ່​ມີ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
8,5

gzip
9m37 ວິ
3m19 ວິ
ແມ່ນ​ແລ້ວ

Rdiff-ສໍາຮອງຂໍ້ມູນ
16m26 ວິ
17m17 ວິ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
11

ພາບຖ່າຍ
4m19 ວິ
4m28 ວິ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
12,5

ແຕກ
11m9 ວິ
7m2 ວິ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
10,5

ຄວາມທົນທານ
ບໍ່ມີການເຂົ້າລະຫັດ
16m48 ວິ
10m58 ວິ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
11

gpg
17m27 ວິ
15m3 ວິ

ເຮັດຊ້ ຳ
ບໍ່ມີການເຂົ້າລະຫັດ
20m28 ວິ
13m45 ວິ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ບໍ່​ມີ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
11

aes
29m41 ວິ
21m40 ວິ

gpg
26m19 ວິ
16m30 ວິ

ສຳ ຮອງຂໍ້ມູນ
ບໍ່ມີການເຂົ້າລະຫັດ
40m3 ວິ
11m8 ວິ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ບໍ່​ມີ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ບໍ່​ມີ
ບໍ່​ມີ
10

aes
42m0 ວິ
14m1 ວິ

aes+lzo
18m9 ວິ
6m19 ວິ

BorgBackup
ບໍ່ມີການເຂົ້າລະຫັດ
4m7 ວິ
2m45 ວິ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
16

aes
4m58 ວິ
3m23 ວິ

blake2
4m39 ວິ
3m19 ວິ

ທີ່ຫາຍາກ
5m38 ວິ
4m28 ວິ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
15,5

ສຳ ຮອງຂໍ້ມູນ
8m21 ວິ
8m19 ວິ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
12

Amanda
9m3 ວິ
2m49 ວິ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
13

BackupPC
rsync
12m22 ວິ
7m42 ວິ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
ບໍ່​ມີ
ແມ່ນ​ແລ້ວ
10,5

tar
12m34 ວິ
12m15 ວິ

ຄວາມຫມາຍຕາຕະລາງ:

• ສີຂຽວ, ເວລາປະຕິບັດງານຫນ້ອຍກວ່າຫ້ານາທີ, ຫຼືຕອບ "ແມ່ນ" (ຍົກເວັ້ນຖັນ "ຕ້ອງການເຄື່ອງແມ່ຂ່າຍຂອງລູກຄ້າບໍ?"), 1 ຈຸດ
• ສີເຫຼືອງ, ເວລາປະຕິບັດງານຫ້າຫາສິບນາທີ, 0.5 ຈຸດ
• ສີແດງ, ເວລາເຮັດວຽກແມ່ນຫຼາຍກວ່າສິບນາທີ, ຫຼືຄໍາຕອບແມ່ນ "ບໍ່" (ຍົກເວັ້ນຖັນ "ທ່ານຕ້ອງການເຄື່ອງແມ່ຂ່າຍຂອງລູກຄ້າບໍ?"), 0 ຄະແນນ

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

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

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

ແຈ້ງການ

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

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