Capacity Tier (ຫຼືທີ່ພວກເຮົາເອີ້ນວ່າມັນພາຍໃນ Vim - captir) ປາກົດຢູ່ໃນມື້ຂອງ Veeam Backup ແລະ Replication 9.5 Update 4 ພາຍໃຕ້ຊື່ Archive Tier. ແນວຄວາມຄິດທີ່ຢູ່ເບື້ອງຫລັງແມ່ນເພື່ອເຮັດໃຫ້ມັນເປັນໄປໄດ້ທີ່ຈະຍ້າຍການສໍາຮອງຂໍ້ມູນທີ່ຫຼຸດລົງອອກຈາກອັນທີ່ເອີ້ນວ່າປ່ອງຢ້ຽມການຟື້ນຟູການດໍາເນີນງານໄປສູ່ການເກັບຮັກສາວັດຖຸ. ອັນນີ້ຊ່ວຍລ້າງພື້ນທີ່ດິສກ໌ໃຫ້ກັບຜູ້ໃຊ້ທີ່ມີໜ້ອຍ. ແລະທາງເລືອກນີ້ເອີ້ນວ່າ Move Mode.

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

ແຕ່ໃນ VBR v10, ແນວຄວາມຄິດໄດ້ຖືກເສີມດ້ວຍຫນ້າທີ່ໃຫມ່ - ຮູບແບບການຄັດລອກ, ຮູບແບບການຜະນຶກແລະສິ່ງທີ່ມີຄວາມຫຍຸ້ງຍາກໃນການອອກສຽງຊື່ Immutability ປາກົດ.

ນີ້ແມ່ນສິ່ງທີ່ ໜ້າ ສົນໃຈທີ່ພວກເຮົາຈະເວົ້າກ່ຽວກັບມື້ນີ້. ຫນ້າທໍາອິດ, ກ່ຽວກັບວິທີທີ່ມັນເຮັດວຽກຢູ່ໃນ VBR9.5u4, ແລະຫຼັງຈາກນັ້ນກ່ຽວກັບການປ່ຽນແປງໃນສະບັບທີສິບ.

ແລະ​ຂໍ​ໃຫ້​ຜູ້​ອ່ານ​ພາ​ສາ​ທີ່​ບໍ​ລິ​ສຸດ​ອະ​ໄພ​ໃຫ້​ຂ້າ​ພະ​ເຈົ້າ, ແຕ່​ວ່າ​ມີ​ຫຼາຍ​ຄໍາ​ສັບ​ທີ່​ບໍ່​ສາ​ມາດ​ແປ​ໄດ້.
ດັ່ງນັ້ນຈະມີ Anglicisms ຫຼາຍໂຕນຢູ່ທີ່ນີ້.
ແລະຫຼາຍ gifs.
ແລະຮູບພາບ.

• ໂດຍບໍ່ມີການເສຍໃຈເລັກນ້ອຍ. ຜູ້ຂຽນບົດຄວາມ.

ດັ່ງທີ່ເຄີຍເປັນ

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

ດັ່ງທີ່ພວກເຮົາເຫັນຢູ່ໃນຮູບ, ພວກເຮົາມີປະເພດຂອງລະບົບຕ່ອງໂສ້ການສໍາຮອງຂໍ້ມູນທີ່ມີຕັນຂໍ້ມູນ, ເຊິ່ງຕັ້ງຢູ່ໃນ SOBR ຊັ້ນປະສິດທິພາບຂອງ repository ທີ່ Capacity Tier ແມ່ນເຊື່ອມຕໍ່. ປ່ອງ​ຢ້ຽມ​ສໍາ​ຮອງ​ຂໍ້​ມູນ​ການ​ດໍາ​ເນີນ​ງານ​ຂອງ​ພວກ​ເຮົາ​ແມ່ນ​ສາມ​ມື້​.

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

ແຕ່ສິ່ງທີ່ແນ່ນອນແມ່ນຫມາຍຄວາມວ່າໂດຍລະບົບຕ່ອງໂສ້ຜະນຶກເຂົ້າກັນແລະສິ່ງທີ່ສາມາດຖືກສົ່ງໄປຫາລະດັບຄວາມອາດສາມາດຍິງໃນການປັບປຸງ 4?

Forward Incremental, ສັນຍານຂອງການປິດຕ່ອງໂສ້ແມ່ນການສ້າງການສໍາຮອງຂໍ້ມູນຢ່າງເຕັມທີ່ໃຫມ່. ແລະມັນບໍ່ສໍາຄັນແນວໃດວ່າການສໍາຮອງຂໍ້ມູນຢ່າງເຕັມທີ່ນີ້ແມ່ນໄດ້ຮັບ: ທັງການສໍາຮອງເຕັມທີ່ສັງເຄາະແລະການເຄື່ອນໄຫວຢ່າງເຕັມທີ່ຖືກພິຈາລະນາ.

ໃນກໍລະນີຂອງ Reverse, ເຫຼົ່ານີ້ແມ່ນໄຟລ໌ທັງຫມົດທີ່ບໍ່ຕົກຢູ່ໃນປ່ອງຢ້ຽມປະຕິບັດງານ.

ໃນກໍລະນີຂອງການເພີ່ມຂຶ້ນ Forward ກັບ rollbacks, ເຫຼົ່ານີ້ແມ່ນ rollbacks ທັງຫມົດແລະ .vbk, ຖ້າມີ .vbk ອື່ນໃນຂອບເຂດການປະຕິບັດ.

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

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

ໃຫ້ພວກເຮົາເບິ່ງວ່າອັນນີ້ມີລັກສະນະແນວໃດກັບຕົວຢ່າງ: ໃຫ້ເວົ້າວ່າພວກເຮົາມີ .vbk ທີ່ອອກມາຈາກປ່ອງຢ້ຽມການເຮັດທຸລະກໍາແລະເປັນຂອງຕ່ອງໂສ້ທີ່ຜະນຶກເຂົ້າກັນ. ນີ້ຫມາຍຄວາມວ່າພວກເຮົາມີສິດທີ່ຈະຍ້າຍມັນໄປຫາລະດັບຄວາມອາດສາມາດຍິງໄດ້. ໃນເວລາທີ່ການເຄື່ອນຍ້າຍ, ໄຟລ໌ metadata ຖືກສ້າງຂຶ້ນໃນ dash ຄວາມອາດສາມາດແລະຕັນຂອງໄຟລ໌ທີ່ຖືກໂອນ. ໄຟລ໌ metadata ລະດັບການເຊື່ອມໂຍງອະທິບາຍສິ່ງທີ່ບລັອກໄຟລ໌ຂອງພວກເຮົາປະກອບດ້ວຍ. ໃນກໍລະນີໃນຮູບ, ໄຟລ໌ທໍາອິດຂອງພວກເຮົາປະກອບດ້ວຍຕັນ a, b, c ແລະ metadata ມີການເຊື່ອມຕໍ່ກັບຕັນເຫຼົ່ານີ້. ເມື່ອພວກເຮົາມີໄຟລ໌ .vbk ທີສອງ, ພ້ອມທີ່ຈະຍ້າຍອອກແລະປະກອບດ້ວຍບລັອກ a, b ແລະ d, ພວກເຮົາ, ການວິເຄາະດັດຊະນີການຂາດນ້ໍາ, ເຂົ້າໃຈວ່າພຽງແຕ່ block d ຕ້ອງໄດ້ຮັບການໂອນ. ແລະໄຟລ໌ metadata ຂອງມັນຈະມີການເຊື່ອມຕໍ່ກັບສອງບລັອກທີ່ຜ່ານມາແລະຫນຶ່ງໃຫມ່.

ຕາມນັ້ນແລ້ວ, ຂະບວນການຕື່ມຂໍ້ມູນໃສ່ພື້ນທີ່ຫວ່າງເປົ່າເຫຼົ່ານີ້ ເອີ້ນວ່າການເຕີມນໍ້າ. ມັນໃຊ້ດັດຊະນີການລະບາຍນ້ໍາຂອງຕົນເອງແລ້ວ, ໂດຍອີງໃສ່ໄຟລ໌ .vbk ທີ່ເກົ່າແກ່ທີ່ສຸດຢູ່ໃນຂອບເຂດການປະຕິບັດໃນທ້ອງຖິ່ນ. ນັ້ນແມ່ນ, ຖ້າຜູ້ໃຊ້ຕ້ອງການສົ່ງຄືນໄຟລ໌ຈາກລະດັບຄວາມອາດສາມາດ, ພວກເຮົາທໍາອິດສ້າງດັດສະນີຂອງບລັອກຂອງ backup ເຕັມທີ່ເກົ່າແກ່ທີ່ສຸດແລະໂອນພຽງແຕ່ບລັອກທີ່ຂາດຫາຍໄປຈາກຄັງຍິງຄວາມສາມາດ. ໃນກໍລະນີທີ່ນໍາສະເຫນີໃນຮູບ, ເພື່ອ rehydrate FullBackup1.vbk ຕາມດັດຊະນີ rehydration, ພວກເຮົາພຽງແຕ່ຕ້ອງການ block C, ທີ່ພວກເຮົາເອົາຈາກລະດັບຄວາມອາດສາມາດຍິງໄດ້. ຖ້າວັດຖຸຟັງຄລາວທີ່ເກັບມ້ຽນເປັນຂອບເຂດການຍິງ, ນີ້ຊ່ວຍໃຫ້ທ່ານປະຫຍັດເງິນຈໍານວນຫຼວງຫຼາຍ.

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

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

ມັນເກີດຂຶ້ນໄດ້ແນວໃດ?

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

ຮູບແບບການສໍາເນົາ

ມັນສ່ວນໃຫຍ່ແມ່ນອີງໃສ່ເຕັກໂນໂລຢີທີ່ມີຢູ່, ແຕ່ມີເຫດຜົນຂອງການນໍາໃຊ້ທີ່ແຕກຕ່າງກັນຫມົດ. 

ຈຸດປະສົງຂອງຮູບແບບນີ້ແມ່ນເພື່ອຮັບປະກັນວ່າຂໍ້ມູນທັງຫມົດທີ່ຢູ່ໃນຂອບເຂດທ້ອງຖິ່ນມີສໍາເນົາຢູ່ໃນ dash ຄວາມອາດສາມາດ.

ຖ້າ​ຫາກ​ທ່ານ​ສົມ​ທຽບ​ການ​ເຄື່ອນ​ໄຫວ​ແລະ​ການ​ສໍາ​ເນົາ​ເອົາ​ຫົວ​ຫນ້າ​ຂອງ​ຮູບ​ແບບ​, ມັນ​ຈະ​ເປັນ​ດັ່ງ​ນີ້​:

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

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

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

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

ຄໍາຖາມທີ່ເກີດຂື້ນ - ຖ້າທ່ານເບິ່ງ UI, ມີໂອກາດທີ່ຈະເລືອກເອົາທັງສອງທາງເລືອກໃນເວລາດຽວກັນ. ຮູບແບບການລວມກັນດັ່ງກ່າວຈະເຮັດວຽກແນວໃດ?

ໃຫ້ຄິດໄລ່ອອກ.

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

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

ເປັນຫຍັງພວກເຮົາຕ້ອງການຮູບແບບການຄັດລອກນີ້?

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

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

ສະນັ້ນໃຫ້ຜ່ານສະຖານະການທີ່ເປັນໄປໄດ້, ຈາກງ່າຍດາຍທີ່ສຸດໄປຫາສະລັບສັບຊ້ອນຫຼາຍ.

ຄວາມໂຊກຮ້າຍທີ່ງ່າຍດາຍທີ່ສຸດທີ່ສາມາດຕົກຢູ່ໃນຫົວຂອງພວກເຮົາແມ່ນຄວາມບໍ່ສາມາດເຂົ້າເຖິງໄຟລ໌ຫນຶ່ງໃນລະບົບຕ່ອງໂສ້ການສໍາຮອງຂໍ້ມູນ.

ເລື່ອງທີ່ໂສກເສົ້າແມ່ນວ່າຫນຶ່ງໃນຂອບເຂດຂອງບ່ອນເກັບມ້ຽນ SOBR ຂອງພວກເຮົາແຕກຫັກ.

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

ຕອນນີ້ໃຫ້ເບິ່ງແຕ່ລະສະຖານະການແຍກຕ່າງຫາກ.

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

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

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

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

ແລະສະຖານະການທີ່ຫນ້າສົນໃຈທີ່ສຸດແມ່ນວ່າເຄື່ອງແມ່ຂ່າຍສໍາຮອງຂໍ້ມູນໄດ້ເສຍຊີວິດ. ມີສອງທາງເລືອກຢູ່ທີ່ນີ້: admin ແມ່ນດີເລີດແລະເຮັດການສໍາຮອງຂໍ້ມູນການຕັ້ງຄ່າ, ແລະ admin ແມ່ນ Pinocchio ທີ່ຊົ່ວຮ້າຍຂອງຕົນເອງແລະບໍ່ໄດ້ເຮັດການສໍາຮອງຂໍ້ມູນການຕັ້ງຄ່າ.

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

ແຕ່ຖ້າ admin ເປັນສັດຕູຂອງຕົນເອງ, ຫຼືການສໍາຮອງຂໍ້ມູນການຕັ້ງຄ່າຍັງປະສົບກັບຄວາມລົ້ມເຫຼວຂອງ epic, ເຖິງແມ່ນວ່າໃນທີ່ນີ້ພວກເຮົາຈະບໍ່ປ່ອຍໃຫ້ລາວຢູ່ໃນຄວາມເມດຕາຂອງໂຊກຊະຕາ. ສໍາລັບກໍລະນີນີ້, ພວກເຮົາໄດ້ແນະນໍາຂັ້ນຕອນໃຫມ່ທີ່ເອີ້ນວ່າ Import Object Storage. ມັນອະນຸຍາດໃຫ້ທ່ານຂ້າມຂະບວນການສ້າງບ່ອນເກັບມ້ຽນ SOBR ດ້ວຍຕົນເອງແລະຄັດຕິດລະດັບຄວາມອາດສາມາດໃນການຖ່າຍຮູບກັບມັນດ້ວຍການສະແກນໃຫມ່ຕໍ່ມາ, ແລະພຽງແຕ່ເພີ່ມວັດຖຸເກັບຮັກສາໄວ້ໃນການໂຕ້ຕອບ Vim ແລະດໍາເນີນການຂັ້ນຕອນການເກັບຮັກສາການນໍາເຂົ້າ. ສິ່ງດຽວທີ່ສາມາດຢືນຢູ່ໃນວິທີການລະຫວ່າງທ່ານແລະການສໍາຮອງຂໍ້ມູນຂອງທ່ານແມ່ນການຮ້ອງຂໍໃຫ້ໃສ່ລະຫັດຜ່ານຖ້າຫາກວ່າສໍາຮອງຂໍ້ມູນຂອງທ່ານໄດ້ຖືກເຂົ້າລະຫັດ.

ນີ້ອາດຈະເປັນທັງຫມົດກ່ຽວກັບການຄັດລອກຮູບແບບແລະພວກເຮົາຍ້າຍໄປ

ໂໝດປິດ

ແນວຄວາມຄິດຕົ້ນຕໍແມ່ນວ່າການສໍາຮອງຂໍ້ມູນໃຫມ່ບໍ່ສາມາດປາກົດຢູ່ໃນຂອບເຂດ SOBR ທີ່ເລືອກຂອງ repository. ກ່ອນທີ່ຈະ v10, ພວກເຮົາມີພຽງແຕ່ໂຫມດບໍາລຸງຮັກສາ, ໃນເວລາທີ່ການເຮັດວຽກໃດໆກັບ repository ໄດ້ຖືກຫ້າມຢ່າງສົມບູນ. ປະເພດຂອງໂຫມດ hardcore ສໍາລັບການປິດການເກັບຮັກສາ, ບ່ອນທີ່ມີພຽງແຕ່ປຸ່ມ Evacuate, ເຊິ່ງການຂົນສົ່ງສໍາຮອງຂໍ້ມູນໃນຂອບເຂດອື່ນໃນຫນຶ່ງຄັ້ງ.

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

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

ທັງສອງໂຫມດສາມາດຖືກນໍາໃຊ້ພ້ອມກັນ, ແຕ່ຈື່ໄວ້ວ່າການບໍາລຸງຮັກສາມີຄວາມສໍາຄັນສູງກວ່າ.

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

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

ສິ່ງຕ່າງໆແມ່ນງ່າຍດາຍກວ່າດ້ວຍ Reverse Incremental. ໃນມັນ, ຈຸດເກົ່າແກ່ທີ່ສຸດບໍ່ຂຶ້ນກັບສິ່ງໃດແລະສາມາດຖືກລົບອອກໄດ້ຢ່າງປອດໄພ. ດັ່ງນັ້ນ, ທັນທີທີ່ .vbk ໃຫມ່ຖືກສ້າງຂື້ນໃນຂອບເຂດໃຫມ່, .vrbs ເກົ່າຈະຖືກລຶບເທື່ອລະອັນ.

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

ສິ່ງຕ່າງໆແມ່ນສັບສົນກວ່າກັບລະດັບຄວາມອາດສາມາດຍິງ.

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

