Postgres Log Backups not aging off Primary Storage

Will you please run the "Data Retention Forecast " report and check the reason for being not aged?

REQ_BY_DATA - Job is required by a not yet prunable backup.

@Kiwi_Dave 

What is the oldest backup retained by basic retention? The log backups will be retained if you have jobs retained by basic retention. Data Retention and Forecast report should show the data backup job id due to which the logs are being retained with ‘Required by data’ reason.

Please check if that job is retained by basic or extended retention. If basic retention retaining the log backups is expected. If that job is very old and you don’t want log backups retained from that long time, you can move such data backup jobs to extended retention and that should release the REQ_BY_DATA chain.

Thanks,

Sunil-

The orange highlighted shows my log backups, the red text is my primary copy of the logs.

All other data and log backups are secondary copies. . 

Logs will always have basic retention as the secondary copies take last full backup of month. So a log file will never meet extended retention requirement.

Is there any elegant way to ensure that the primary copy log job is deleted as per basic days rule after a valid secondary has been copied to long term storage.

Hi @DaveK 

I see both these (Data & Log) are part of the same backup job id. In this case, these Archive Logs will be linked to Data and retained as long as the Data is retained. These logs are required to bring the database to consistent state during recovery. If we age these logs we can’t guarantee the recoverability of the database from just data component alone.

So, it is neither recommended to prune these log files, nor there is a way to do so.

You can however create a long term copy and copy these logs if you want to free up your primary copy storage.

Thanks,

Sunil-

Would you consider this a bug in Commvault?  Regardless of retention reason, if there is a secondary copy of the log then the primary should be deleted once it reaches it’s basic days requirement. The required by data retention will be fulfilled by the secondary copy.

The log in question is created when the backup of the database is taken, the database backup inherits the extended retention and this should pass to the log file instead of relying on required by data to hold onto the log.

Manually changing retention for logs each month would be a burden as we have a large number of logs in this state. There is no way using Storage policy extended retention rules that I know of that could only apply extended retention to a log file created while full database backup is run.

Hi @DaveK 

Can you please try one option? Instead of keeping same retention days for both these copies, can you increase the retention of the second copy slightly? When logs are there on multiple copies, the copy with the longest retention will be retained. Here in this case both copies have the same retention criteria.

Thanks,

Sunil-

Your suggestion worked.

I set the basic days retention on my secondary copy to 1 day higher than that of the primary. After running data aging the logs disappeared from the Primary copy.

Thanks for this. Happy to close the case