I'm not sure if there is anything specific to your setup, but I run cleanup of DDs at the same time (including those which replicate among themselves). I never had seen any issue with that.
Thanks. I also saw where someone said a couple of years ago "Some other points you can consider while setting up cleaning schedule is if you have a replication pair DDRs, I would have cleaning run on Source first and then on Destination, (for eg. Source DDR cleaning schedule is set to run on Monday 6AM, the destination DDR is set to run at Tuesday 6AM). This helps to keep both your DDR spaces synced; when the backups are deleted from the Source, it is reflected to the Destination, so running the clean next day takes care of the recently deleted Data right away." In our case, both DDRs replicate source data to each other, but that sounds a little like what I was remembering the EMC tech saying a few months back/
I've actually never thought about this before, however, If data is deleted on the DD and not cleaned yet, it still won't be replicated - it's just waiting to be cleaned off the system as already irrelevant/dead data.
You will constantly be behind deleted data between clean cycles, which is fine and as expected, but you may be able to seed off data stored on the destination that is due to be deleted by the backup app.
I'm just not convinced that there is much to be gained with an offset clean cycle between source and target DD - the gains will be marginal or not there as you might expect, retention policy length would play a large role in this.
Specifically if you expire/delete data one day and then try to replicate to that system the next, that you can't seed against it and it *could make replication take longer.
A word of warning though, increasing clean schedules will lead to filesystem fragmentation and impact read performance. The perfect setup is where you clean as infrequently as possible, though once a week is the default/expectation.
I don't believe there is any advantage or disadvantage to this configuration. also cleaning on your source datadomain (in this case, it seems these are both source and target to each other) won't actually delete blocks which have not replicated to target yet even though images have reached the retention in avamar's catalog and have asked DD to delete them.
if you are running the DD over 90% then you will notice slow cleaning process as it needs more space to get this done faster. you can also increase the cleaning throttle.
ble1
4 Operator
•
14.4K Posts
0
October 4th, 2016 01:00
I'm not sure if there is anything specific to your setup, but I run cleanup of DDs at the same time (including those which replicate among themselves). I never had seen any issue with that.
hatfield1
8 Posts
0
October 5th, 2016 05:00
Thanks. I also saw where someone said a couple of years ago "Some other points you can consider while setting up cleaning schedule is if you have a replication pair DDRs, I would have cleaning run on Source first and then on Destination, (for eg. Source DDR cleaning schedule is set to run on Monday 6AM, the destination DDR is set to run at Tuesday 6AM). This helps to keep both your DDR spaces synced; when the backups are deleted from the Source, it is reflected to the Destination, so running the clean next day takes care of the recently deleted Data right away." In our case, both DDRs replicate source data to each other, but that sounds a little like what I was remembering the EMC tech saying a few months back/
jbrooksuk
208 Posts
0
October 5th, 2016 10:00
I've actually never thought about this before, however, If data is deleted on the DD and not cleaned yet, it still won't be replicated - it's just waiting to be cleaned off the system as already irrelevant/dead data.
You will constantly be behind deleted data between clean cycles, which is fine and as expected, but you may be able to seed off data stored on the destination that is due to be deleted by the backup app.
I'm just not convinced that there is much to be gained with an offset clean cycle between source and target DD - the gains will be marginal or not there as you might expect, retention policy length would play a large role in this.
Specifically if you expire/delete data one day and then try to replicate to that system the next, that you can't seed against it and it *could make replication take longer.
A word of warning though, increasing clean schedules will lead to filesystem fragmentation and impact read performance. The perfect setup is where you clean as infrequently as possible, though once a week is the default/expectation.
Just my thoughts,
Jonathan
suneny1234
1 Message
0
November 29th, 2016 12:00
I don't believe there is any advantage or disadvantage to this configuration. also cleaning on your source datadomain (in this case, it seems these are both source and target to each other) won't actually delete blocks which have not replicated to target yet even though images have reached the retention in avamar's catalog and have asked DD to delete them.
if you are running the DD over 90% then you will notice slow cleaning process as it needs more space to get this done faster. you can also increase the cleaning throttle.
how big is your DD990?
hope this helps!