ວິ​ທີ​ການ​ເກັບ​ຮັກ​ສາ​ສໍາ​ຮອງ​ຂໍ້​ມູນ​ໃນ​ການ​ເກັບ​ຮັກ​ສາ​ວັດ​ຖຸ​ສູງ​ເຖິງ 90​%

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

ໃຫ້: ມີບ່ອນເກັບຂໍ້ມູນ S3 ທ້ອງຖິ່ນ, ມີ Veritas NetBackup, ເຊິ່ງໄດ້ຮັບຫນ້າທີ່ຂະຫຍາຍໃຫມ່ສໍາລັບການຍ້າຍຂໍ້ມູນໄປຫາບ່ອນເກັບມ້ຽນວັດຖຸ, ໃນປັດຈຸບັນສະຫນັບສະຫນູນການຊໍ້າຊ້ອນ, ແລະມີບັນຫາກັບພື້ນທີ່ຫວ່າງໃນການເກັບຮັກສາທ້ອງຖິ່ນນີ້.

ວຽກງານ: ເພື່ອເຮັດໃຫ້ທຸກສິ່ງທຸກຢ່າງເພື່ອໃຫ້ຂະບວນການເກັບຮັກສາສໍາເນົາສໍາຮອງແມ່ນໄວແລະລາຄາຖືກ.

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

ຮູບພາບສະແດງໃຫ້ເຫັນສິ່ງທີ່ພວກເຮົາມາ:

ດັ່ງທີ່ທ່ານສາມາດເຫັນໄດ້, ການສໍາຮອງຂໍ້ມູນຄັ້ງທໍາອິດໄດ້ຖືກເຮັດຊ້າໆ (70 Mb / s), ແລະການສໍາຮອງຂໍ້ມູນຕໍ່ມາຂອງລະບົບດຽວກັນແມ່ນໄວຂຶ້ນຫຼາຍ.

ແທ້ຈິງແລ້ວ, ມີລາຍລະອຽດເພີ່ມເຕີມເລັກນ້ອຍກ່ຽວກັບຄຸນລັກສະນະຕ່າງໆ.

ບັນທຶກສໍາຮອງສໍາລັບຜູ້ທີ່ພ້ອມທີ່ຈະອ່ານເຄິ່ງຫນຶ່ງຂອງຫນ້າ dumpເຕັມດ້ວຍການສະແກນຄືນໃໝ່
ວັນທີ 18 ທັນວາ 2018 12:09:43 ໂມງແລງ — ຂໍ້ມູນ bpbkar (pid=4452) ເລັ່ງສົ່ງ 14883996160 ໄບຕ໌ອອກຈາກ 14883994624 ໄບຕ໌ໄປຫາເຊີບເວີ, ການເພີ່ມປະສິດທິພາບ 0.0%
Dec 18, 2018 12:10:07 PM - Info NBCC (pid=23002) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr ; ລາຍງານ=PDDO ສະຖິຕິ (ສະຕຣີມຫຼາຍກະທູ້ທີ່ໃຊ້ແລ້ວ) ສໍາລັບ (NBCC): ສະແກນແລ້ວ: 14570817 KB, CR ສົ່ງໄປ: 1760761 KB, CR ສົ່ງຜ່ານ FC: 0 KB, dedup: 87.9%, cache disabled

ຢ່າງ​ເຕັມ​ທີ່
ວັນທີ 18 ທັນວາ 2018 12:13:18 ໂມງແລງ — ຂໍ້ມູນ bpbkar (pid=2864) ເລັ່ງສົ່ງ 181675008 ໄບຕ໌ອອກຈາກ 14884060160 ໄບຕ໌ໄປຫາເຊີບເວີ, ການເພີ່ມປະສິດທິພາບ 98.8%
Dec 18, 2018 12:13:40 PM - Info NBCC (pid=23527) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr ; Report=PDDO Stats for (NBCC): scanned: 14569706 KB, CR ສົ່ງ: 45145 KB, CR ສົ່ງເກີນ FC: 0 KB, dedup: 99.7%, cache disabled

