ໃນໜ້ານີ້
- ມີ Backup ກັບ ກູ້ຄືນໄດ້ແທ້ ບໍ່ແມ່ນເລື່ອງດຽວກັນ
- ກົດ 3-2-1
- ເປັນຫຍັງຈຶ່ງກາຍເປັນ 3-2-1-1-0
- ຮູບແບບທີ່ເຮົາໃຊ້ເລື້ອຍ ສຳລັບຫ້ອງການ 20–150 ຄົນ
- ກຳນົດ RPO ແລະ RTO ກ່ອນຊື້ຫຍັງ
- ຕົວຢ່າງ: ຄິດເວລາກູ້ຄືນໃຫ້ເຫັນຕົວເລກ
- ສາມສິ່ງທີ່ຄົນມັກເຂົ້າໃຈຜິດວ່າແມ່ນ Backup
- ເກັບ Backup ດົນປານໃດ
- ໄຟຟ້າ, bandwidth ແລະ ສາຂາ
- ທົດສອບການກູ້ຄືນແນວໃດ
- ຂໍ້ຜິດພາດທີ່ພົບເລື້ອຍ
- ລາຍການກວດ
- ມາຄິດເວລາກູ້ຄືນຂອງທ່ານນຳກັນ
ມີ Backup ກັບ ກູ້ຄືນໄດ້ແທ້ ບໍ່ແມ່ນເລື່ອງດຽວກັນ
ເມື່ອເຮົາຖາມວ່າ "ມີ backup ບໍ?" ເກືອບທຸກຄົນຕອບວ່າມີ. ເມື່ອຖາມຕໍ່ວ່າ "ກູ້ຄືນຄັ້ງສຸດທ້າຍເມື່ອໃດ?" ຫ້ອງປະຊຸມມັກງຽບ. ກົດ 3-2-1 ມີໄວ້ເພື່ອວ່າ ເມື່ອສິ່ງໜຶ່ງເສຍ ຍັງມີອີກສຳເນົາໜຶ່ງທີ່ໃຊ້ໄດ້. ຄູ່ມືນີ້ສະແດງວິທີຕັ້ງຄ່າ ແລະ ວິທີພິສູດວ່າໃຊ້ໄດ້ແທ້ ກ່ອນວັນທີ່ຕ້ອງໃຊ້.
ກົດ 3-2-1
- 3 ສຳເນົາຂອງຂໍ້ມູນ: ຂໍ້ມູນທີ່ໃຊ້ງານ ບວກ backup ສອງຊຸດ
- 2 ສື່ ຫຼື ລະບົບທີ່ຕ່າງກັນ (ເຊັ່ນ ດິສ NAS ບວກ cloud object storage ຫຼື tape)
- 1 ສຳເນົາຢູ່ນອກສະຖານທີ່
ເປັນຫຍັງຈຶ່ງກາຍເປັນ 3-2-1-1-0
Ransomware ສະໄໝໃໝ່ ຊອກຫາ backup ແລະ ລຶບຖິ້ມກ່ອນເຂົ້າລະຫັດ. NAS ທີ່ join domain ດຽວກັນ ຫຼື map ເປັນໄດຣຟ໌ ຈະຖືກທຳລາຍພ້ອມກັບທຸກຢ່າງ. ຈຶ່ງເພີ່ມອີກສອງກົດ:
- 1 ສຳເນົາທີ່ immutable (ແກ້ໄຂ ຫຼື ລຶບບໍ່ໄດ້ຈົນກວ່າຈະໝົດໄລຍະເກັບ ເຖິງວ່າຈະມີລະຫັດ admin) ຫຼື offline / air-gapped
- 0 ຂໍ້ຜິດພາດ: backup ຖືກກວດອັດຕະໂນມັດ ແລະ ການກູ້ຄືນຖືກທົດສອບແທ້
ຮູບແບບທີ່ເຮົາໃຊ້ເລື້ອຍ ສຳລັບຫ້ອງການ 20–150 ຄົນ
| ສຳເນົາ | ຢູ່ໃສ | ໃຊ້ເພື່ອຫຍັງ |
|---|---|---|
| ຂໍ້ມູນໃຊ້ງານ | Server ຫຼື VM | ວຽກປະຈຳວັນ |
| Backup 1 | NAS ຫຼື backup appliance ໃນຫ້ອງ server, ເປີດ immutable snapshot/repository | ກູ້ໄວ ພາຍໃນນາທີ ຫາ ຊົ່ວໂມງ |
| Backup 2 | Cloud object storage ທີ່ມີ object lock, ຫຼື NAS ຢູ່ອີກສະຖານທີ່ໜຶ່ງ | ລອດຈາກໄຟໄໝ້, ລັກຂະໂມຍ, ນ້ຳຖ້ວມ ແລະ ransomware |
Backup 1 ຄວນໃຊ້ລະຫັດແຍກຕ່າງຫາກ, ບໍ່ join domain, ແລະ ບໍ່ເປີດ share ທີ່ຜູ້ໃຊ້ທົ່ວໄປເຫັນໄດ້.
ຕົວຢ່າງເຄື່ອງມືທີ່ເຮັດແບບນີ້ໄດ້: Veeam (ລຸ້ນ 13 ອອກໃນປີ 2025, ມີ Linux appliance ທີ່ hardened ແລ້ວ ແລະ hardened repository ແບບ immutable), Synology Active Backup for Business ພ້ອມ immutable snapshot, ແລະ QNAP Hybrid Backup Sync. ເລືອກຕາມຂະໜາດ ແລະ ທັກສະຂອງທີມ ບໍ່ແມ່ນຕາມຊື່ສຽງ.
ກຳນົດ RPO ແລະ RTO ກ່ອນຊື້ຫຍັງ
- RPO: ເສຍຂໍ້ມູນໄດ້ຫຼາຍສຸດເທົ່າໃດ? Backup ທຸກຄືນ ໝາຍເຖິງ RPO ປະມານ 24 ຊົ່ວໂມງ.
- RTO: ລະບົບຕ້ອງກັບມາໃຊ້ໄດ້ພາຍໃນເວລາເທົ່າໃດ?
ສອງຕົວເລກນີ້ກຳນົດງົບປະມານ. RPO ໜຶ່ງຊົ່ວໂມງ ຕ້ອງ backup ເລື້ອຍ ຫຼື replication. RTO ສອງຊົ່ວໂມງສຳລັບ ERP ຕ້ອງກູ້ຈາກເຄື່ອງໃນບ່ອນ, ເພາະດຶງ 2 TB ຈາກ cloud ຜ່ານສາຍ 100 Mbps ໃຊ້ເວລາເກີນ 40 ຊົ່ວໂມງ.
| ລະບົບ | RPO ເລີ່ມຕົ້ນ | RTO ເລີ່ມຕົ້ນ |
|---|---|---|
| ບັນຊີ / ERP | 1–4 ຊົ່ວໂມງ | 4–8 ຊົ່ວໂມງ |
| File server | 24 ຊົ່ວໂມງ | 1 ມື້ |
| ກ່ອງອີເມວເທິງ cloud | ຕາມ backup ພາຍນອກ | 1 ມື້ |
| ພາບ CCTV | ສ່ວນຫຼາຍບໍ່ backup; ໃຊ້ RAID ແລະ ກຳນົດມື້ເກັບ | — |
ນີ້ແມ່ນຈຸດເລີ່ມຕົ້ນ. ຕົກລົງຕົວເລກສຸດທ້າຍກັບຜູ້ບໍລິຫານ ເພາະເຂົາເຈົ້າແມ່ນຄົນທີ່ຕ້ອງປະເຊີນໜ້າລູກຄ້າເມື່ອລະບົບລົ້ມ.
ຕົວຢ່າງ: ຄິດເວລາກູ້ຄືນໃຫ້ເຫັນຕົວເລກ
ບໍລິສັດ 60 ຄົນ ມີຂໍ້ມູນ 4 TB (file server 3.5 TB, ERP 0.5 TB). ອິນເຕີເນັດ upload 50 Mbps, download 100 Mbps.
| ການກະທຳ | ການຄິດ | ເວລາໂດຍປະມານ |
|---|---|---|
| ກູ້ ERP 0.5 TB ຈາກ NAS ຜ່ານ 1 GbE | 0.5 TB × 8 ÷ 1 Gbps | ປະມານ 1–2 ຊົ່ວໂມງ |
| ກູ້ທັງ 4 TB ຈາກ NAS ຜ່ານ 1 GbE | 4 TB × 8 ÷ 1 Gbps | ປະມານ 9 ຊົ່ວໂມງ ທີ່ຄວາມໄວເຕັມ, ແທ້ມັກ 12 ຊົ່ວໂມງຂຶ້ນ |
| ກູ້ທັງ 4 TB ຈາກ cloud ຜ່ານ 100 Mbps | 4 TB × 8 ÷ 100 Mbps | ປະມານ 89 ຊົ່ວໂມງ ຫຼື ເກືອບ 4 ມື້ |
| Backup ເຕັມຄັ້ງທຳອິດຂຶ້ນ cloud ຜ່ານ 50 Mbps | 4 TB × 8 ÷ 50 Mbps | ປະມານ 7–8 ມື້ |
ບົດຮຽນ: cloud ແມ່ນບ່ອນເກັບສຳເນົາສຸດທ້າຍທີ່ດີ ແຕ່ບໍ່ແມ່ນບ່ອນກູ້ໄວ. ກູ້ ERP ກ່ອນ ຈາກ NAS ໃນບ່ອນ, ແລ້ວຈຶ່ງກູ້ໄຟລ໌ທີ່ເຫຼືອຕາມລຳດັບຄວາມສຳຄັນ. ຖ້າ RTO ທີ່ຜູ້ບໍລິຫານຕ້ອງການສັ້ນກວ່ານີ້ ຕ້ອງໃຊ້ 10 GbE ລະຫວ່າງ NAS ແລະ server, ຫຼື ໃຊ້ instant recovery ທີ່ເປີດ VM ຈາກ backup ໂດຍກົງ.
ສາມສິ່ງທີ່ຄົນມັກເຂົ້າໃຈຜິດວ່າແມ່ນ Backup
RAID. ລອດເມື່ອດິສເສຍໜຶ່ງລູກ. ບໍ່ປ້ອງກັນການລຶບ, ransomware ຫຼື controller ເສຍ.
Sync OneDrive ຫຼື Google Drive. ຖ້າໄຟລ໌ໃນ notebook ຖືກເຂົ້າລະຫັດ, sync ກໍອັບໂຫຼດໄຟລ໌ທີ່ຖືກເຂົ້າລະຫັດຂຶ້ນໄປ. Version history ຊ່ວຍໄດ້ ແຕ່ພຽງໃນໄລຍະຈຳກັດ.
Microsoft 365 ຫຼື Google Workspace ຢ່າງດຽວ. ຜູ້ໃຫ້ບໍລິການຮັບຜິດຊອບໂຄງສ້າງ ແລະ ການໃຫ້ບໍລິການ. ການປ້ອງກັນຜູ້ໃຊ້ລຶບ, admin ຖືກເຈາະ ຫຼື ຕ້ອງການຂໍ້ມູນເກົ່າກວ່າໄລຍະເກັບຂອງແພລດຟອມ ແມ່ນໜ້າທີ່ຂອງທ່ານ. ໃຊ້ backup ຈາກພາຍນອກ ຫຼື ບໍລິການ backup ແບບເສຍເງິນຂອງຜູ້ໃຫ້ບໍລິການເອງ ສຳລັບກ່ອງອີເມວ, OneDrive ແລະ SharePoint, ຫຼື Google Drive.
ເກັບ Backup ດົນປານໃດ
ຜູ້ໂຈມຕີມັກຢູ່ໃນເຄືອຂ່າຍຫຼາຍອາທິດກ່ອນລົງມື, backup ເຈັດມື້ຈຶ່ງອາດມີແຕ່ສຳເນົາທີ່ຕິດເຊື້ອແລ້ວ. ລະບົບ GFS ແມ່ນຈຸດເລີ່ມຕົ້ນທີ່ດີ:
| ລະດັບ | ຕົວຢ່າງ |
|---|---|
| ລາຍວັນ | 14–30 ມື້ |
| ລາຍອາທິດ | 4–8 ອາທິດ |
| ລາຍເດືອນ | 12 ເດືອນ |
| ລາຍປີ | ດົນເທົ່າທີ່ຝ່າຍການເງິນ ແລະ ຜູ້ບໍລິຫານຕ້ອງການເກັບບັນທຶກ |
ໄຟຟ້າ, bandwidth ແລະ ສາຂາ
ໄຟຟ້າ. NAS ທີ່ໄຟດັບກາງຄັນຂະນະຂຽນ ອາດເຮັດໃຫ້ repository ເສຍ ຫຼື ເກີດ RAID rebuild ທີ່ແລ່ນຫຼາຍຊົ່ວໂມງ. NAS ແລະ server ທີ່ເກັບ backup ຕ້ອງຢູ່ຫຼັງ UPS ທີ່ສັ່ງປິດເຄື່ອງອັດຕະໂນມັດຜ່ານ USB ຫຼື ກາດເຄືອຂ່າຍ. ທົດສອບເທື່ອໜຶ່ງ ດ້ວຍການຖອດປລັກແທ້. ເບິ່ງ ຄູ່ມືເລືອກຂະໜາດ UPS.
Bandwidth. Backup ເຕັມຄັ້ງທຳອິດ 3 TB ຜ່ານ upload 50 Mbps ໃຊ້ເວລາປະມານຫົກມື້ ທີ່ຄວາມໄວເຕັມສາຍ. ຂະໜາດນີ້ ໃຫ້ seed ດ້ວຍດິສ ແລ້ວສົ່ງແຕ່ incremental, ແລະ ຈຳກັດຄວາມໄວໃນເວລາເຮັດວຽກ.
ສາຂາຕ່າງແຂວງ ແລະ ໜ້າງານບໍ່ແຮ່. ເກັບ backup ໃນບ່ອນໄວ້ກູ້ໄວ ແລະ replicate ຕອນກາງຄືນໄປວຽງຈັນ ຫຼື cloud. ຢ່າລືມ notebook ຂອງຜູ້ບໍລິຫານ ແລະ ວິສະວະກອນໜ້າງານ ທີ່ມັກເປັນບ່ອນດຽວທີ່ມີເອກະສານສຳຄັນ.
ນ້ຳຖ້ວມ ແລະ ຄວາມຮ້ອນ. ຫ້ອງ server ຊັ້ນລຸ່ມ ໃກ້ແມ່ນ້ຳ ແມ່ນຄວາມສ່ຽງແທ້ໃນລະດູຝົນ. ສຳເນົານອກສະຖານທີ່ ຕ້ອງຢູ່ຫ່າງພໍ ທີ່ນ້ຳຖ້ວມດຽວກັນຈະບໍ່ຮອດ.
ຂຽນຂັ້ນຕອນ backup ແລະ ການກູ້ຄືນໄວ້ເປັນລາຍລັກອັກສອນ, ແລະ ເກັບ backup ໄວ້ຫຼາຍກວ່າໜຶ່ງສະຖານທີ່ສະເໝີ. ນ້ຳຖ້ວມ ຫຼື ໄຟໄໝ້ໃນຫ້ອງ server ດຽວ ບໍ່ຄວນເອົາທຸກສຳເນົາໄປນຳ.
ທົດສອບການກູ້ຄືນແນວໃດ
ການທົດສອບບໍ່ຈຳເປັນຕ້ອງໃຫຍ່. ທຸກໄຕມາດ ເລືອກໜຶ່ງລະບົບ: ກູ້ VM ຂອງ ERP ໄປໃສ່ເຄືອຂ່າຍທົດສອບທີ່ແຍກອອກ, ໃຫ້ພະນັກງານບັນຊີໜຶ່ງຄົນເຂົ້າໃຊ້ ແລະ ເປີດລາຍງານຂອງມື້ວານ, ແລ້ວບັນທຶກເວລາທີ່ໃຊ້ຕັ້ງແຕ່ເລີ່ມຈົນໃຊ້ໄດ້. ຕົວເລກນັ້ນແມ່ນ RTO ແທ້ຂອງທ່ານ, ບໍ່ແມ່ນຕົວເລກໃນສະເປັກ. ທຸກປີ ໃຫ້ຄົນທີ່ບໍ່ແມ່ນ admin ຫຼັກ ລອງກູ້ຕາມເອກະສານ. ຖ້າເຂົາເຈົ້າເຮັດບໍ່ໄດ້ ເອກະສານຕ້ອງແກ້.
ຂໍ້ຜິດພາດທີ່ພົບເລື້ອຍ
- Backup ລົ້ມເຫຼວມາຫຼາຍເດືອນ ແຕ່ບໍ່ມີໃຜຮູ້. Email ແຈ້ງເຕືອນໄປຫາກ່ອງຂອງພະນັກງານທີ່ລາອອກແລ້ວ.
- NAS ໃຊ້ລະຫັດ admin ດຽວກັບ domain. ຜູ້ໂຈມຕີທີ່ໄດ້ລະຫັດ domain ກໍລຶບ backup ໄດ້ທັນທີ.
- Backup ແຕ່ໄຟລ໌, ບໍ່ backup ຖານຂໍ້ມູນໃຫ້ຖືກວິທີ. ການສຳເນົາໄຟລ໌ຖານຂໍ້ມູນຂະນະເປີດໃຊ້ ອາດໄດ້ສຳເນົາທີ່ເປີດບໍ່ໄດ້. ໃຊ້ backup ແບບ application-aware.
- ກະແຈເຂົ້າລະຫັດເກັບໄວ້ໃນ server ທີ່ຖືກ backup. ເມື່ອ server ເສຍ ກະແຈກໍເສຍນຳ.
- ເຊື່ອວ່າ cloud ກູ້ໄດ້ໄວ. ເບິ່ງຕົວຢ່າງຂ້າງເທິງ: 4 TB ໃຊ້ເວລາເກືອບສີ່ມື້.
ສຳລັບການປ້ອງກັນ ransomware ດ້ານອື່ນໆ ເບິ່ງ ລາຍການກວດປ້ອງກັນ Ransomware, ແລະ ສຳລັບການເລືອກບ່ອນເກັບ ເບິ່ງ NAS, SAN ຫຼື Cloud.
ລາຍການກວດ
- ບັນຊີຂໍ້ມູນ ແລະ ລະບົບທັງໝົດ ພ້ອມເຈົ້າຂອງແຕ່ລະລະບົບ.
- ເປົ້າໝາຍ RPO/RTO ທີ່ຜູ້ບໍລິຫານລົງນາມ.
- ຊອບແວ backup ທີ່ຄອບຄຸມ VM, server ແທ້ ແລະ Microsoft 365 ຫຼື Google Workspace.
- ເປີດ immutability ຢ່າງໜ້ອຍໜຶ່ງ repository.
- Backup ນອກສະຖານທີ່ເຂົ້າລະຫັດ, ແລະ ເກັບກະແຈໄວ້ບ່ອນອື່ນ ບໍ່ແມ່ນ server ດຽວກັນ.
- ທົດສອບການກູ້ຄືນທຸກໄຕມາດ ແລະ ບັນທຶກເວລາທີ່ໃຊ້.
- ການແຈ້ງເຕືອນເມື່ອ backup ລົ້ມເຫຼວ ໄປຫາຄົນທີ່ອ່ານແທ້.
- ຂັ້ນຕອນກູ້ຄືນເປັນລາຍລັກອັກສອນ ທີ່ຄົນອື່ນເຮັດຕາມໄດ້ ເມື່ອ admin ຫຼັກບໍ່ຢູ່.
ຍີ່ຫໍ້ທີ່ເຮົາສະໜອງ ແລະ ຕິດຕັ້ງສຳລັບ backup ລວມມີ Veeam, Synology ແລະ QNAP. ອ່ານເພີ່ມທີ່ Backup ແລະ Disaster Recovery.
ມາຄິດເວລາກູ້ຄືນຂອງທ່ານນຳກັນ
ບອກເຮົາວ່າມີຂໍ້ມູນປະມານຈັກ TB, ລະບົບໃດສຳຄັນທີ່ສຸດ ແລະ ຄວາມໄວ upload ຂອງອິນເຕີເນັດ. ເຮົາຈະຄິດວ່າ backup ຄັ້ງທຳອິດ ແລະ ການກູ້ຄືນທັງໝົດໃຊ້ເວລາເທົ່າໃດ, ແລ້ວອອກແບບໃຫ້ RTO ທີ່ທ່ານຕ້ອງການເຮັດໄດ້ແທ້.
- #backup
- #3-2-1
- #disaster-recovery
- #rpo
- #rto
- #immutable
