Skip to main content
Solved

Questions about Archiving and Backing up the same data

  • 6 October 2021
  • 2 replies
  • 619 views

We have a legacy setup wherein a share is both archived and backed up utilizing different sudo-clients.  There is a sudo-client to take intellisnap backup; and then there is another sudo client which runs archive job on the same location.  I am a bit confused by this setup.   

What is archiving actually doing?  My understanding was it would create a stub and move the data from primary storage to the MediaAgent saving some space on the primary storage and the backups would be smaller.

  • Also when we restore the backups would it restore the stub or actual data?

 

 

Also what happens during the restore/recall of archive; does stub gets replaced by the files and would that mean that the if there is another client running backup on the same share; it will capture all data rather than stub;  

Setup: 

Netapp Share: 

NetApp 9.84 Cluster-Mode

Sudo client ZCluster1:  Snapshot backup runs (Intellinsnap); backup copy goes to the MA (has DDB/IndexCache). 

Location it protects

“/svm-hsc-cifs/SharedDrives”

 

Another sudo-client (Archive):  Archives a sub-folder in Shared Drive above “/SharedDrives/ Marketing”

 

However, it appears it is just backing up the same data again without creating the stub or changing anything on the primary storage.  

I validated it by restoring the common files which are protected by both Intellisnap and Archive jobs and both restore the same data; wherein I had thought the restore that I would run from backup would just restore the stub file. 

Is there a way to check if the archive job is resulting in any stub creation?  

We have a legacy setup wherein a share is both archived and backed up utilizing different sudo-clients.  There is a sudo-client to take intellisnap backup; and then there is another sudo client which runs archive job on the same location.  I am a bit confused by this setup.   

What is archiving actually doing?  My understanding was it would create a stub and move the data from primary storage to the MediaAgent saving some space on the primary storage and the backups would be smaller.

  • Also when we restore the backups would it restore the stub or actual data?

 

 

Also what happens during the restore/recall of archive; does stub gets replaced by the files and would that mean that the if there is another client running backup on the same share; it will capture all data rather than stub;  

Setup: 

Netapp Share: 

NetApp 9.84 Cluster-Mode

Sudo client ZCluster1:  Snapshot backup runs (Intellinsnap); backup copy goes to the MA (has DDB/IndexCache). 

Location it protects

“/svm-hsc-cifs/SharedDrives”

 

Another sudo-client (Archive):  Archives a sub-folder in Shared Drive above “/SharedDrives/ Marketing”

 

However, it appears it is just backing up the same data again without creating the stub or changing anything on the primary storage.  

I validated it by restoring the common files which are protected by both Intellisnap and Archive jobs and both restore the same data; wherein I had thought the restore that I would run from backup would just restore the stub file. 

Is there a way to check if the archive job is resulting in any stub creation?  

Hi @Theseeker !  I moved this excellent post to its own thread so we can better track your answer.

I’m going to engage with our top Archiving expert so we can go down your list and cover all bases.

I broke this down into numbered questions to help make sure I answered all of your questions. Please find your questions and answers inline

 

1. We have a legacy setup wherein a share is both archived and backed up utilizing different sudo-clients.  There is a sudo-client to take intellisnap backup; and then there is another sudo client which runs archive job on the same location.  I am a bit confused by this setup.   

What is archiving actually doing?  My understanding was it would create a stub and move the data from primary storage to the MediaAgent saving some space on the primary storage and the backups would be smaller.

  • Also when we restore the backups would it restore the stub or actual data?

 

A. You are correct in that the File Archiver piece will stub the data leaving a 4k stub on the primary storage but for the backup piece, we are using the application size of the file and not the 4k size that is now on primary.

  • When restoring your data via the CommCell Console/Command Center, the default option is to restore the data version of the file but you can also restore the actual stub if needed.

 

 

2. Also what happens during the restore/recall of archive; does stub gets replaced by the files and would that mean that the if there is another client running backup on the same share; it will capture all data rather than stub;  

A. During a stub recall, the file version will replace the stub on primary storage and if there are backups running against the share, it will backup the file version unless you are using dedupe. If using dedupe, if the file has been backed up before and has not changed after being recalled, it will not be backed up twice. I have included a link to our Books Online below that discusses our Deduplication:

https://documentation.commvault.com/11.24/expert/12435_deduplication_for_data_protection_and_archiving.html#storage-policy-with-deduplication

 

3. Another sudo-client (Archive):  Archives a sub-folder in Shared Drive above “/SharedDrives/ Marketing”

However, it appears it is just backing up the same data again without creating the stub or changing anything on the primary storage.  

I validated it by restoring the common files which are protected by both Intellisnap and Archive jobs and both restore the same data; wherein I had thought the restore that I would run from backup would just restore the stub file. 

Is there a way to check if the archive job is resulting in any stub creation?  

 

A. To check whether or not a job had stubbed files, you can review the ‘stubbed’ column when viewing the backup history. If this is a newly created archiver subclient, you may be encountering the delayed archiving/stubbing feature. I have included a link below for reference but if you feel that files should have been archived but have not, please open a ticket with our support to review. They will need the following:

  • JobID
  • Logs from the CommServe, MediaAgent and Proxy machine performing the Archiving.

 

Delayed stubbing - https://documentation.commvault.com/11.24/expert/25875_delayed_archiving.html

 

Reply


Terms & ConditionsCookie settings