Skip to main content
Solved

Best practice of moving backup jobs from one disk library to another

  • 23 September 2022
  • 3 replies
  • 1255 views

Forum|alt.badge.img+4

Hi,

 

I am thinking to use Aux copy to move backup jobs of backup copy of storage policy from one disk library to another as the original disk library is getting full. I have several questions regarding Aux copy and hoping that I can get answers here.

  1. as there are two different disk libraries which use different DDBs, does it mean that a full copy of backup jobs will be transferred through the network without deduplication? When I looked into the aux job that I ran for testing, the size of backup data transferred across is much smaller and very closed to the actual data written size of the original copy. Did I miss anything or this is expected behavior? If so what is the theory behind it.
  2. How can I tell for sure that all backup jobs have been copied across? I am planning to delete the original copy to free up space but I want to make sure that all jobs are copied across before doing it.

Kind regards,

Boyi

Best answer by Jos Meijer

Hi @Boyi 

The data transfered on a aux copy with deduplication enabled will be more likely to be closer to the actual data written size. But this depends on if the blocks on the target side are present to deduplicate with. If it is data for which no reference blocks are available to deduplicate with, a higher amount of data will be transfered to provide the baseline blocks in order to provide deduplication on future data.

A part of your second question is also an influence for how the transfered data size will be, assuming that you have a synchronous copy then in basics it will copy all jobs and thus it is more likely all the necessary blocks are available for reference thus optimizing the data amount to be transfered on the network.

If you have a selective copy, only jobs will be copied depending on the settings choosen:

  • Automatically copy first or last full backup jobs based on automatic time-based selection such as all, weekly, monthly, quarterly, half-yearly, or yearly.
  • Manually select the jobs to be copied during an Auxiliary Copy operation.

This can be verifified in the Copy Policy settings of your Storage Policy Copy properties.
These settings will have data transfered periodically/incidentally and thus can show less optimized data amount to be transfered on the network as the chance of having new data will be more likely.

Coming back on your second question, once jobs have been copied according to the copy type it will be marked as transfered. When a job then is manually deleted on the target copy location you will have to manually set the job to be copied again, the system assumes you deleted the job with a reason.

 

View original
Did this answer your question?

3 replies

Mike Struening
Vaulter
Forum|alt.badge.img+23

@Boyi , you have the right idea on how to best move jobs, so here’s some context to answer your questions:

When deduping an aux copy, we don’t dedupe against concurrent streams, meaning it’s possible to copy 2 source jobs (or more) at the same time that should dedupe, but won’t.  For this reason the sizes in the copies won’t match, though it will get better over time.

If you check the aux copy jobs, make sure a) the number of jobs is the same and b) the first and last job ID are the same.  Now, if you have different sets of retention, this won’t help at all, but as long as you see no jobs to Be Copied, you should have everything completed.

Let me know if that helps!


Forum|alt.badge.img+4
  • Author
  • Byte
  • 7 replies
  • September 26, 2022

@Mike StrueningThanks for your reply.

 

Is there a way to estimate the size of data that will be transferred across the network with this aux copy? Is it close to the actual data written size or it will be the full application size? I know we can set network throttling to minimize the network impact but it would be good to know the data size in case anyone asks.

 

Also just for my own curiosity after the aux copy if I manually delete a job in the new copy/library, will the next aux copy job copy this missing backup again from the original copy/library again? Does aux copy always make sure the new copy is synced with the original copy?

 

Kind regards,

Boyi


Jos Meijer
Commvault Certified Expert
Forum|alt.badge.img+17
  • Commvault Certified Expert
  • 638 replies
  • Answer
  • September 26, 2022

Hi @Boyi 

The data transfered on a aux copy with deduplication enabled will be more likely to be closer to the actual data written size. But this depends on if the blocks on the target side are present to deduplicate with. If it is data for which no reference blocks are available to deduplicate with, a higher amount of data will be transfered to provide the baseline blocks in order to provide deduplication on future data.

A part of your second question is also an influence for how the transfered data size will be, assuming that you have a synchronous copy then in basics it will copy all jobs and thus it is more likely all the necessary blocks are available for reference thus optimizing the data amount to be transfered on the network.

If you have a selective copy, only jobs will be copied depending on the settings choosen:

  • Automatically copy first or last full backup jobs based on automatic time-based selection such as all, weekly, monthly, quarterly, half-yearly, or yearly.
  • Manually select the jobs to be copied during an Auxiliary Copy operation.

This can be verifified in the Copy Policy settings of your Storage Policy Copy properties.
These settings will have data transfered periodically/incidentally and thus can show less optimized data amount to be transfered on the network as the chance of having new data will be more likely.

Coming back on your second question, once jobs have been copied according to the copy type it will be marked as transfered. When a job then is manually deleted on the target copy location you will have to manually set the job to be copied again, the system assumes you deleted the job with a reason.

 


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings