As I’m on the Customer side and never get asked this kind of question, I can only provide what I would “think” would be appropriate, with a balance between “current’ restore points to ‘quickly’ restore from and viable long-term retention to be able to recover in the event of some mishap.

Personally, I’d go with your middle option Craig. A week’s worth for short-term is generally the timeframe of an org’s “operational restore window”; and, the 4Ws, 3Ms, 1Y gives the biz a good amount of long-term points from which to recover, without utilizing too much storage...assuming they’d be implementing a block clone filesystem.

Good question!

This one will be subjective for sure based on the person answering and where they work.  I selected the last one as it seems like a good policy and one I would implement.  It will be interesting to see how the answers on this one go.

chosen last option for me the best 

7D/4W/12M/1Y

I’m going with the second last option as that one works for us. However, it is also job dependent depending on the type of jobs being backed up and balances out our storage infrastructure too. 

From what I've seen, customers running in the cloud typically take daily backups and keep them for 14 days. They generally don't want weekly or annual backups unless necessary. (What I mean by "necessary" is that there are people who do it for reasons such as audit processes.)

Hi @Cragdoo 

my choice about 7D/4W/0M/0Y is only to VM backup related. I love to explain to the customer there are no reasons to have a lot of backup data for VM. I think 14 days for performance tier backup data is a good time to retain the VM if they have immutable repository and a very reactive support team. 

Different idea is for unstructured data where can be needed more restore point.  

Mine is very different, but I chose the middle as it seems reasonable. 

With tape I actually keep a few yearly jobs offline.  

I try to have 14-30 daily’s if I can for file servers at my primary site. At other sites I’ll start doing weekly/monthly jobs. 

I have a few jobs that run multiple times a day so I go by how many restore points instead of days. 

I also run snapshot jobs every few hours to capture the state of VM’s between the backup jobs if I need to restore something.

Great pool @Cragdoo ! Hi! if depends and you must provide a first guideline, the last option is the most complete: 7D/4W/12M/1Y

I see @Rick Vanover would add another option

7D/4W/4M/4Y 

Any thoughts on that one?

I can see that as well as 7Y for certain companies like banks or government for sure.  We have some customers that need that long for retention.

If using Fast Clone...sure! Minimal storage cost.

but would you call that standard/recommended? It’s based on specific compliance requirements.

No I would not. My other answer still stands for the recommended setting.

For me, it depends on what the customer is using for the backing repository.  If they’re using something like Object Storage, REFS or XFS datastores, then I’m fine with 7D/4W/12M/1Y (or longer yearly if needed), but for my clients using NTFS, NFS or SMB/CIFS repositories and we need the space, I’ll omit weekly retention and instead run something like 30D/0W/12M/1Y or much less like 30D/0W/3M/0Y if space is a real premium for them.  Most of these clients also will have copy jobs or SOBR including Object Storage that has the longer-term retention though.

I got a new request from a customer: an immutable S3 on-prem with 30 days retention and cloud immutable S3 with 30 days and 12Monthly...no weekly and no yearly… probably as new types of storing can emerge different types of retention policy. 

How would you implement this requirement? And what’s your idea about this? 

Thanks

You could do a VHR on premise and then cloud vendor for the GFS of 12 months plus the 30 days. It all depends what vendor you want to use like Wasabi say or other.  The VHR would be a physical box on premise.