Incremental
ວັນທີ 18 ທັນວາ 2018 12:15:32 ໂມງແລງ — ຂໍ້ມູນ bpbkar (pid=792) ເລັ່ງສົ່ງ 9970688 ໄບຕ໌ອອກຈາກ 14726108160 ໄບຕ໌ໄປຫາເຊີບເວີ, ການເພີ່ມປະສິດທິພາບ 99.9%
Dec 18, 2018 12:15:53 PM - Info NBCC (pid=23656) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr ; Report=PDDO Stats for (NBCC): scanned: 14383788 KB, CR ສົ່ງ: 15700 KB, CR ສົ່ງເກີນ FC: 0 KB, dedup: 99.9%, cache disabled

ຢ່າງ​ເຕັມ​ທີ່
ວັນທີ 18 ທັນວາ 2018 12:18:02 ໂມງແລງ — ຂໍ້ມູນ bpbkar (pid=3496) ເລັ່ງສົ່ງ 171746816 ໄບຕ໌ອອກຈາກ 14884093952 ໄບຕ໌ໄປຫາເຊີບເວີ, ການເພີ່ມປະສິດທິພາບ 98.8%
Dec 18, 2018 12:18:24 PM - Info NBCC (pid=23878) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr ; Report=PDDO Stats for (NBCC): scanned: 14569739 KB, CR ສົ່ງ: 34120 KB, CR ສົ່ງເກີນ FC: 0 KB, dedup: 99.8%, cache disabled

ມີ​ບັນ​ຫາ​ຫຍັງ

ລູກຄ້າຕ້ອງການເຮັດການສໍາຮອງຂໍ້ມູນເລື້ອຍໆເທົ່າທີ່ເປັນໄປໄດ້ແລະເກັບຮັກສາມັນລາຄາຖືກເທົ່າທີ່ເປັນໄປໄດ້. ມັນດີທີ່ສຸດທີ່ຈະເກັບຮັກສາພວກມັນລາຄາຖືກຢູ່ໃນບ່ອນເກັບມ້ຽນວັດຖຸເຊັ່ນ S3, ເພາະວ່າພວກມັນມີລາຄາຖືກທີ່ສຸດໃນຄ່າໃຊ້ຈ່າຍຂອງການບໍລິການຕໍ່ Megabyte ຈາກບ່ອນທີ່ທ່ານສາມາດມ້ວນສໍາຮອງຂໍ້ມູນໃນເວລາທີ່ເຫມາະສົມ. ໃນເວລາທີ່ມີການສໍາຮອງຂໍ້ມູນຫຼາຍ, ມັນຈະກາຍເປັນບໍ່ມີລາຄາຖືກຫຼາຍ, ເນື່ອງຈາກວ່າການເກັບຮັກສາສ່ວນໃຫຍ່ຖືກຄອບຄອງໂດຍສໍາເນົາຂອງຂໍ້ມູນດຽວກັນ. ໃນກໍລະນີຂອງ HaaS ຂອງເພື່ອນຮ່ວມງານຕວກກີ, ການເກັບຮັກສາສາມາດມີຄວາມຫນາແຫນ້ນປະມານ 80-90%. ມັນເປັນທີ່ຊັດເຈນວ່າເລື່ອງນີ້ກ່ຽວຂ້ອງກັບສະເພາະຂອງພວກເຂົາ, ແຕ່ຂ້ອຍແນ່ນອນຈະອີງໃສ່ພໍ່ຕູ້ຢ່າງຫນ້ອຍ 50%.

ເພື່ອແກ້ໄຂບັນຫາ, ຜູ້ຂາຍຕົ້ນຕໍໄດ້ສ້າງປະຕູສູ່ Amazon S3 ດົນນານ. ວິທີການທັງຫມົດຂອງພວກເຂົາແມ່ນເຫມາະສົມກັບ S3 ທ້ອງຖິ່ນຕາບໃດທີ່ພວກເຂົາສະຫນັບສະຫນູນ Amazon API. ໃນສູນຂໍ້ມູນຕວກກີ, ການສໍາຮອງຂໍ້ມູນແມ່ນເຮັດກັບ S3 ຂອງພວກເຮົາ, ເຊັ່ນດຽວກັນກັບ T-III "Compressor" ໃນລັດເຊຍ, ເນື່ອງຈາກວ່າໂຄງການນີ້ເຮັດວຽກໄດ້ດີສໍາລັບພວກເຮົາ.

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

