Understanding how the Short-Term Retention Policy works

[sandroalves]

Hi,

I made the following configuration:

Example 1





Example 2





I ran the first run on the same day changing only the times and others I ran running manually.

The documentation says: the default is 14 recovery points and with each execution outside the schedule it will create new recovery points.

I understand that if I did it manually, it can grow infinitely. But those that were executed in the schedule at the scheduled time, even if I change it several times a day, it should merge when it reaches the number defined in the JOB policy and not continue creating new ones.

I did the test using (recovery point and days) and the same situation happened.

The question is when this documentation reference will happen: (After the allowed number of restore points is exceeded, Veeam Backup & Replication automatically removes the oldest restore point from the backup chain)

The video should include an informed flag if it was manual or scheduled.

And also how do I remove these points already executed? Is there a manual merge?

Thanks.

[foggy]

Hi Sandro, do you have any full backup (either active or synthetic) scheduled under Advanced settings?

[sandroalves]

Hi,

I kept the default configuration:



The daily execution I read now and I believe it will not clear because the "date" is the same day.

----> For the daily retention policy, Veeam Backup & Replication does not count restore points created on the day the retention policy is run. For example, if you create a backup job on Monday, set daily retention to 3 days, and create full backups daily. On Thursday, Veeam Backup & Replication will keep restore points created during 4 days (Monday, Tuesday, Wednesday, and Thursday). Restore points created on Thursday will not be counted. On Friday, Veeam Backup & Replication will delete backup files created on Monday, and keep restore points created during 4 days (Tuesday, Wednesday, Thursday, and Friday). Note that the retention period may be longer depending on the specified backup method. <----

Now the recovery points need to be cleaned up, I don't agree with that!!!

Thanks.

[foggy]

Please review this KB article with a visual explanation of how retention works for different backup methods. You have synthetic full enabled, that means you're running simple forward incremental, which cannot delete the older part of the chain until the new full is created and the corresponding backup chain has enough restore points.

[sandroalves]

Hi,

this KB was enlightening! Very happy...

After unchecking the option (Create synthetic full backups periodically) and now, it is keeping only the last 3 backups.

This is the concept that I am used to with another protection solution.

I set up a periodic per minute and managed to simulate the process with 3 recovery points.

It maintains a full (vbk) and two incremental (vib).

It remains unclear what the information means:

---> If you decide to use the forward incremental backup method, it is necessary to schedule the creation of periodic active full or synthetic full backups. This will help you avoid long chains of increments, ensure safety of backup data, and allow you to meet the requirements of your retention policy. Below are animated examples of these things. <----

Why do I need to perform (active full or synthetic full backups) if I notice that (vbk) is updated after the 3 recovery point cycle?



And how to perform (active full or synthetic full backups) automated? (Reserve incremental?) I remember that my job is unchecked, because I want to work with infinite incrementals.

Now I want some help for the tape.

In the other solution I know, the export to the tape is always complete.

I read in the KB that "Forward Incremental" is the best option, but does that mean that to restore I need the complete tape? Did it also work on old solutions?!?!

Another doubt is the copy to tape is it always granular? Or do I always need to perform some activity on disk backup before playing to tape to activate granularity?

Thanks.

[foggy]

Please review this thread for considerations on why you might need periodic active fulls. Generally, they are not required these days provided you follow the recommendations mentioned there. To automate them, you either need to enable them in the job settings (like you had synthetic fulls enabled before - but this will switch the backup method to simple forever incremental and change retention algorithm) or trigger them manually via PS script scheduled with Windows Task Scheduler.

For the tape related questions, please create a separate thread in the corresponding subforum. Thanks!

[sandroalves]

Hi,

thankful for the topic, they exchange a lot of information and at some point end up causing confusion, but clarify some doubts.

I want to use the technology of infinite incremental and after deactivating the creation of (synthetic / complete) I understand that I am on the path I want, as my diaries will be short (only 6 days).

Using Surebackup will require a resource to connect the VMs and I don't have that.

- My routine will be:
- Daily with 6 days of infinite incremental backup (Saturday to Saturday)
- One weekly (Sunday)
- One monthly (Day 1 of the month)

However, I have the need to keep a weekly and three monthly backup.

I can't use GFS with infinite incremental, so that possibility is ruled out, as I need a full backup and when enabled on the task it makes an infinite incremental into a simple incremental.

What I have left then is to create another infinite incremental JOB (Synthetic and full disabled) and schedule to be executed for the weekly and monthly.

The conflict that can happen will be in the monthly one, because I don't know when the first day of the month will occur and it will happen with the daily backup.

Another point of observation that is not clear is that even using the same repository, deduplication should consider these backup chains "duplicate" and not use these same blocks.

Does my understanding make sense?

Thanks.

[sandroalves]

Hi,

I'm doing a simulation to understand how they see it (VBK) when we activate a backup copy with GFS.

I reiterate my indignation at the fact that dedup do veem does not reduce the space occupied by the same VM. He should have an intelligence to analyze the blocks of the VM already present in the repository.

This means that if I store 1TB of backups (initial - one VBK and one VIB) in the main repository, the second repository will need at least 1TB as well.

I hope that the next weekly and monthly he will deduplicate in the same repository.

Come on...









I noticed that he marked the (VBK) that was copied to the copy repository with "R - full backups created with the simple retention scheme or active full backups".

If I configured GFS that the Friday backup (today) should be "W - weekly backups", why did it mark it as "R"?



I configured that every 21st that will be tomorrow it should mark as "M - monthly backups". What will happen to this configuration? Will he mark (VBK) as "M"?

Do I need new (VBK) for "W and M"?

Thanks.

[foggy]

Veeam B&R inline deduplication is performed within a backup file. To deduplicate between the files you need to use some storage deduplication technology, for example, Windows Deduplication.

As for GFS retention, then consider using backup copy jobs instead of primary jobs GFS, it will allow to avoid creating several jobs for the same VMs.

[sandroalves]

Hi,

I understand, this information I have.

I believe that Veem does not want to be responsible for deduplication knowing that there are already resources in Windows (ReFs) and devices like "Data Domain" that do this job.

I continued my tests and now I understand in practice how it works. This is what I wanted to see and I was happy with a reason.

The space initially doubled with the new repository, but stagnated even after generating new full backups. That's nice!

Veem marks the full backup created during copying as "R, W or M".

If a weekly runs on a monthly date it merges both and scores as well.



Thanks.

[foggy]

Correct, if both weekly and monthly are scheduled on the same day, a single full backup will be marked both as weekly and monthly.

[sandroalves]

Hi,

well, this question I solved.

But I still have a very common one and I need an opinion from those who use it and not just theory.

It was said that it is not recommended to use native dedup from veem in the first repository, but to use it in the second repository for weekly and monthly.

I know other solutions and I know in practice what it is to work with dedup with 4K blocks. It sucks! The restoration takes a lot of time and is frustrating.

But you see it when we create the depository, we use 64KB blocks, that is, the deduplication with this block is very small and with that you have a very efficient restoration. Very much !!!!

I never used windows deduplication to restore using (ReFS). I understand that the dedup of the native of veem using 64K blocks could honestly be used in the main repository according to my initial clarification.

In addition to using dedup depending on the solution you cannot move the data due to hash blocking. This is bad, because you get stuck.

But using the windows dedup I no longer have practical experience, so the question remains.

If we use the windows dedup to restore a backup together with the inline dedup of veem will we have significant gains?

Will the restoration time be greatly affected?

If we need to expand the volume of windows with ReFS dedup, is there any impediment?

Thanks.

[foggy]

It was said that it is not recommended to use native dedup from veem in the first repository, but to use it in the second repository for weekly and monthly.

This recommendation refers to the target storage deduplication, not Veeam B&R inline deduplication. Veeam B&R inline deduplication uses much larger blocks (1MB by default). But with any kind of target storage deduplication restoration times will be affected due to the need to rehydrate data.