ປະມານສິ່ງດຽວກັນເກີດຂຶ້ນໃນໂຫມດເຄື່ອນທີ່ - ພວກເຮົາລໍຖ້າ retouch, ລຶບອັນເກົ່າຢູ່ໃນບ່ອນເກັບມ້ຽນ, ແລະລຶບສິ່ງທີ່ເກັບໄວ້ໃນບ່ອນເກັບມ້ຽນວັດຖຸ.

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

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

ໂດຍພື້ນຖານແລ້ວນັ້ນແມ່ນທັງໝົດຂອງມັນ. ສະນັ້ນໃຫ້ພວກເຮົາກ້າວໄປສູ່ລັກສະນະທີ່ຍາກທີ່ສຸດ -

ຄວາມບໍ່ສາມາດຕ້ານທານໄດ້

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

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

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

ແນວຄວາມຄິດທັງໝົດທີ່ໄດ້ອະທິບາຍໄວ້ກ່ອນໜ້ານີ້ກ່ຽວກັບການຂາດນໍ້າ, ດັດຊະນີ ແລະເມຕາເດຕາຍັງສືບຕໍ່ເຮັດວຽກຄືກັນ. ແຕ່ມີເງື່ອນໄຂຫນຶ່ງ - ຕັນຖືກກໍານົດບໍ່ພຽງແຕ່ສໍາລັບຂໍ້ມູນ, ແຕ່ຍັງສໍາລັບ metadata. ນີ້ແມ່ນເຮັດໄດ້ໃນກໍລະນີທີ່ຜູ້ໂຈມຕີທີ່ມີສະຕິປັນຍາຕັດສິນໃຈທີ່ຈະລຶບຖານຂໍ້ມູນ metadata ຂອງພວກເຮົາແລະປ້ອງກັນການສະກັດຂໍ້ມູນຈາກການປ່ຽນເປັນ mush binary ທີ່ບໍ່ມີປະໂຫຍດ.

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

ໃຫ້ໃຊ້ເວລາຂະຫນາດຂອງຫົກມື້ແລະຂ້າງລຸ່ມນີ້ພວກເຮົາຈະຫມາຍເວລາທີ່ຄາດວ່າຈະຫມົດອາຍຸຂອງ immutability. ໃນມື້ທໍາອິດທີ່ພວກເຮົາເອົາແລະສ້າງໄຟລ໌ທີ່ປະກອບດ້ວຍຂໍ້ມູນ block a ແລະ metadata ຂອງມັນ. ຖ້າຄວາມບໍ່ສາມາດປ່ຽນແປງໄດ້ຖືກກໍານົດເປັນສາມມື້, ມັນເປັນເຫດຜົນທີ່ຈະສົມມຸດວ່າໃນວັນທີສີ່ຂໍ້ມູນຈະຖືກປົດລັອກແລະລຶບຖິ້ມ. ໃນມື້ທີສອງພວກເຮົາຈະເພີ່ມໄຟລ໌ໃຫມ່ 2, ປະກອບດ້ວຍຕັນ b ທີ່ມີການຕັ້ງຄ່າດຽວກັນ. ຕັນຍັງຈໍາເປັນຕ້ອງໄດ້ໂຍກຍ້າຍອອກໃນວັນທີສີ່. ແຕ່ໃນມື້ທີສາມ, ບາງສິ່ງບາງຢ່າງທີ່ຂີ້ຮ້າຍເກີດຂຶ້ນ - ໄຟລ໌ File3 ຖືກສ້າງຂື້ນ, ປະກອບດ້ວຍ block d ໃຫມ່ແລະການເຊື່ອມຕໍ່ກັບ block a ເກົ່າ. ນີ້ຫມາຍຄວາມວ່າສໍາລັບຕັນແລະທຸງ immutability ຂອງຕົນຕ້ອງໄດ້ຮັບການ reset ກັບວັນທີໃຫມ່, ເຊິ່ງໄດ້ຍ້າຍໄປວັນທີຫົກ. ແລະໃນທີ່ນີ້ບັນຫາເກີດຂຶ້ນ - ໃນການສໍາຮອງຂໍ້ມູນທີ່ແທ້ຈິງມີຈໍານວນຂະຫນາດໃຫຍ່ຂອງຕັນດັ່ງກ່າວ. ແລະເພື່ອຂະຫຍາຍໄລຍະເວລາທີ່ບໍ່ສາມາດປ່ຽນແປງໄດ້, ທ່ານ ຈຳ ເປັນຕ້ອງເຮັດການຮ້ອງຂໍ ຈຳ ນວນຫຼວງຫຼາຍໃນແຕ່ລະຄັ້ງ. ແລະໃນຄວາມເປັນຈິງ, ນີ້ຈະເປັນຂະບວນການປະຈໍາວັນເກືອບບໍ່ມີທີ່ສິ້ນສຸດ, ເນື່ອງຈາກວ່າມີລະດັບສູງຂອງຄວາມເປັນໄປໄດ້ທີ່ພວກເຮົາຈະຊອກຫາ stacks hefty ຂອງຕັນ deduplicated ກັບແຕ່ລະສໍາເນົາ. ການຮ້ອງຂໍຈໍານວນຫລາຍຈາກຜູ້ໃຫ້ບໍລິການເກັບຮັກສາວັດຖຸຫມາຍຄວາມວ່າແນວໃດ? ສິດ! ໃບເກັບເງິນໃຫຍ່ໃນທ້າຍເດືອນ.

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

ໃຫ້ສືບຕໍ່ພິຈາລະນາສະຖານະການດຽວກັນ, ແຕ່ກັບການຜະລິດຕັນ. ໃນມື້ທໍາອິດທີ່ພວກເຮົາສ້າງ file1 ຈາກ block a ແລະ metadata. ພວກເຮົາເພີ່ມໄລຍະເວລາການຜະລິດແລະຄວາມບໍ່ປ່ຽນແປງ - ນີ້ຫມາຍຄວາມວ່າໂອກາດທີ່ຈະລຶບໄຟລ໌ຈະຢູ່ໃນວັນທີຫົກ. ຖ້າໃນມື້ທີສອງພວກເຮົາສ້າງ File2, ປະກອບດ້ວຍບລັອກ b ແລະການເຊື່ອມຕໍ່ເພື່ອບລັອກ a, ຫຼັງຈາກນັ້ນບໍ່ມີຫຍັງເກີດຂຶ້ນກັບວັນທີລຶບທີ່ຄາດໄວ້. ນາງ​ຢືນ​ດັ່ງ​ທີ່​ນາງ​ໄດ້​ເຮັດ​ໃນ​ວັນ​ທີ​ຫົກ. ແລະດັ່ງນັ້ນພວກເຮົາກໍາລັງພະຍາຍາມປະຫຍັດເງິນໃນຈໍານວນຄໍາຮ້ອງຂໍ. ສະຖານະການພຽງແຕ່ໃນເວລາທີ່ເສັ້ນຕາຍສາມາດປ່ຽນໄດ້ແມ່ນຖ້າໄລຍະເວລາການຜະລິດຫມົດອາຍຸ. ນັ້ນແມ່ນ, ຖ້າໃນມື້ທີສາມ, File3 ໃຫມ່ມີການເຊື່ອມຕໍ່ເພື່ອສະກັດ a, ຫຼັງຈາກນັ້ນ, ຮຸ່ນ 2 ຈະຖືກເພີ່ມນັບຕັ້ງແຕ່ Gen1 ໄດ້ຫມົດອາຍຸແລ້ວ. ແລະວັນທີທີ່ຄາດວ່າຈະລຶບບລັອກ a ຈະປ່ຽນເປັນມື້ທີແປດ. ນີ້ອະນຸຍາດໃຫ້ພວກເຮົາຫຼຸດລົງຢ່າງຫຼວງຫຼາຍຈໍານວນຂອງການຮ້ອງຂໍເພື່ອຂະຫຍາຍອາຍຸຂອງຕັນ deduplicated, ເຊິ່ງຊ່ວຍປະຢັດລູກຄ້າເປັນໂຕນຂອງເງິນ.

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

ແລະ, ຕາມປົກກະຕິ, ບາງການເຊື່ອມຕໍ່ທີ່ເປັນປະໂຫຍດ:

• ກ່ຽວກັບ ການສ້າງຕັນ ໃນ​ທຸກ​ລາຍ​ລະ​ອຽດ​.
• ຂໍ້​ມູນ​ທັງ​ຫມົດ​ກ່ຽວ​ກັບ Veeam Backup & Replication 10 ດີທີ່ສຸດ
• О ລະດັບຄວາມອາດສາມາດ ໃນລາຍລະອຽດ

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