Veritas NetBackup ເພີ່ມຄຸນສົມບັດ CloudCatalyst:

ນັ້ນແມ່ນ, ລະຫວ່າງເຄື່ອງທີ່ຕ້ອງໄດ້ຮັບການສໍາຮອງແລະປະຕູ, ມີເຄື່ອງແມ່ຂ່າຍຂອງ Linux ລະດັບປານກາງໂດຍຜ່ານການຈະລາຈອນສໍາຮອງຈາກຕົວແທນ SRK ຜ່ານແລະຖືກ deduplicated ໃນທັນທີກ່ອນທີ່ຈະໂອນມັນໄປ S3. ຖ້າກ່ອນຫນ້ານີ້ມີ 30 ສໍາຮອງຂໍ້ມູນ 20 GB ດ້ວຍການບີບອັດ, ໃນປັດຈຸບັນ (ເນື່ອງຈາກຄວາມຄ້າຍຄືກັນຂອງເຄື່ອງຈັກ) ປະລິມານຂອງພວກມັນໄດ້ກາຍເປັນຂະຫນາດນ້ອຍກວ່າ 90%. ເຄື່ອງຈັກ deduplication ຖືກນໍາໃຊ້ຄືກັນກັບເວລາທີ່ເກັບໄວ້ໃນແຜ່ນປົກກະຕິໂດຍໃຊ້ Netbackup.

ນີ້ແມ່ນສິ່ງທີ່ເກີດຂື້ນກ່ອນເຄື່ອງແມ່ຂ່າຍລະດັບກາງ:

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

ບັນທຶກ228 ວຽກ (0 ຄິວ 0 Active 0 Waiting for Retry 0 Suspended 0 Incomplete 228 Done — 13 ເລືອກ)
(ໃຊ້ການກັ່ນຕອງ [13])

Job Id ປະເພດ State State Details Status Job Policy Job Schedule Client Media Server Start Time Elapsed Time End Time Storage Unit Attempt Operation Kilobytes Files Pathname % Complete (Estimated) Job PID Owner Copy Parent Job ID KB/Sec Active Start Active Elapsed Robot Vault Session ID Media ທີ່ຈະຖອດການເຄື່ອນຍ້າຍຂໍ້ມູນອອກຈາກເຈົ້າພາບປະເພດ Master Priority Deduplication Rate Transport Accelerator Optimization Instance ຫຼື Database Share Host
— 1358 Snapshot Done 0 VMware — NGNCloudADC NBCC Dec 18, 2018 12:16:19 PM 00:02:18 Dec 18, 2018 12:18:37 PM STU_DP_S3_**** backup 1 100% 1358 Dec. :18:2018 PM 12:16:27 Instant Recovery Disk Standard WIN-*********** 00
1360 Backup Done 0 VMware Full NGNCloudADC NBCC Dec 18, 2018 12:16:48 PM 00:01:39 Dec 18, 2018 12:18:27 PM STU_DP_S3_**backup 1 14,535,248% root 149654 100 ທັນວາ 23858 , 1358 335,098:18:2018 PM 12:16:48 Instant Recovery Disk Standard WIN-*********** 00 01% 39%
1352 Snapshot Done 0 VMware - NGNCloudADC NBCC Dec 18, 2018 12:14:04 PM 00:02:01 Dec 18, 2018 12:16:05 PM STU_DP_S3_**** backup 1 100% 1352 Dec. 18:2018 PM 12:14:14 Instant Recovery Disk Standard WIN-*********** 00
. 1354 0 ທັນວາ 18 , 2018 12:14:34 PM 00:01:21 Instant Recovery Disk Standard WIN-*********** 18 2018% 12%
1347 Snapshot Done 0 VMware - NGNCloudADC NBCC Dec 18, 2018 12:11:45 PM 00:02:08 Dec 18, 2018 12:13:53 PM STU_DP_S3_**** backup 1 100% 1347 Dec. 18:2018 PM 12:11:45 Instant Recovery Disk Standard WIN-*********** 00
1349 Backup Done 0 VMware Full NGNCloudADC NBCC Dec 18, 2018 12:12:02 PM 00:01:41 Dec 18, 2018 12:13:43 PM STU_DP_S3_**backup 1 14,535,215% root 149653 100 ທັນວາ 23508 , 1347 316,319:18:2018 PM 12:12:02 Instant Recovery Disk Standard WIN-*********** 00 01% 41%
1341 Snapshot Done 0 VMware - NGNCloudADC NBCC Dec 18, 2018 12:05:28 PM 00:04:53 Dec 18, 2018 12:10:21 PM STU_DP_S3_**** backup 1 100% 1341 Dec. 18:2018 PM 12:05:28 Instant Recovery Disk Standard WIN-*********** 00
1342 Backup Done 0 VMware Full_Rescan NGNCloudADC NBCC Dec 18, 2018 12:05:47 PM 00:04:24 Dec 18, 2018 12:10:11 PM STU_DP_S3_1**backup 14,535,151 149653 root 100 22999 1341 ທັນ 70,380 , 18 2018:12:05 PM 47:00:04 Instant Recovery Disk Standard WIN-*********** 24 0% 87.9%

