Skip to main content

Hello,

 

a customer asked if it would be possible to make all their primary copies (for disk libraries) WORM-protected and what the implications were.

Up until now our standard is n-days/1cycle retention on primary copies and n-days/0cycle retention on a secondary copy.

We basically use the 1 cycle as a safety net. So if for whatever reason the backup of a client does not work for a long time, they always have one backup available without setting a manual retention on those jobs.

Now we have an internal discussion about how the retention for WORM works. Specifically if the cycle retention is also relevant for manual deletion of the jobs/clients that hold those jobs.

So for example: A client is using a WORM storage policy with 14 days/1 cycle retention.

Data Aging will not age out and delete the jobs automatically until both conditions are met.

But is it possible to manually delete the jobs on day 15? I would say it is not possible because it is still retained by the cycles. If that is the case, backups of long gone machines would always remain.

So it would be a decision between keeping a cycle as safety net or WORM.

 

In the documentation it is not completely clear what the case is and I don’t want to test the thing since we’d need support to remove the test afterwards.

 

If anyone has any experience or can point me to a page in the documentation I have overlooked I’d be grateful.

 

Thank you and have a nice day everyone!

Jakob

 

 

Hello @JakobL 

With retention I like to think of Days as “how long you want to keep the data” and Cycles as “how many copies of the data do you want to keep before we age the oldest one”. Both are used when it comes to data aging and both criteria must be met.

 

With WORM, the Policy has (in this example) 14day retention. If the data is deduplicated you will need to configure the DDB Seal Frequency to 14days to match. The Vendor’s WORM lock feature must be set to twice that so that blocks aren’t deleted while jobs later in the cycle are still in retention. 

For example: If Day1 backup runs and writes baseline, Backup on Day14 will reference those blocks. Day1 backup will age, but the blocks won’t be pruned because Day14 backup still needs them and has to be kept for 14days. Allowing Day1 blocks to age when the DDB is sealed will make the jobs later in the cycle un-restorable.

 

To answer your Retention question, Jobs will age according to retention, once they meet Days AND Cycles. If you are on Day 15\Cycle2, the job will age and there is no need for manual deletion. If you are on day15\Cycle1, a new Full must be run before the job will age. Since WORM is enabled nothing can be manually deleted without an authorization code from our Legal Team.

 

Thank you,

Collin

 

Hello @Collin Harper 

About WORM Storage, in a Storage Library with DDB, I have the feeling that the only concern of customers (including me) is the extra space (almost double) that is going to need for DDB sealing.

But, why is needed to seal that DDB (according with retention etc) ?
The DDB leaves in MA and WORM Storage protects the Disk Library. So why it is necessary to seal it and subsequently to create the need for additional space in Disk Library?

Would you have the noble kindness to explain please?

Best regards,
Nikos

Reply


Terms & ConditionsCookie settings