Backup ທີ່ກູ້ຄືນໄດ້ແທ້: ທົດສອບກ່ອນມື້ທີ່ຈຳເປັນ

ຄຳຖາມທີ່ພວກເຮົາໄດ້ຍິນຕົວຈິງ

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

ເປັນຫຍັງ backup ຈຶ່ງຫຼົ້ມເຫຼວຕອນກູ້ຄືນຕົວຈິງ

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

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

ສອງ, ຂໍ້ມູນສຳຮອງຖືກທຳລາຍໄປພ້ອມກັບຕົ້ນສະບັບ. NAS ທີ່ວາງໄວ້ຂ້າງເຊີບເວີກໍຈົມນ້ຳຖ້ວມຄັ້ງດຽວກັນ, ໄໝ້ໄຟຄັ້ງດຽວກັນ, ແລະ ຖືກເຂົ້າລະຫັດໂດຍ ransomware ໂຕດຽວກັນທີ່ແຜ່ລາມຜ່ານເຄືອຂ່າຍ. ຮາດດິສ USB ທີ່ບໍ່ເຄີຍສັບປ່ຽນໝູນວຽນກໍຈະມີພຽງສຳເນົາເກົ່າຊຸດດຽວ ຖ້າມັນຍັງໃຊ້ໄດ້ຢູ່. ການ sync ໄຟລ໌ຂຶ້ນ cloud ກໍບໍ່ແມ່ນການ backup ເຊັ່ນກັນ: ເມື່ອ ransomware ປ່ຽນຊື່ໄຟລ໌ຂອງທ່ານ, ໂປຣແກຣມ sync ກໍຈະອັບໂຫຼດໄຟລ໌ທີ່ຖືກປ່ຽນຊື່ນັ້ນຂຶ້ນໄປພາຍໃນບໍ່ເທົ່າໃດນາທີ. ສຳລັບຄວາມແຕກຕ່າງລະຫວ່າງການ sync ກັບການ backup, ເບິ່ງໄດ້ທີ່ ກົດການສຳຮອງຂໍ້ມູນ 3-2-1 ຂອງພວກເຮົາ.

ສາມ, ຄວາມສົມບູນຂອງຖານຂໍ້ມູນ (database consistency). ການກ໊ອບປີ້ໄຟລ໌ຂອງຖານຂໍ້ມູນບັນຊີ ຫຼື ສາງສິນຄ້າ ໃນຂະນະທີ່ມັນກຳລັງເຮັດວຽກຢູ່ ມັກຈະໄດ້ຊຸດໄຟລ໌ທີ່ບໍ່ສາມາດເປີດຂຶ້ນມາໄດ້ເມື່ອກູ້ຄືນ. ຖານຂໍ້ມູນຕ້ອງການວິທີ backup ສະເພາະຂອງມັນເອງ, ເຊັ່ນ: ຄຳສັ່ງ dump ໃນຕົວ ຫຼື agent ທີ່ເຊື່ອມຕໍ່ກັບ database engine ໂດຍກົງ, ຕາມດ້ວຍການທົດສອບລ໊ອກອິນ.

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

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

RPO ແລະ RTO ແບບເຂົ້າໃຈງ່າຍ

ຄຳສັບສັ້ນໆ ສອງຄຳນີ້ເປັນຕົວກຳນົດການອອກແບບລະບົບ backup ທັງໝົດຂອງທ່ານ, ດັ່ງນັ້ນ ມາທຳຄວາມເຂົ້າໃຈຜ່ານຕົວຢ່າງກັນເລີຍ.

RPO (recovery point objective) ຕອບຄຳຖາມວ່າ: ພວກເຮົາຍອມເສຍວຽກທີ່ເຮັດໄປແລ້ວໄດ້ຫຼາຍປານໃດ? RPO ໜຶ່ງມື້ ໝາຍຄວາມວ່າຂໍ້ມູນສຳຮອງຂອງຄືນວານນີ້ແມ່ນພຽງພໍແລ້ວ, ແລະ ການຄີຂໍ້ມູນຂອງມື້ນີ້ໃໝ່ດ້ວຍມືແມ່ນຍອມຮັບໄດ້. RPO ໜຶ່ງຊົ່ວໂມງ ໝາຍຄວາມວ່າທ່ານຕ້ອງມີການສຳຮອງຂໍ້ມູນທຸກໆ ຊົ່ວໂມງ, ເພາະການເສຍຂໍ້ມູນໃບບິນຕະຫຼອດຕອນເຊົ້າຂອງຮ້ານທີ່ວຽກຫຍຸ້ງນັ້ນສ້າງຄວາມເສຍຫາຍຫຼາຍ. RPO ຍິ່ງສັ້ນ ໝາຍເຖິງການແລ່ນ backup ທີ່ຖີ່ຂຶ້ນ ແລະ ໃຊ້ພື້ນທີ່ຈັດເກັບຫຼາຍຂຶ້ນ.

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

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