1339 Snapshot Done 150 VMware - NGNCloudADC NBCC Dec 18, 2018 11:05:46 AM 00:00:53 Dec 18, 2018 11:06:39 AM STU_DP_S3_**** backup 1 Dec 100% root 1339:18 AM 2018:11:05 Instant Recovery Disk Standard WIN-*********** 46
1327 Snapshot Done 0 VMware - *******.**********.cloud NBCC Dec 17, 2018 12:54:42 PM 05:51:38 Dec 17, 2018 6:46:20 PM STU_DP_S3_****backup 1 100% root 1327 Dec 17, 2018 12:54:42 PM 05:51:38 Instant Recovery Disk Standard WIN-*********** 0
1328 Backup Done 0 VMware Full *******.**********.cloud NBCC Dec 17, 2018 12:55:10 PM 05:29:21 Dec 17, 2018 6:24:31 PM STU_DP_S3_**backup 1 222,602,719 258932 100% 12856 root 1327 11,326 Dec 17, 2018 12:55:10 PM 05:29:21 Instant Recovery Disk**********0% Standard WIN-87.9. 0%
1136 Snapshot Done 0 VMware - *******.**********.cloud NBCC Dec 14, 2018 4:48:22 PM 04:05:16 Dec 14, 2018 8:53:38 PM STU_DP_S3_****backup 1 100% root 1136 Dec 14, 2018 4:48:22 PM 04:05:16 Instant Recovery Disk Standard WIN-*********** 0
1140 Backup Done 0 VMware Full_Scan *******.**********.cloud NBCC Dec 14, 2018 4:49:14 PM 03:49:58 Dec 14, 2018 8:39:12 PM STU_DP_S3_****backup 1 217,631,332 255465 100% 26438 root 1136 15,963 Dec 14, 2018 4:49:14 PM 03:49:58 Instant Recovery Disk.****** Standard WIN-0%45.2. 0%

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

ເຊີບເວີລະດັບກາງມີບ່ອນເກັບມ້ຽນຂອງຕົນເອງ, ບ່ອນທີ່ມັນຂຽນ "cache" ຂອງຂໍ້ມູນແລະຮັກສາຖານຂໍ້ມູນສໍາລັບການຖອນຊໍ້າກັນ.

ສະຖາປັດຕະຍະກໍາທີ່ສົມບູນມີລັກສະນະດັ່ງນີ້:

