Unsolved
2 Posts
0
338
Replication stops working after creating DDboost Storage Unit on replicated Mtree
I replicated my DD to another DD, and on replication side i need to access the files from Veeam. Therefore I created a DDBoost Storage Unit on the replicated MTree with the following command:
ddboost storage-unit modify #StorageUnite_Name# user #Username#
(like described here: https://www.dell.com/community/Data-Domain/Recreate-DDBoost-storage-unit-on-existing-MTree/td-p/7148986)
That worked and I can now acces it using ddboost. But now the replication is not working anymore.
Any ideas why?
I am using the follwing for both DDs:
Model Number
|
DD3300
|
Version
|
7.10.0.0-1017741
|
barry_beckers
393 Posts
0
June 26th, 2023 10:00
What is your actual idea of how to use the replicated data? How and in what way is the veeam server supposed to be accessing the replicated mtree? Is it another veeam instance that would scan in the repo? Used as fail-over, when the original site/location/dd is unavailable?
You seem to want it to be used on the target DD actively but also it to be in sync continuously?
What is the actual replication error that you get?
Wasn't the target mtree read-only when you setup the mtree replication while now, it would have been turned into status RW? Which "mtree list" should show on both ends.
Wouldn't you have to create a fastcopy of the replicated mtree and then add that to veeam? As stated in a older Dell KB regarding veeam 9.5?
https://supportkb.dell.com/attachment/ka02R000000hA3YQAU/Veeam9.5_DDBoost_and_DR_csp_en_US_1.pdf
But that also means your (fast)copy of the replicated mtree is NOT in sync at all, only once you perform the fastcopy of the replicated mtree.
As said it depends on how you even intend to use the replica? It might be that you intend to use it in a way, that might not be supported/possible?
ywtech
2 Posts
0
June 27th, 2023 04:00
Update: apparently after a reboot of DD1 the synchronization worked again.
I have a prod1(veeam1, DD1) and DR2 site(veeam2, DD2)
Veeam1 on prod backup copies to DD1 and DD1 replicates to DR site DD2.
From veeam2 I want daily restores from DD2. (So DD2 should be in sync within A few hours, which workes fine on my old DDs)
I never did this fast copy but I did it like described here with my old DD which works fine:
https://community.veeam.com/blogs-and-podcasts-57/how-to-use-the-data-domain-repository-mtree-replica-at-the-dr-site-3174
The error message was smth. like: "Out of sync for over 32 hours"
barry_beckers
393 Posts
0
June 27th, 2023 08:00
what do you mean with "daily restores"?
the thing is also, what do you want to protect yourself against? In your case veeam1 is completely unaware of anything being replicated to dd2, also there is a possible delay, depending on how and when the mtree replication is to be triggered or occurring?
While when veeam1 would have for example a copy job of some sorts to dd2, veeam1 would be aware. Then veeam2 would add the repo on dd2 when veeam1 would be unavailable.
But as asked, what is the intended fail-over that you have in mind exactly? Is veeam2 supposed to be available to perform any restores and if so, why would that not be under control of veeam1?
using a different backup product ourselves (Dell Networker), but I rather like to have the production backup server be in full control of which backups go where and it being aware of its status at any given moment. So backups can be replicated all over the place, but the backup server would be fully in control of that.
One exception might be some cyber protection approach, where data is being replicated to another DD and data is being analyzed to see if they are compromised and made available for restore in case the primary environment might be severely affected. However for normal backup, if resiliency is required, I'd used more than one backup media and have the backup server replicate its backups (or a selected amount) anywhere you'd like and be aware and in control of it. So that is to have a proper RTO/RPO whereas a cyber recovery/protection approach on top of that would be some kinda last resort, which might not contain the latest backups even.
Hence I am curious what your approach and current usage and expectation is?