Veeam full backup retention

Have you checked if the Full Backup File Maintenance - Remove after X days option is enabled in the job?

It’s worth checking the job logs to see if any automatic deletions occurred.

I also recommend opening a support ticket with Veeam in parallel to ensure a deeper investigation.

Thanks for the information.But this option will only removes regular backup chains, right? It doesn't remove GFS restore points. GFS restore points are removed based on their GFS retention.

If you have any corruption in full or syntactic chain will lead to early deletion and GFS cannot mark the monthly flag. 

Navigate to Backups > Disk and locate your job and Right click > properties of the job.

Confirm that your monthly full backups are labeled as M as per your GFS config 

Also depending on the backup chain type if the new per VM with separate metadata that can play a factor.  See here - https://helpcenter.veeam.com/docs/backup/vsphere/retention_separate_vms.html?ver=120

Hi ​@Nikks -

Hard to say really. If possible, in your Veeam Console > Home node > Backups > Disks area. Rt-click a Job with these settings and select Properties. Select a VM in the top-left window, then view the restore points in the bottom pane. Can you see how many Monthly’s you have? I also noticed above you don’t have any Weekly’s configured. I really think that plays a big role here. If you can post a screenshot of your VM Properties, blocking out sensitive VM names so we can see what it shows. Let’s start there.

Best.

Yes it is enabled. I think this could be the reason ?

I don’t think that is the reason ​@Nikks . Deleted Items only refers to VM objects in a Job which have been removed from a Job and are no longer processed. So, if you remove “VM-A” from your Job, it is removed after 30 days only after it meets certain criteria, one of which if it is no longer part of an active backup chain.

See: https://helpcenter.veeam.com/docs/backup/vsphere/retention_deleted_vms.html?ver=120

Thanks for the clarification. Disk properties shows M 

Great! Thank you for sharing your VM/Backup Properties. You are good to go it appears from your screenshot. You have 3 mos worth of backups (inclusive, btw).

It looks like around the 23-29 March timeframe, you’ll have another Monthly taken and your Dec “M” .vbk file will be deleted, to meet your GFS 3 mo retention setting.

Best.

​@coolsport00 Thanks for the findings. But my question is that why i am not seeing the Jan 31st full backup here as per the below  settings. Active full backup runs on last day of every month. All these M showing are synthetic backups. Am i missing something ?

Nikks wrote:

coolsport00 wrote:

Great! Thank you for sharing your VM/Backup Properties. You are good to go it appears from your screenshot. You have 3 mos worth of backups (inclusive, btw).

It looks like around the 23-29 March timeframe, you’ll have another Monthly taken and your Dec “M” .vbk file will be deleted, to meet your GFS 3 mo retention setting.

Best.

​@coolsport00 Thanks for the findings. But my question is that why i am not seeing the Jan 31st full backup here as per the below  settings. Active full backup runs on last day of every month. All these M showing are synthetic backups. Am i missing something ?

 

In your original post you said that the Active Full is scheduled on the “Last monday of every month”. Actually based on the job properties it looks like it’s the “Last Sunday of every month”.

The GFS setting is set to use the “Last weekly full of the month”, which in January would have been Jan 26th. 

​@Nikks - per your initial post, you scheduled Active Fulls for last Monday of every month...not last day of the month, so that would be the 27th of Jan. I see the 26th, which coincides with your Synthetic Full config of every last Sunday of the Month. Your Active Full will get removed based on your Short-Term Retention. Once you reach 35 days, you’ll have that Active Full removed and just have the Synthetic around, so as not to have duplicate files. I think you should have at least a .vib file for the 27th though.

Hope that helps.

UPDATE: Actually, due to your 35 day Short-Term Retention, you won’t have a .vib on the 27th. So, what you have is (should be) correct. Is this Job a daily/24hr job? i.e. you run it once/daily?

Tommy O'Shea wrote:

Nikks wrote:

coolsport00 wrote:

Great! Thank you for sharing your VM/Backup Properties. You are good to go it appears from your screenshot. You have 3 mos worth of backups (inclusive, btw).

It looks like around the 23-29 March timeframe, you’ll have another Monthly taken and your Dec “M” .vbk file will be deleted, to meet your GFS 3 mo retention setting.

Best.

​@coolsport00 Thanks for the findings. But my question is that why i am not seeing the Jan 31st full backup here as per the below  settings. Active full backup runs on last day of every month. All these M showing are synthetic backups. Am i missing something ?

 

In your original post you said that the Active Full is scheduled on the “Last monday of every month”. Actually based on the job properties it looks like it’s the “Last Sunday of every month”.

The GFS setting is set to use the “Last weekly full of the month”, which in January would have been Jan 26th. 

Sorry i given incorrect info on Active full backup and synthetic in my initial post . This is the correct one.

Sorry i given incorrect info on Active full backup and synthetic in my initial post . This screenshot is the correct one. Instead of Day i typed Monday. regarding the job , it is daily one.

I ama little confused with thew Active and synthetic full backup with respect to GFS. Which full backup is GFS taking , synthetic or active based upon the settings ?

By your screenshot, and by your Synthetic Full configuration, it looks to be your Synthetic Full is used by GFS. I think my Active Full explanation above is still correct, whether it’s last day or last Mon.

You can read more about GFS below:
https://helpcenter.veeam.com/docs/backup/vsphere/gfs_retention_policy.html?ver=120

At the very least, you could contact Veeam Support to better explain and verify if I was correct. I actually had to do that several yrs ago. It can get a bit tricky 😉

​@Nikks, is the Active Full actually being created? Can you show the job statistics for Feb 28th? Does it indicate that an Active Full ran?

Yeah, the deleted items don’t apply to GFS retention. I didn’t pay attention to what you said.

This is a good point. Your Active Full will get removed based on your Short-Term Retention and what you have is correct. 

Thanks. Please advise me what changes i need to make in order to get GFS on Active full backup instead of synthetic? Sorry for the inconvenience caused, as i don’t have much expertise in GFS settings .

​@Nikks, also if the Active Full is actually running, how long is it taking to complete? Does it cross over into the next day/month?

Let me check from the logs

​@Nikks -

Why are you wanting an Active over Synthetic Full? Actually, I’m asking this a bit late...but why are you running both Full types to begin with? Is there some need or requirement you have to do so?

Synthetic Fulls, with Fast Clone enabled (XFS on Linux; ReFS on Windows) is super fast. Whereas Actives require data for the new Full to be pulled from the source storage/VMs, taking quite a bit of time to perform, similar to a 1st run of a Job.

To use Active over Synthetic, you simply just need to disable that function in your Job (uncheck the ‘Create Synthetic Full….’ option).

Before making any changes though, I highly advise you reach out to Support so you are sure of the changes you make result in the outcome you desire. You don’t want to run into any loss of data to inhibit recovery you may need.

we use full back up to be on our tape back ups as part of the contract with the clients

Ok, but I don’t think it matters if your Full is Synthetic vs Active for Tape, does it?

But, unchecking the box to do Synthetics will leave you with just your Actives. Again, reach out to Support for confirmation. You have several things going on here with your Backups and you want to be sure of your configs.

Best.