1. ເຊີບເວີແມ່ແບບຈັດການການຕັ້ງຄ່າ, ອັບເດດ, ແລະອື່ນໆ ແລະຕັ້ງຢູ່ໃນຄລາວ.
2. ເຊີບເວີມີເດຍ (ເຄື່ອງກາງ * nix) ຄວນຕັ້ງຢູ່ໃກ້ກັບລະບົບທີ່ຊ້ຳຊ້ອນທີ່ສຸດໃນການເຂົ້າຫາເຄືອຂ່າຍ. ທີ່ນີ້, ການຊໍ້າຊ້ອນການສໍາຮອງຂໍ້ມູນຈາກເຄື່ອງທີ່ສະຫງວນໄວ້ທັງຫມົດແມ່ນເຮັດໄດ້.
3. ໃນເຄື່ອງສໍາຮອງມີຕົວແທນທີ່ໂດຍທົ່ວໄປແລ້ວສົ່ງໄປຫາເຄື່ອງແມ່ຂ່າຍສື່ພຽງແຕ່ສິ່ງທີ່ບໍ່ຢູ່ໃນບ່ອນເກັບມ້ຽນຂອງມັນ.

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

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

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

ນີ້ແມ່ນສິ່ງທີ່ເບິ່ງຄືວ່າ:

ແລະນີ້ແມ່ນໄມ້ທ່ອນອື່ນ169 ວຽກ (0 ຄິວ 0 Active 0 Waiting for Retry 0 Suspended 0 Incomplete 169 Done — 1 ເລືອກ)

Job Id ປະເພດ State State Details Status Job Policy Job Schedule Client Media Server Start Time Elapsed Time End Time Storage Unit Attempt Operation Kilobytes Files Pathname % Complete (Estimated) Job PID Owner Copy Parent Job ID KB/Sec Active Start Active Elapsed Robot Vault Session ID Media ທີ່ຈະຖອດການເຄື່ອນຍ້າຍຂໍ້ມູນອອກຈາກເຈົ້າພາບປະເພດ Master Priority Deduplication Rate Transport Accelerator Optimization Instance ຫຼື Database Share Host
— 1372 Restore Done 0 nbpr01 NBCC Dec 19, 2018 1:05:58 PM 00:04:32 Dec 19, 2018 1:10:30 PM 1 14,380,577 1 100% 8548 Dec 1372, 70,567 19:2018:1. PM 06:00:00 WIN-*********** 04

ຄວາມສົມບູນຂອງຂໍ້ມູນແມ່ນຮັບປະກັນໂດຍການປົກປ້ອງ S3 ຕົວຂອງມັນເອງ - ມີຄວາມຊໍ້າຊ້ອນທີ່ດີຢູ່ທີ່ນັ້ນເພື່ອປ້ອງກັນຄວາມລົ້ມເຫຼວຂອງຮາດແວເຊັ່ນ spindle ຮາດໄດທີ່ຕາຍແລ້ວ.

ເຄື່ອງແມ່ຂ່າຍສື່ຕ້ອງການ 4 TB ຂອງ cache - ນີ້ແມ່ນຄໍາແນະນໍາຂະຫນາດຕໍາ່ສຸດຂອງ Veritas. ຫຼາຍແມ່ນດີກວ່າ, ແຕ່ນັ້ນແມ່ນສິ່ງທີ່ພວກເຮົາໄດ້ເຮັດ.

ຜົນໄດ້ຮັບ

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

ໃນກໍລະນີນີ້, ເສັ້ນທາງຕ່າງໆໄດ້ຖືກປິດຜ່ານ "ອິນເຕີເນັດໃຫຍ່", ແຕ່ທ່ານສາມາດຂັບລົດຜ່ານ VPN L2 ຜ່ານອິນເຕີເນັດ, ແຕ່ມັນກໍ່ດີກວ່າທີ່ຈະຕິດຕັ້ງເຄື່ອງແມ່ຂ່າຍສື່ກ່ອນທາງເຂົ້າຂອງຜູ້ໃຫ້ບໍລິການ.

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

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