PowerShell script exchange
Post Reply
FireExit
Service Provider
Posts: 27
Liked: 8 times
Joined: Nov 26, 2015 12:06 am
Contact:

Find retention policy for orphaned backup files?

Post by FireExit »

Hi,
When I delete a backup job, an alert pops up:

> Deleting backup job will detach existing backups. Detached backups can be found under the Orphaned node and are still subject to their last known time-based retention

Since I can't look in the job anymore to see what the retention is, and the properties of the backup don't seem to show it, how can I find what Veeam is using as the retention policy for a backup?
david.domask
Veeam Software
Posts: 2846
Liked: 654 times
Joined: Jun 28, 2016 12:12 pm
Contact:

Re: Find retention policy for orphaned backup files?

Post by david.domask »

Hi FireExit,

Regrettably this is not currently returned via any supported means with Powershell, and I'm not quick finding any methods for retrieving it with unsupported means.

Quick question however, are you using Day or Point based retention? Day has been default for awhile, but if you have jobs created in older versions it may be using Points (or you set Points intentionally)

Reason I ask is because Background Retention only works with Day based retention, so the point may be moot :/

Can you explain the use case a bit more? I do agree it's a useful information to have, but the main idea of Background retention automatically cleaning up old backups -- if there are backups that you know you'll need for a longer period, I would use Export Backup which allows pre-set custom retention periods. (these can be customized as per the User Guide page)

[Edit: Took some time to research this, and honestly there aren't good ways of retrieving this information besides doing a direct SQL query against the backups.options table. This table stores the original retention settings for a given backup, and you can do some math to figure out the remaining retention on a given restore point, but I would strongly advise against direct SQL queries, especially in a script. Lots of headaches, and very likely will need to use insecure means to pass SQL credentials to the script]
David Domask | Product Management: Principal Analyst
Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest