Tsightler: your point, in my opinion, is somewhat valid and I have used it in the past, but the issue here is extra complexity added to management of several things. Is this by design or a limitation of managing multiple/juggling VMs within replication jobs?Įven though this is a post from over 3 years ago, I echo kesenta's thoughts. Should I be manipulating something in the database or VM-ID folder for this VM as part of moving the VM between jobs? If i took the VM out and put it back into the same job, it doesn't do a digest recalculation, as expected. This shouldn't be the case since the VM was just replicated and therefore has minimal to no data change (even tested with source VM powered off). The issue is by simply moving the VM between replication jobs, it causes it to be recalculated even if a replication job was successfully completed just before it was moved. The digest recalculation can potentially take hours but that's not the issue here. Replica mapping is enabled after VM03 is moved from Job #1 to Job #2 (the Detect option was used). I don't see any traffic on the WAN link that indicates it is being saturated during the digest calculation step. Job configuration is set to Optimal for Compression and WAN target for Deduplication. Backup Server + Local/Source Proxy VM (8 vCPU, 16GB)
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |