questions on v12's new background retention

[mcz]

Hi everyone,

I've researched a bit regarding the background retention, have read the "what's new" and "release notes" of v12, checked

https://helpcenter.veeam.com/docs/backu ... ml?ver=120

but never found all the answers. The questions are:

• where can you see which backups the background retention would delete after a v12 installation/upgrade?

• how can you manually overrule the system, so that a (orphaned) backup would not get deleted by the new functionality

• what if you have set a wrong retention in the original backup job, say you would like to extent the retention now, how could that be achieved?

Thanks!

[Dima P.]

Hello Michael,

where can you see which backups the background retention would delete after a v12 installation/upgrade?

- GFS backups that are expired (same as in v11)
- Orphaned backups with time-based retention (new in v12), these backups displayed under the Orphaned node
- Retired backups attached to the jobs if for some reason they are not processed by job itself (say the job is disabled). This rule however would affect only the part of the chain if you have multiple full backups. For example:

Retention is set to 5 days
Backup chain is [ F1 + I1-1 + I1-2 ] [ F2 + I2-1 + I2-2 + I2-3 ]
Backup job is disabled

Incremental backup I1-1 is expired, so all the backup chain F1 + I1-1 + I1-2 can be removed
Incremental backup I2-3 is expired, but wont be removed because F2 + I2-1 + I2-2 + I2-3 is the last backup chain in the job

how can you manually overrule the system, so that a (orphaned) backup would not get deleted by the new functionality

You can remove backup from configuration, that will remove it from db and next import or repository rescan will place such backup under imported node which is not processed by system (or background) retention

what if you have set a wrong retention in the original backup job, say you would like to extent the retention now, how could that be achieved?

You can change retention in the job and that would affect the backup.

[Egor Yakovlev]

Just to add some clearance here, as it might be a typo on Dima's comment:
- if i1.1 is expired, that will not immediately lead to a backup chain F1+i1.1+i1.2 deletion. The chain will be deleted when last increment (aka i1.2) expires in it.
- we have a default limit of minimum 3 restore points "leftover" with daily retention case, so yes, even when all restore points are expired in last F+i... chain, it will not be deleted.

/Cheers!

[mcz]

Thanks Egor & Dima,

regarding the to be removed restore points: I have a backup under "orphaned" and I only see one full there (it was only offloaded once). Assume you'd see more restore points, Y,M,etc. Now if you have deleted the source (copy) jobs, you wouldn't see the retention anywhere - that's at least what I'd claim now.

So how can I be sure if a restore point would be kept or not? I don't see any "expired" information there... Why not introduce a column in general to show everyone "will expire in x days"? That would be very helpful and would basically be the same as on the hardened repo...

Thanks!

[Egor Yakovlev]

A visible retention expiration date would be nice, of course.
Thing is, current code does not store exact removal dates for restore points anywhere in the database, and background retention process calculates "removal validity" for each restore point when it runs a daily cleanup. Having that said, calculating that data in the UI "on the flight" might require some overhead resources.
We are definitely considering improving user experience with removal dates visibility\control in the future updates.

[mcz]

Thanks Egor, makes sense. But what can I do now to validate my retention when there's no backup job left?

[Egor Yakovlev]

Unfortunately there is no way as of today(unless working with DB queries, which is never recommended).
To reset applied retention \ make sure Orphaned backups are preserved, You can use "Remove from Configuration + Import" path suggested by Dima above.

[Henrik.Grevelund]

Hi,

The background retention job starts at 00:30.
Is there a way to change that ?

I would like to move it to working hours, since it prevents backup beeing written to the repository being scanned in cloud connect.

[Egor Yakovlev]

Hi Henrik.

You can use:

Code: Select all

HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication\
"RetentionJobStartTimeHours" DWORD, 0-23
"RetentionJobStartTimeMinutes" DWORD, 0-59

/Cheers!

[bct44]

Hello, is it possible to be alerted when this task is not performed correctly? a snmp traps would be great

[Egor Yakovlev]

Currently there are no notifications for background retention session, as it is a common system session amongst dozens others.
Noted the improvement though, its a good one.
/Thanks!

[Matt.Sharpe]

Can the background retention job be disabled? I know its not best practice, but seeing it have an impact on an S3 job (jobs being locked by the retention job and not being released).

I imagine it can be disabled with a registry key?

[Dima P.]

Hello Matt,

Option to disable retention is coming in v12.1. Background retention also performs the so called object storage checkpoint cleanup, so it's not recommended to keep it disabled for a long time especially if you are running backup to an Object Storage repository. I'd recommend to raise a support case and investigate the lock issue. Thank you!