Hi Team,
I'd like to understand about the 3x BET capacity requirement when deploying WORM Workflows on an S3 based storage .
any documentation which explain the architecture and this limitation in detail ?
Hi Team,
I'd like to understand about the 3x BET capacity requirement when deploying WORM Workflows on an S3 based storage .
any documentation which explain the architecture and this limitation in detail ?
Good morning. The extra space requirement is due to the need to seal in order to age data. With WORM there is no micro pruning, just macro pruning. The extra space requirement is to allow data to continue to be written to storage until the DDB itself ages off.
I have a further question to this,
When the DDB’s are sealed do all the backups automatically switch to traditional full for the first backup on the DDB?
I’ve been told yes by some and read in another post that Synthetic full could still be run although not really advisable.
Reason I ask - if everything switched to the first initial full - that could kill the backup window/SLA during the first full pass so would need to plan sealing & backup schedules / plans accordingly. (or is there software intelligence that still references what’s previously been backed up so incremental/Syn Full can continue as normal?
Key question here is to understand the full impact to the backup environment and operation window when regularly sealing DDB’s using worm.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.