Solved

incremental storage policy - fuzzy on implementing in existing working policies

  • 18 January 2024
  • 4 replies
  • 59 views

Userlevel 2
Badge +7

I’m wondering how to add an incremental SP into a working environment without causing mission critical BUs to fail.

I have 4 “very large” NAS/NFS subclients which all go to a SP which currently has just one S3 destination for all jobs. It was becoming impractical to send all fulls and incs to tape and the business requirement is just “daily backups to tape” so we do synthetic fulls, but, even occasional synth fulls then would need to copy to tape, all wasting tapes due to cycles, etc. I had talked to one of the guys in support about this and it sounded “easy enough” but when I try to deploy, things don’t look like it was described over the phone.

So, what we would really like to do is have only incremental jobs copied from that S3 copy to tape. No fulls, ever go to tape. We also don’t want to skip any incs going to the existing primary bucket.

I thought it would be as simple as creating a new incremental policy but I have observed that if I have any Incremental SP’s the actual option to select the Inc.SP from the existing SP, the box is missing. I don’t get it. Removing all incremental SPs - the drop down box returns to my main S3 SP.

 

I then saw that you could modify the actual subclients to tell them how to get to the incremental SP, but, that seems to override sending those incs to the S3 primary or is that not going to change by all this?

Anyhow I couldn’t find a BoL page which answers this, only how to enable.

thanks!

icon

Best answer by Albert Williams 18 January 2024, 23:28

View original

4 replies

Userlevel 5
Badge +12

Hello @downhill 

I don’t think this is a very good design when it comes to restores. For you to restore data you are going to cause a chain recall on all your data because all of the Incremental are depended on each other. Performing a full or a Syth full creates a checkpoint to reduce the overhead of performing a restore.

Tapes are much more suited for long term storage of infrequent backups, in the case of DR or large scale outages and should not be used as your first point to restore from. I would recommend a short term retention on disk and then move only the full backups to tape with a retention that is suitable and not going to cause a huge amount of tape’s ( for example a monthly full for 1 year retention means you need 12 times the size of your full in tapes ). 

Even if you wanted to go forward with the design you are talking about, Commvault cannot move incremental jobs without it being a “synchronous copy” and this will pick up all jobs. There is no selective type available where it just picks Incremental jobs. 

I think a question to the business around what they need this data for and their use case for it. It sounds like they want to be able to perform a full recovery but not want to pay for all the space of maintaining multiple copies of the full. I would recommend deduplication multi-tier cloud storage to save the most cost ( assuming restores are not frequent ). This allows you to use something like deep glacier which has lots of cost savings. 

https://documentation.commvault.com/2023e/expert/faster_restores_for_amazon_s3_glacier.html

Kind regards

Albert Williams

Userlevel 2
Badge +7

Not so.

Each day the stuff that is picked up is what would be targeted for any restores, not a full plus tons of incs.

The requirement FROM the business is not to DR recover every shred from some full plus all incs, it’s simply to have the deltas on tape, local, not in the public cloud.

Basically a belt and suspenders, different media, etc.

I don’t mind doing fulls to tape occasionally but don’t want them chewing or co-mingling up tapes with incrementals on them.

on-demand backupset is another suggested way out of this but that requires a Rube Goldberg approach to target specific paths / directories / etc. and once they are backed up never back them up again.

 

Userlevel 5
Badge +12

I would say that your best answer to achieve this is to run your synthetic fulls less frequent then.
Sounds like the business has two requirements:

 

1- Copy of the data that is a cold copy and not linked to any public cloud.

2- Data recoverable with a 24 hour RPO

 

Joining both of these requirements into one solution i think is where you are hitting the main issue. 
If you can satisfy the business RPO needs with a shorter retention hot storage and then have the tapes making the offsite requirements things will be a lot easier to manage and restore from. Joining both will work but will make restores a lot harder.

Kind regards

Albert Williams

Userlevel 2
Badge +7

Ok I can see what we wanted to do with inc. policies is impossible. Moving on as other complications have arisen. thanks Albert.

Reply