ການທົດສອບຫ້າຮູບແບບ ແລະ ຄວນເຮັດເລື້ອຍປານໃດ

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

ຂໍ້ຄວນລະວັງສຳລັບແຕ່ລະແບບ. ສຳລັບການກູ້ຄືນໄຟລ໌ດ່ຽວ, ຫ້າມກູ້ຄືນທັບໄຟລ໌ຕົ້ນສະບັບເດັດຂາດ; ໃຫ້ໃຊ້ໂຟນເດີຊົ່ວຄາວ ເພື່ອບໍ່ໃຫ້ໄຟລ໌ສຳຮອງທີ່ອາດຈະເສຍໄປທຳລາຍຂໍ້ມູນຕົວຈິງ. ສຳລັບການກູ້ຄືນ VM, ເຄືອຂ່າຍທີ່ແຍກອອກຕ່າງຫາກແມ່ນສຳຄັນຫຼາຍ: domain controller ຫຼື mail server ທີ່ກູ້ຄືນຂຶ້ນມາ ຖ້າໄປເຊື່ອມຕໍ່ກັບເຄືອຂ່າຍໃຊ້ງານຕົວຈິງ ອາດສ້າງຄວາມເສຍຫາຍໜັກໄດ້ພາຍໃນບໍ່ເທົ່າໃດວິນາທີ. ຖອດສາຍອອກກ່ອນ, ກວດກາຊ້ຳສອງຮອບ. ສຳລັບການທົດສອບຖານຂໍ້ມູນ, ພຽງແຕ່ເປີດໄຟລ໌ຂຶ້ນມາໄດ້ແມ່ນຍັງບໍ່ພໍ; ຕ້ອງລ໊ອກອິນຜ່ານແອັບພລິເຄຊັນ ແລະ ກວດກາຂໍ້ມູນຂອງອາທິດລ່າສຸດນຳ, ເພາະຖານຂໍ້ມູນອາດຈະເປີດຂຶ້ນໄດ້ ແຕ່ລາຍການເຄື່ອນໄຫວລ່າສຸດອາດຈະຫາຍໄປ. ສຳລັບການທົດສອບແບບ bare-metal, ໃຫ້ກຽມເຄື່ອງສຳຮອງໄວ້ໜຶ່ງເຄື່ອງ ຫຼື ຢ່າງໜ້ອຍກໍຕ້ອງມີ USB ບູດລະບົບທີ່ທົດສອບແລ້ວຕຽມໄວ້; ລະດູຝົນຢູ່ລາວມັກມີຟ້າຜ່າທີ່ເຮັດໃຫ້ power supply ພັງ, ແລະ ນັ້ນແມ່ນເວລາທີ່ທ່ານຈະຕ້ອງໄດ້ໃຊ້ມັນແທ້ໆ. ການຊ້ອມເຕັມຮູບແບບຄວນປະຕິບັດຕາມ ແຜນຮັບມືເຫດສຸກເສີນ ທີ່ຂຽນໄວ້, ໂດຍມີຄົນໜຶ່ງຄອຍຈັບເວລາໃນແຕ່ລະຂັ້ນຕອນ.

ວິທີວັດແທກຜົນການກູ້ຄືນຢ່າງຖືກຕ້ອງ

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

ລອງຄິດໄລ່ຄ່າວໆ ກ່ອນທົດສອບ ເພື່ອໃຫ້ຮູ້ວ່າຄວນຄາດຫວັງເວລາເທົ່າໃດ. ການກູ້ຄືນຂໍ້ມູນ 500 GB ຜ່ານສາຍ LAN ໃນຫ້ອງການລະດັບ 1 Gbps, ເຊິ່ງຄວາມໄວຕົວຈິງຫຼັງຫັກ overhead ຈະຢູ່ປະມານ 100 MB ຕໍ່ວິນາທີ, ຈະໃຊ້ເວລາປະມານ 90 ນາທີ. ຂໍ້ມູນ 500 GB ຊຸດດຽວກັນນີ້ ຖ້າດຶງຜ່ານອິນເຕີເນັດຄວາມໄວ 50 Mbps ຈະໃຊ້ເວລາປະມານໜຶ່ງມື້ເຕັມ. ຖ້າຜ່ານຮາດດິສ USB 2.0 ລຸ້ນເກົ່າທີ່ຄວາມໄວ 25 MB ຕໍ່ວິນາທີ ຈະໃຊ້ເວລາເກືອບຫົກຊົ່ວໂມງ. ໃຫ້ກວດກາຕົວເລກເຫຼົ່ານີ້ຊ້ຳສອງຮອບທຽບກັບຄວາມໄວສາຍສັນຍານຕົວຈິງຂອງທ່ານ ກ່ອນທີ່ຈະໄປຮັບປາກເລື່ອງເວລາກັບເຈົ້າຂອງກິດຈະການ. ຖ້າເວລາທີ່ວັດແທກໄດ້ເກີນຄ່າ RTO, ໃຫ້ແກ້ໄຂການອອກແບບລະບົບ: ເພີ່ມສຳເນົາຂໍ້ມູນໄວ້ພາຍໃນຫ້ອງການ, ແຍກລະບົບສຳຄັນອອກມາເພື່ອໃຫ້ກູ້ຄືນໄດ້ໄວຂຶ້ນ, ຫຼື ກຽມເຄື່ອງສຳຮອງ (standby) ໄວ້.

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

ສຳເນົາຂໍ້ມູນທີ່ແກ້ໄຂບໍ່ໄດ້ (Immutable) ແລະ ບັນທຶກການກູ້ຄືນ

ຕ້ອງມີຂໍ້ມູນສຳຮອງຢ່າງໜ້ອຍໜຶ່ງຊຸດທີ່ລອດພົ້ນ ເຖິງວ່າຈະຖືກໂຈມຕີດ້ວຍ ransomware ທັງລະບົບກໍຕາມ. ນັ້ນໝາຍເຖິງ backup ທີ່ມັນແວ (malware) ບໍ່ສາມາດຂຽນທັບໄດ້: ຮາດດິສອອບໄລນ໌ທີ່ຖອດສາຍອອກທຸກຄັ້ງຫຼັງຈາກ backup ແລ້ວ, ຫຼື ພື້ນທີ່ເກັບຂໍ້ມູນເທິງ cloud ແລະ NAS ທີ່ເປີດໃຊ້ງານໂໝດ immutability ຫຼື object lock ເພື່ອບໍ່ໃຫ້ສາມາດປ່ຽນແປງໄຟລ໌ໄດ້ຕາມຈຳນວນມື້ທີ່ກຳນົດ. ໃຫ້ທົດສອບສຳເນົາຊຸດນີ້ນຳ ຢ່າງໜ້ອຍປີລະສອງຄັ້ງ, ໂດຍການລອງກູ້ຄືນຈາກມັນໂດຍສະເພາະ. ຮາດດິສອອບໄລນ໌ທີ່ບໍ່ເຄີຍທົດສອບເລີຍກໍເປັນພຽງແຕ່ຄວາມຫວັງເທົ່ານັ້ນ; ເທັບບັນທຶກຂໍ້ມູນ ແລະ ຮາດດິສ USB ເກົ່າໆ ມັກຈະເພໄປເອງໂດຍບໍ່ມີອາການເຕືອນ. ໃຫ້ເຮັດຄວບຄູ່ໄປກັບການກວດກາໃນ ລາຍການກວດກາເພື່ອປ້ອງກັນ ransomware ຂອງພວກເຮົາ.

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

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

ລາຍການກວດກາສັ້ນໆ ກ່ອນທີ່ທ່ານຈະເອີ້ນວ່າລະບົບໃດໜຶ່ງປອດໄພແລ້ວ:

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

ຂັ້ນຕອນຕໍ່ໄປຂອງທ່ານ: ທົດສອບກູ້ຄືນໜຶ່ງຄັ້ງໃນເດືອນນີ້

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

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